[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 incrediball changed: What|Removed |Added CC||peter at axium dot co.nz --- Comment #15 from incrediball 2013-04-02 00:58:40 UTC --- I believe the discussion here is missing the point. Currently (at least with version 4.5 and ARM, which I am currently using) the situation is that the compiler generates broken code WITHOUT COMMENT when the address of something like an integer in a packed structure is assigned to a int* . Since the pointer type does not provide any information about the actual alignment of the integer, it is obviously impractical to fix when accessing the integer and we certainly do not want to have extra code inserted for handling the possibility that the int may not be aligned correctly. Therefore the compiler MUST see this as a type conflict and at least warn that the address of the member in a packed struct is incompatible with the pointer type. I have several projects which require the use of packed structures and I simply cannot rule out that that I have not at some point accidentally assigned the address of a member variable to a pointer. It would therefore be very handy if the compiler could point this out. -Wcast-align certainly doesn't do this.
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #18 from incrediball 2013-04-02 20:21:06 UTC --- Not sure if I can agree with (or understand) this comment. If we use my example of the address of an int in a packed structure being assigned to an int* then one could argue that there is a kind of implicit cast happening. The pointer is to an integer WITH the default alignment which would be 4 on the ARM system I work with. The int in the struct has an alignment of 1 and so the two types need to be regarded as being incompatible and there should be an unconditional warning or at least -Wcast-align should enable such a warning. I don't know what BLKmode is but if you're speaking of making an int* type generally able to access the int regardless of its alignment, I think this is the wrong way to go because code size will explode and efficiency will go out the window. However if the int* would be declared with some special attribute then, sure, generate whatever code that is necessary to access the int and the above mentioned warning can be suppressed in this case (wouldn't the code generated be much the same code that is used to directly access the int in the packed struct anyway?) However this would be the second (optional) step, the first thing is that the compiler needs to emit a warning explaining that the code that it is generating is broken.
[Bug rtl-optimization/38644] [4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 incrediball changed: What|Removed |Added CC||peter at axium dot co.nz --- Comment #68 from incrediball 2013-04-05 03:51:14 UTC --- Is this problem resolved? The status is still set to "NEW" but "known to work" shows that it either has been resolved in v4.7.0 or that version is somehow not affected. I spent the best part of this week trying to track this problem down. It was VERY hard to reproduce but I eventually found that the -fschedule-insns2 compile option caused the problem. The code that was affected is almost exactly the same as the test case in comment #1.
