* Re: *more* alignment problems
@ 2000-03-30 13:06 Richard Kenner
2000-03-30 13:14 ` David Edelsohn
2000-03-30 13:22 ` Chip Salzenberg
0 siblings, 2 replies; 9+ messages in thread
From: Richard Kenner @ 2000-03-30 13:06 UTC (permalink / raw)
To: law; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: *more* alignment problems
2000-03-30 13:06 *more* alignment problems Richard Kenner
@ 2000-03-30 13:14 ` David Edelsohn
2000-03-30 13:22 ` Chip Salzenberg
1 sibling, 0 replies; 9+ messages in thread
From: David Edelsohn @ 2000-03-30 13:14 UTC (permalink / raw)
To: Richard Kenner; +Cc: law, gcc
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: *more* alignment problems
2000-03-30 13:06 *more* alignment problems Richard Kenner
2000-03-30 13:14 ` David Edelsohn
@ 2000-03-30 13:22 ` Chip Salzenberg
1 sibling, 0 replies; 9+ messages in thread
From: Chip Salzenberg @ 2000-03-30 13:22 UTC (permalink / raw)
To: Richard Kenner; +Cc: law, gcc
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: *more* alignment problems
@ 2000-03-30 13:40 Richard Kenner
2000-03-30 13:49 ` Chip Salzenberg
0 siblings, 1 reply; 9+ messages in thread
From: Richard Kenner @ 2000-03-30 13:40 UTC (permalink / raw)
To: chip; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: *more* alignment problems
2000-03-30 13:40 Richard Kenner
@ 2000-03-30 13:49 ` Chip Salzenberg
0 siblings, 0 replies; 9+ messages in thread
From: Chip Salzenberg @ 2000-03-30 13:49 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: *more* alignment problems
@ 2000-03-30 13:16 Richard Kenner
2000-03-30 13:21 ` David Edelsohn
2000-03-30 13:48 ` Michael Meissner
0 siblings, 2 replies; 9+ messages in thread
From: Richard Kenner @ 2000-03-30 13:16 UTC (permalink / raw)
To: dje; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: *more* alignment problems
2000-03-30 13:16 Richard Kenner
@ 2000-03-30 13:21 ` David Edelsohn
2000-03-30 13:48 ` Michael Meissner
1 sibling, 0 replies; 9+ messages in thread
From: David Edelsohn @ 2000-03-30 13:21 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
>>>>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: *more* alignment problems
2000-03-30 13:16 Richard Kenner
2000-03-30 13:21 ` David Edelsohn
@ 2000-03-30 13:48 ` Michael Meissner
1 sibling, 0 replies; 9+ messages in thread
From: Michael Meissner @ 2000-03-30 13:48 UTC (permalink / raw)
To: Richard Kenner; +Cc: dje, gcc
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* *more* alignment problems
@ 2000-03-30 12:48 Jeffrey A Law
0 siblings, 0 replies; 9+ messages in thread
From: Jeffrey A Law @ 2000-03-30 12:48 UTC (permalink / raw)
To: kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-03-30 13:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-30 13:06 *more* alignment problems Richard Kenner
2000-03-30 13:14 ` David Edelsohn
2000-03-30 13:22 ` Chip Salzenberg
-- strict thread matches above, loose matches on Subject: below --
2000-03-30 13:40 Richard Kenner
2000-03-30 13:49 ` Chip Salzenberg
2000-03-30 13:16 Richard Kenner
2000-03-30 13:21 ` David Edelsohn
2000-03-30 13:48 ` Michael Meissner
2000-03-30 12:48 Jeffrey A Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).