This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/51628] __attribute__((packed)) is unsafe in some cases


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628

--- Comment #18 from incrediball <peter at axium dot co.nz> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]