[Bug c++/40527] New: #pragma pack([push,] n) should be coded in the signature

[Bug c++/40527] New: #pragma pack([push,] n) should be coded in the signature

[gerolf dot wendland at nsn dot com]

I do regard the alignment settings for structs, unions, 
classes as important as the signature of functions.

compilation of structs in the scope of different 
#pragma pack([push], n) 
produces errors that are hard to understand.

The linker could produce errors or warnings when
combining compilation units with symbols that differ
only in their memory alignment.


The compiler's warning about impaired 
#pragma pack(push,n)
#pragma pack(pop)

doesn't help in such cases.


-- 
           Summary: #pragma pack([push,] n) should be coded in the signature
           Product: gcc
           Version: 4.3.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gerolf dot wendland at nsn dot com


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

[Bug c++/40527] #pragma pack([push,] n) should be coded in the signature

[bangerth at gmail dot com]

------- Comment #1 from bangerth at gmail dot com  2009-08-25 15:33 -------
That would require that the ABI specifies such a mangling. I'm not sure
anyone wants to go that route.


-- 


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

[Bug c++/40527] #pragma pack([push,] n) should be coded in the signature

[gerolf dot wendland at nsn dot com]

------- Comment #2 from gerolf dot wendland at nsn dot com  2009-08-26 06:55 -------
(In reply to comment #1)
> That would require that the ABI specifies such a mangling. I'm not sure
> anyone wants to go that route.

This is exactly what I had in mind. Slightly extended names for
structs/classes/unions would eventually lead to different mangled
names of functions.


-- 


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

[Bug c++/40527] #pragma pack([push,] n) should be coded in the signature

[jason at gcc dot gnu dot org]

------- Comment #3 from jason at gcc dot gnu dot org  2009-11-10 18:53 -------
This falls in the category of diagnosing ODR violations, which we don't really
try to do currently.  It would be possible to do some ODR checking based on the
debug info that we already emit; that seems a more promising route than
breaking the ABI for this sort of thing.


-- 


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