[Bug c++/17519] [3.4/4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-02-24 00:25 --- This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519
[Bug c++/17519] [3.4/4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct
--- Comment #12 from titusjan at gmail dot com 2006-02-17 08:38 --- (In reply to comment #11) Is this still an issue in 4.1/4.2. IIUC I've cleaned up the points where this warning was/was not being emitted. Ah. I've got 4.0.3. I'll check 4.1/4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519
[Bug c++/17519] [3.4/4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct
--- Comment #11 from nathan at gcc dot gnu dot org 2006-02-16 20:12 --- Is this still an issue in 4.1/4.2. IIUC I've cleaned up the points where this warning was/was not being emitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519
[Bug c++/17519] [3.4/4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct
--- Comment #10 from titusjan at gmail dot com 2006-02-15 11:53 --- (In reply to comment #9) (In reply to comment #4) [snip] All the more reason to warn if we don't pack these members now, but we might fix that in the future and thus change the data layout. I.e. if the packed attribute is applied (individually or as part of an entire struct / class) to a member, but ignored, and this is relevant for the size or alignment of that member, we should warn. That obviously applies for the target we are compiling for, but I think if possible, we should warn if the ignoring of the packed attribute is relevant for any possible gcc target. I've got non-POD objects that abstract endiannes and use them in arrays that represent data-packets. The non-POD objects are quite simple, they don't use inheritance or virtual methods. I use assert statements to verify the size of the data-packets and notice that packing hasn't changed. Nevertheless, I get this warning when changing from gcc 3.3 to 4.0. Is this warning given because there are other targets where the packing will be different, or because the packing might change in the future? In the first case: I don't need my program to be portable to every possible GCC target. I think it's my responsibility to ensure that it works on the relevant targets and would only want to get a warning if the packed attribute is actually ignored. In the second case: how likely is it that the packing will change in the future? I don't see any reason why my objects can't be packed but I have no knowledge of the GCC internals. In any case, can this warning be suppressed or is there a simple workaround? Since I use the asserts I'm not realy worried about missing the case when the packet attribute is ignored. Forgive me for using this bugtracking system as a helpdesk but I hope my questions contribute to the discussion. Pepijn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519
[Bug c++/17519] [3.4/4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-02-10 18:22 --- (In reply to comment #4) There's certainly a good case for warning about packing that's likely not to have the desired results - we've been bitten by that before. But that doesn't really apply to all non-POD; you can define a subset safe-non-POD (broadly speaking, no virtual functions/bases and (recursively) no unsafe non-static data members) where everything still has reasonably predictable representations and you don't need extra space for polymorphism magic. All the more reason to warn if we don't pack these members now, but we might fix that in the future and thus change the data layout. I.e. if the packed attribute is applied (individually or as part of an entire struct / class) to a member, but ignored, and this is relevant for the size or alignment of that member, we should warn. That obviously applies for the target we are compiling for, but I think if possible, we should warn if the ignoring of the packed attribute is relevant for any possible gcc target. So if you do go in that direction, please consider separate warnings for those non-POD types that can nevertheless safely be packed and those that can't. Classes made non-POD through fairly innoccuous constructions - e.g. constructors, simple inheritance - are often useful in abstracting hardware registers, data formats, etc. We'd be swamped in warnings if we got one for every packed non-POD, but we definitely do want to know if there's something that's actually going to mess things up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519
