[Bug tree-optimization/30826] New: alignment error when optimizing with inlining

[Bug tree-optimization/30826] New: alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

Attached test program dumps core when built with optimization using gcc-4.1.1
on ia64-hp-hpux11.23.

It works without optimization, or when using "-O1 -fno-inline".

It is same both with HP's gcc-4.1.1 as well with self-built gcc-4.1.1, both
using GNU as.

$ /opt/hp-gcc-4.1.1/bin/gcc -v
Using built-in specs.
Target: ia64-hp-hpux11.23
Configured with: /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/configure
--host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23
--prefix=/opt/hp-gcc-4.1.1 --enable-languages=c,c++ --with-gnu-as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
Thread model: posix
gcc version 4.1.1

$ /opt/hp-gcc-4.1.1/bin/gcc inline.c
$ ./a.out

$ /opt/hp-gcc-4.1.1/bin/gcc inline.c -O1
$ ./a.out
Bus error (core dumped)

$ /opt/langtools/bin/gdb a.out
HP gdb 5.6.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.6.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..(no debugging symbols found)...
(gdb) r
Starting program: /mnt/big/logins/haubi/a.out 
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGBUS, Bus error
  si_code: 1 - BUS_ADRALN - Invalid address alignment.
0x200000007edb4130:0 in mallinfo+0x180 () from /usr/lib/hpux32/libc.so.1
(gdb) bt
#0  0x200000007edb4130:0 in mallinfo+0x180 () from /usr/lib/hpux32/libc.so.1
#1  0x40008b0:0 in main+0x30 ()
(gdb)


-- 
           Summary: alignment error when optimizing with inlining
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: michael dot haubenwallner at salomon dot at
 GCC build triplet: ia64-hp-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


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

[Bug tree-optimization/30826] alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

------- Comment #1 from michael dot haubenwallner at salomon dot at  2007-02-16 17:50 -------
Created an attachment (id=13055)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13055&action=view)
testcase, extracted from preprocessor output of real application code.

Have looked at assembler output:
There is a difference in call to mallinfo() from f1(), when f2() is empty, or
when using 'long long' as datatype for 'status'.


-- 


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

[Bug tree-optimization/30826] alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

------- Comment #2 from michael dot haubenwallner at salomon dot at  2007-02-16 17:56 -------
Created an attachment (id=13056)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13056&action=view)
the failing assembler output, created with '-O1'

Have the focus on line 18:
18     adds r8 = 20, r12
19     br.call.sptk.many b0 = mallinfo#


-- 


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

[Bug tree-optimization/30826] alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

------- Comment #3 from michael dot haubenwallner at salomon dot at  2007-02-16 17:58 -------
Created an attachment (id=13057)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13057&action=view)
assembler output without the bug-trigger, built with '-O1 -DNOTRIGGER'

Again, focus on line 18:
18     adds r8 = 16, r12
19     br.call.sptk.many b0 = mallinfo#


-- 


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

[Bug tree-optimization/30826] alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

------- Comment #4 from michael dot haubenwallner at salomon dot at  2007-02-16 18:06 -------
Have already debugged inside mallinfo(), where gdb says:
Program received signal SIGBUS, Bus error
  si_code: 1 - BUS_ADRALN - Invalid address alignment.
0x200000007edb4130:0 in mallinfo+0x180 () from /usr/lib/hpux32/libc.so.1

The disassembly snippet of mallopt() is:

(gdb) disassemble $pc $pc+0x10
Dump of assembler code from 0x200000007edb4130:0 to 0x200000007edb4140:0:
0x200000007edb4130:0 <mallinfo+0x180>:        st8              [r79]=r9
0x200000007edb4130:1 <mallinfo+0x181>:        st8              [r38]=r8,8
0x200000007edb4130:2 <mallinfo+0x182>:        adds             r14=-8,r11;;
End of assembler dump.
(gdb) p /x $r79
$2 = 0x200000007fffe914
(gdb) 

