[U-Boot] [PATCH v2] arm: Switch to -mno-unaligned-access when supported by the compiler

[Wolfgang Denk]

Dear Tom,

In message <20140210222819.GE7049 at bill-the-cat> you wrote:
> 
> I agree we shouldn't use __packed without a good reason.  And I don't
> think we've got many no-reason uses right now but I'm all in favor of
> dropping them and keeping an eye on new users.  The problem is that
> unless we do something, any of the valid and we aren't going to / can't
> change them __packed structs will be the next place things blow up when
> gcc optimizes things in a new (and valid based on what we've told it!)
> way.

If I look around where __packed (and variants) is being used I could
just cry.  Just have a loog for example at include/ec_commands.h - it
appears they always add __packed to all structs, including such where
all entries are uint8_t - see for example struct ec_lpc_host_args :-(

> > Takes valid code?  But would this original code run on an architecture
> > where any unaligned access causes a machine check?  My understanding
> > is it doesn't?
> 
> It would run because being __packed gcc would know to do the right thing
> on that architecture.

We are not discussing application code here.  We are dealing with low-
level hardware related stuff.  When I try to read from a 32 bit device
register I must be absolutley sure that this will be a single 32 bit
transfer.  It is totally unacceptable if I have to fear that the
compiler might break this up into 4 byte accesses behind my back. What
if this happens to be an auto-incrementing register or such?

But obviously only few people share this point of view...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man did not weave the web of life; he  is  merely  a  strand  in  it.
Whatever he does to the web, he does to himself.     - Seattle [1854]