PR 45819 - possible fix?

[Richard Guenther]

On Mon, Jul 25, 2011 at 7:05 PM, DJ Delorie <dj@redhat.com> wrote:
>
>> Fact is that GCC knows that memory is not properly aligned.
>
> So in the impossibly rare case that gcc is *wrong*, how is the
> programmer supposed to tell gcc that?  I mean, gcc 4.4 has been doing
> what the programmer wanted, and zillions of ARM devices have been
> happily working, and now you tell me they should have been segfaulting
> for the last N years.  Surely there's a chance that the ARM developers
> know what they're talking about, and have been desperately trying to
> convince gcc to stop trying to second-guess them?

So don't lie to GCC then?  You specify

struct X { char c; int i; } __attribute__((packed)) x;

and expect that GCC knows x.i is aligned to 4 bytes!?  It sees the access
to x.i, sees you are on a strict-align target and makes sure your code does
not fault.  How is that not a sane default behavior?

> I mean, what else should the user expect when they cast a random value
> to a "volatile uint32_t *" and derefence it?  I would have expected
> gcc to preserve the load *exactly* as the user specified it, not
> convert that one load into FOUR loads.

Well, then provide a proper struct definition, I suppose adding some
head padding and adjusting the pointer in ehci->regs would do the trick.

Or declare it a bug in volatile handling (which is, after all, not
very well defined)
and simply throw away any alignment information we have in that case
(which would make it an expander bug I guess, unless the arm target does
something special here).

Richard.