The value of r79 comes from that r8 set on line#18, which is incorrectly
aligned to 4 when calculated from '20, r12'.

Seems that it needs to be aligned to 8 for 'st8'...


-- 


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

[Bug target/30826] alignment error when optimizing with inlining

[sje at cup dot hp dot com]

------- Comment #5 from sje at cup dot hp dot com  2007-02-16 23:26 -------
It looks like GCC is running afoul of the IA64 Runtime standard.  In section
8.6 (return values) it says that aggregates larger than 256 bytes (mallinfo is
320 bytes), the caller must allocate a buffer and pass a pointer to that buffer
to the callee.  It also says that the buffer must be 16 byte aligned.  GCC is
passing a pointer to the local mi variable.  That local variable is only
required to have 4 byte alignment because that is the maximum alignment of any
of its fields.

The inlining is incidental in that it is what results in mi being 4 (but not 8)
byte aligned and thus causing the segfault.

There is another bug (PR15087) about GCC not obeying the IA64 runtime alignment
requrements in other cases.


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sje at cup dot hp dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-02-16 23:26:10
               date|                            |


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

[Bug target/30826] alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

------- Comment #6 from michael dot haubenwallner at salomon dot at  2007-02-17 14:35 -------
(In reply to comment #5)

> There is another bug (PR15087) about GCC not obeying the IA64 runtime alignment
> requrements in other cases.
> 

Huh, this one is nearly three years old.
After reading that one, if understanding right, I'd be happy to have a patch
for gcc to fix this if available, even if not in svn, as we link only against
oracle and SAP libs from third party, not using structures as return values
IIRC. Everything else is built with this same gcc.

Or would it be enough to simply disable inlining here as a workaround ?
If yes, a simple patch to disable inlining for this platform might help, to
avoid to have our build-process always pass -fno-inline (unfortunately we're
not using autotools everywhere yet).


-- 


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

[Bug target/30826] alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

------- Comment #7 from michael dot haubenwallner at salomon dot at  2007-02-17 15:01 -------
Maybe coincident, but using gcc-3.4.5 with '-O2' works for this one testcase.


-- 


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

[Bug target/30826] alignment error when optimizing with inlining

[michael dot haubenwallner at salomon dot at]

------- Comment #8 from michael dot haubenwallner at salomon dot at  2007-02-19 12:19 -------
(In reply to comment #5)
> <snip> it says that aggregates larger than 256 bytes (mallinfo is
> 320 bytes), <snip>

This should be counted in _bits_, not bytes ?
'struct mallinfo' has 40 bytes, 10 * int32_t, 320 _bits_.


-- 


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

[Bug target/30826] alignment error when optimizing with inlining

[sje at cup dot hp dot com]

------- Comment #9 from sje at cup dot hp dot com  2007-02-20 17:06 -------
I did mean 256 bits and not bytes in comment #5.

Forcing -fno-inline wouldn't necessarily help, the compiler is forcing the
return structure to be 4 byte aligned and it is going to be a 50/50 proposition
whether or not it also gets 8 byte aligned by chance.  Any optimization that
changed the layout of local variables could affect the alignment of the return
structure (which might be the local variable or might be a temporary created by
GCC).

I was able to workaround the bug in inline.c by putting
  __attribute__ ((aligned(16)))
on the declaration of mi.

This should work as long as GCC doesn't need to create a temporary for the
return value being returned and puts it directly in the mi variable. If it
creates a temporary there is no way to control the alignment used.


-- 


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

[Bug target/30826] alignment error

[tom dot culliton at oracle dot com]

------- Comment #10 from tom dot culliton at oracle dot com  2008-01-07 17:42 -------
We've run afoul of this issue as well attempting to use gcc 4.1.1 and 4.1.2 on
this platform, and it means that G++ is essentially unusable for us. Not
following the IA64 ABI/Runtime Standard is a pretty serious bug.

Is there a reliable work around for this problem?


-- 

tom dot culliton at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tom dot culliton at oracle
                   |                            |dot com


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