[Bug target/15087] New: IA64: Wrong alignment for structure > 8 byte

[Bug target/15087] New: IA64: Wrong alignment for structure > 8 byte

[hjl at lucon dot org]

IA64 softwae runtime convention document, section 3.3.1 says that 
object greater that 8 bytes whould be aligned at 16 byte boundary. But
gcc doesn't do it.

-- 
           Summary: IA64: Wrong alignment for structure > 8 byte
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl at lucon dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[hjl at lucon dot org]

------- Additional Comments From hjl at lucon dot org  2004-04-23 01:33 -------
Created an attachment (id=6146)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6146&action=view)
A testcase

[hjl@gnu-4 align]$ gcc align_test.c
[hjl@gnu-4 align]$ ./a.out
Aborted


-- 


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

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-23 01:40 -------
Confirmed, the problem is the following define:
#define DATA_ALIGNMENT(TYPE, ALIGN)             \
  (TREE_CODE (TYPE) == ARRAY_TYPE               \
   && TYPE_MODE (TREE_TYPE (TYPE)) == QImode    \
   && (ALIGN) < BITS_PER_WORD ? BITS_PER_WORD : (ALIGN))

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |ABI, wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-23 01:40:38
               date|                            |


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

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-04-23 04:56 -------
Subject: Re:  New: IA64: Wrong alignment for structure >
 8 byte

hjl at lucon dot org wrote:
> IA64 softwae runtime convention document, section 3.3.1 says that 
> object greater that 8 bytes whould be aligned at 16 byte boundary. But
> gcc doesn't do it.

This is a known problem, except it is much more complicated than what HJ 
has stated.  You really have to look at the documentation here to 
properly understand what is going on.

The Software Conventions and Runtime Architecure (SCRA), section 3.3.1 
Global Variables, says that dynamically allocated regions (e.g. malloc), 
and external data items greater than 8 bytes must be aligned to 16-byte 
boundaries.  It also says that smaller objects must have alignment of 
the nearest power of 2 equal to or larger than their size.  So a global 
structure object of 3 chars must have an alignment of 4.  And the global 
structure object in HJ's example must have an alignment of 16.

The SCRA also says, in section 4.2 Aggregate Types, that an aggregate 
type has the same alignment as the most strictly aligned field.  There 
is an example showing a 24-byte structure type which has 8-byte 
alignment.  A structure type of 3 bytes has alignment of 1, and the 
structure type in HJ's example has alignment 8.

So the tricky part here is that if an aggregate object is local, then 
its alignment is only guaranteed to be as large as the alignment of its 
most strictly aligned field.  However, if an aggregate object is global 
(extern), then its alignment is a power of 2 equal to or larger than its 
size up to 16.  This is an unusual convention I have never seen before, 
and gcc currently has no support for it.  I looked at this once a few 
years ago and didn't see any easy way to implement it.  I think we have 
to add a new hook to implement it, and I never got around to that.

Just assuming the larger alignment for an aggregate object is not safe. 
  If we have a local object in one module, take its address, and then 
pass the address to another module, then we might segfault if we 
dereference it assuming it has the larger alignment.  So this means we 
must assume objects have the smaller alignment when dereferencing 
pointers to them, and we must assume they have the larger alignment when 
creating them.

We can do better if we had a reliable way to know if we were accessing a 
local or global object.  I am not sure if we have this info.  Things are 
probably easier now than when I first looked, what with cgraph, 
functions-as-trees, and tree-ssa.  In the simple case, if we are 
directly accessing a decl, and the decl is global, then we should be 
able to assume the larger alignment.

Gcc is currently self-consistent.  The problem only arises when linking 
gcc compiled code with icc compiled code, as icc implements the ABI as 
specified.

Fixing gcc means introducing a minor ABI change, which makes this more 
complicated.  Once we start increasing alignment for global objects, we 
can't immediately assume such larger alignments when derefencing them, 
as that fails if linked with code compiled by an older gcc version.  If 
we just continue assuming the smaller alignments on dereference for a 
gcc version or two, then we can spread the ABI breakage over a few 
years, and it will be less likely to affect anyone.  So we fix the 
alignments in version X, and then wait until version X+2 before using 
the new alignments for optimization purposes.  This means versions X-1 
and X+2 will be incompatible, but presumably few people would try 
cross-linking code compiled by two gcc versions which are 4 versions apart.


-- 


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

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[steven at gcc dot gnu dot org]

------- Comment #4 from steven at gcc dot gnu dot org  2010-07-20 13:40 -------
We might as well close this as WONTFIX, I don't think anyone is interested in
fixing this. We would have to document this problem in the manual, but then at
least we can close the Bugzilla entry. Thoughts?


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[michael dot haubenwallner at salomon dot at]

------- Comment #5 from michael dot haubenwallner at salomon dot at  2010-08-09 08:49 -------
Well, I'm waiting for this to become fixed, even if it isn't a real blocker
here.
There is a workaround (=ugly hack) using alignment attributes within #ifdef's
for the rare cases where this really is a problem - mallinfo() only for now
here.
But IIRC somewhere there was a note from an Oracle developer having to avoid
gcc on ia64-hpux because of this bug...
Found it: in PR30826, maybe a dup?


-- 


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

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-10 15:23:35 UTC ---
*** Bug 30826 has been marked as a duplicate of this bug. ***

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |SUSPENDED

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-10 15:29:09 UTC ---
(In reply to comment #3)
> Subject: Re:  New: IA64: Wrong alignment for structure >
>  8 byte
> 
> hjl at lucon dot org wrote:
> > IA64 softwae runtime convention document, section 3.3.1 says that 
> > object greater that 8 bytes whould be aligned at 16 byte boundary. But
> > gcc doesn't do it.
> 
> This is a known problem, except it is much more complicated than what HJ 
> has stated.  You really have to look at the documentation here to 
> properly understand what is going on.
> 
> The Software Conventions and Runtime Architecure (SCRA), section 3.3.1 
> Global Variables, says that dynamically allocated regions (e.g. malloc), 
> and external data items greater than 8 bytes must be aligned to 16-byte 
> boundaries.  It also says that smaller objects must have alignment of 
> the nearest power of 2 equal to or larger than their size.  So a global 
> structure object of 3 chars must have an alignment of 4.  And the global 
> structure object in HJ's example must have an alignment of 16.
> 
> The SCRA also says, in section 4.2 Aggregate Types, that an aggregate 
> type has the same alignment as the most strictly aligned field.  There 
> is an example showing a 24-byte structure type which has 8-byte 
> alignment.  A structure type of 3 bytes has alignment of 1, and the 
> structure type in HJ's example has alignment 8.
> 
> So the tricky part here is that if an aggregate object is local, then 
> its alignment is only guaranteed to be as large as the alignment of its 
> most strictly aligned field.  However, if an aggregate object is global 
> (extern), then its alignment is a power of 2 equal to or larger than its 
> size up to 16.  This is an unusual convention I have never seen before, 
> and gcc currently has no support for it.  I looked at this once a few 
> years ago and didn't see any easy way to implement it.  I think we have 
> to add a new hook to implement it, and I never got around to that.
> 
> Just assuming the larger alignment for an aggregate object is not safe. 
>   If we have a local object in one module, take its address, and then 
> pass the address to another module, then we might segfault if we 
> dereference it assuming it has the larger alignment.  So this means we 
> must assume objects have the smaller alignment when dereferencing 
> pointers to them, and we must assume they have the larger alignment when 
> creating them.
> 
> We can do better if we had a reliable way to know if we were accessing a 
> local or global object.  I am not sure if we have this info.  Things are 
> probably easier now than when I first looked, what with cgraph, 
> functions-as-trees, and tree-ssa.  In the simple case, if we are 
> directly accessing a decl, and the decl is global, then we should be 
> able to assume the larger alignment.

This basically means that layout_type has to assume the object is local
(thus, TYPE_ALIGN is the conservative low value - this value is also
used when accessign the object via a pointer).  layout_decl on the other
hand does have the information whether the object is local or global
and can properly specify DECL_ALIGN to be higher.

> Gcc is currently self-consistent.  The problem only arises when linking 
> gcc compiled code with icc compiled code, as icc implements the ABI as 
> specified.
> 
> Fixing gcc means introducing a minor ABI change, which makes this more 
> complicated.  Once we start increasing alignment for global objects, we 
> can't immediately assume such larger alignments when derefencing them, 
> as that fails if linked with code compiled by an older gcc version.  If 
> we just continue assuming the smaller alignments on dereference for a 
> gcc version or two, then we can spread the ABI breakage over a few 
> years, and it will be less likely to affect anyone.  So we fix the 
> alignments in version X, and then wait until version X+2 before using 
> the new alignments for optimization purposes.  This means versions X-1 
> and X+2 will be incompatible, but presumably few people would try 
> cross-linking code compiled by two gcc versions which are 4 versions apart.

So, I am suspending this bug since the architecture in question lingers
in a semi-dead state and thus any ABI breakage is probably unwanted.