Re: *more* alignment problems

Re: *more* alignment problems

[Richard Kenner]

    Because all of those bitfield functions were manipulating alignment in
    bytes, the SLOW_UNALIGNED_ACCESS macro expects the alignment to be
    bytes.  The primary question for SLOW_UNALIGNED_ACCESS is whether the
    alignment is less than the natural alignment for the type, usually in
    granularity of bytes, not bits.

Why does it matter which way it's defined?  I changed the macro in
rs6000.h to accept bits.

Re: *more* alignment problems

[David Edelsohn]

>>>>> Richard Kenner writes:

> Because all of those bitfield functions were manipulating alignment in
> bytes, the SLOW_UNALIGNED_ACCESS macro expects the alignment to be
> bytes.  The primary question for SLOW_UNALIGNED_ACCESS is whether the
> alignment is less than the natural alignment for the type, usually in
> granularity of bytes, not bits.

Richard> Why does it matter which way it's defined?  I changed the macro in
Richard> rs6000.h to accept bits.

	It does not matter how it is defined and changing all uses is
fine.  expmed.c:store_bit_field() uses the macro, so if there is some
confusion over the units of alignment in the function, it will affect the
call to the macro.

	Actually, the use of SLOW_UNALIGNED_ACCESS() which I implemented
is incomplete because it often uses the alignment of the containing object
and not the effective alignment of the bitfield based on the actual offset
used. 

David

Re: *more* alignment problems

[Michael Meissner]

On Mon, Mar 30, 1970 at 04:26:33PM -0500, Richard Kenner wrote:
>     Because all of those bitfield functions were manipulating alignment in
>     bytes, the SLOW_UNALIGNED_ACCESS macro expects the alignment to be
>     bytes.  The primary question for SLOW_UNALIGNED_ACCESS is whether the
>     alignment is less than the natural alignment for the type, usually in
>     granularity of bytes, not bits.
> 
> Why does it matter which way it's defined?  I changed the macro in
> rs6000.h to accept bits.

As long as the macro in question will never need to deal with anything that is
larger than 1/8 of the address space.

-- 
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: *more* alignment problems

[Richard Kenner]

    According to Richard Kenner:
    > I only really *have* one target easily accessible to me now.

    Surely the GNU project owns more than just Alphas.  If all else fails
    you could send me a tarball and I could bootstrap on the various Debian
    machines I have access to.

Note the word "now".  I expect this to change in the not-too-distant
future.

Re: *more* alignment problems

[Chip Salzenberg]

According to Richard Kenner:
>     According to Richard Kenner:
>     > I only really *have* one target easily accessible to me now.
> 
>     Surely the GNU project owns more than just Alphas.
> 
> Note the word "now".  I expect this to change in the not-too-distant
> future.

Marvy.  My offer stands, though, in the meantime.
-- 
Chip Salzenberg              - a.k.a. -              <chip@valinux.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: *more* alignment problems

[Richard Kenner]

    Maybe for a change this extensive you should have bootstrapped more than
    just one target.

I only really *have* one target easily accessible to me now.

    What unit is ALIGN supposed to have for store_field?  In at least one
    case it's being called with alignment in bits.

It's supposed to have bits *everywhere*.

    That value gets passed to store_bit_field which expects alignment in bytes
    according to its comment.

I thought I fixed the comment.

Let me review.

Re: *more* alignment problems

[David Edelsohn]

	Because all of those bitfield functions were manipulating
alignment in bytes, the SLOW_UNALIGNED_ACCESS macro expects the alignment
to be bytes.  The primary question for SLOW_UNALIGNED_ACCESS is whether
the alignment is less than the natural alignment for the type, usually in
granularity of bytes, not bits.

David

Re: *more* alignment problems

[Chip Salzenberg]

According to Richard Kenner:
> I only really *have* one target easily accessible to me now.

Surely the GNU project owns more than just Alphas.  If all else fails
you could send me a tarball and I could bootstrap on the various Debian
machines I have access to.
-- 
Chip Salzenberg              - a.k.a. -              <chip@valinux.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

*more* alignment problems

[Jeffrey A Law]

I spoke too soon.

Maybe for a change this extensive you should have bootstrapped more than
just one target.

What unit is ALIGN supposed to have for store_field?  In at least one
case it's being called with alignment in bits.

That value gets passed to store_bit_field which expects alignment in bytes
according to its comment.

The mis-match is causing 931110-1.c to fail execution because we do a
mis-aligned store.

jeff