Dear Tom, In message <20140210222819.GE7049@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: w...@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] _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot