Old Synopsis: GCC 3.3 miscompiles code with -O3 -fPIC on x86 New Synopsis: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 State-Changed-From-To: open->analyzed State-Changed-By: bangerth State-Changed-When: Tue May 20 01:16:37 2003 State-Changed-Why: Confirmed. This is a smaller snippet (it has nothing to do with namespaces): ---------------------------- int* i; int& get_x() { return *i; } int main() { int j; i = &j; get_x(); } -------------------------- It crashed in get_x: g/x> /home/bangerth/bin/gcc-3.3-pre/bin/c++ -O3 -fPIC x.cc g/x> ./a.out Segmentation fault Note that we really need both -fPIC and -O3. This crashes with both 3.3 and present mainline. It doesn't with 2.95 and 3.2.3, so it's definitely a regression worth fixing! W. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10877
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Andrew Pinski <pinskia@physics.uc.edu> To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, lloyd@acm.jhu.edu, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Andrew Pinski <pinskia@physics.uc.edu> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Mon, 19 May 2003 21:58:26 -0400 It does not fail for me though on i686-pc-linux-gnu with GCC: 3.4 20030517 (experimental). Or on i686-unkown-openbsd3.1 with gcc version 3.4 20030519 (experimental). tin:~/src/gnu/gcc>g++ -O3 -fPIC ../gcctest/testpic.cc tin:~/src/gnu/gcc>./a.out tin:~/src/gnu/gcc>more ../gcctest/testpic.cc int* i; int& get_x() { return *i; } int main() { int j; i = &j; get_x(); } Thanks, Andrew Pinski PS here is the asm from a working version: .file "testpic.cc" .globl i .bss .align 4 .type i, @object .size i, 4 i: .zero 4 .text .align 2 .p2align 4,,15 .globl _Z5get_xv .type _Z5get_xv, @function _Z5get_xv: .LFB4: call __i686.get_pc_thunk.ax addl $_GLOBAL_OFFSET_TABLE_, %eax pushl %ebp .LCFI0: movl i@GOT(%eax), %edx movl %esp, %ebp .LCFI1: popl %ebp movl (%edx), %eax ret .LFE4: .size _Z5get_xv, .-_Z5get_xv .align 2 .p2align 4,,15 .globl main .type main, @function main: .LFB5: pushl %ebp .LCFI2: movl %esp, %ebp .LCFI3: leal -8(%ebp), %eax pushl %ebx .LCFI4: subl $4, %esp .LCFI5: andl $-16, %esp call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx movl i@GOT(%ebx), %ecx movl %eax, (%ecx) call _Z5get_xv@PLT movl -4(%ebp), %ebx xorl %eax, %eax leave ret .LFE5: .size main, .-main .section .gnu.linkonce.t.__i686.get_pc_thunk.ax,"ax",@progbits .globl __i686.get_pc_thunk.ax .hidden __i686.get_pc_thunk.ax .type __i686.get_pc_thunk.ax, @function __i686.get_pc_thunk.ax: movl (%esp), %eax ret .section .gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits .globl __i686.get_pc_thunk.bx .hidden __i686.get_pc_thunk.bx .type __i686.get_pc_thunk.bx, @function __i686.get_pc_thunk.bx: movl (%esp), %ebx ret .ident "GCC: (GNU) 3.4 20030517 (experimental)" http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=10877
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Wolfgang Bangerth <bangerth@ices.utexas.edu> To: Andrew Pinski <pinskia@physics.uc.edu> Cc: gcc-bugs@gcc.gnu.org, <lloyd@acm.jhu.edu>, <gcc-gnats@gcc.gnu.org> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 08:47:58 -0500 (CDT) > It does not fail for me though on i686-pc-linux-gnu with GCC: 3.4 > 20030517 (experimental). > Or on i686-unkown-openbsd3.1 with gcc version 3.4 20030519 > (experimental). That's pretty weird. I can reproduce this with most a 3.4 snapshot from 2003-05-15 as well as a 3.3 snapshot from 2003-05-16. I compared the assembler output, and instructionwise they are equal, but there are some additional linkonce things in your output. I don't know enough about this stuff to tell whether that's relevant. I'll update now to present HEAD and check+report again once the bootstrap is done. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Wolfgang Bangerth <bangerth@ices.utexas.edu> To: Andrew Pinski <pinskia@physics.uc.edu> Cc: gcc-bugs@gcc.gnu.org, <lloyd@acm.jhu.edu>, <gcc-gnats@gcc.gnu.org> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 10:26:37 -0500 (CDT) > It does not fail for me though on i686-pc-linux-gnu with GCC: 3.4 > 20030517 (experimental). > Or on i686-unkown-openbsd3.1 with gcc version 3.4 20030519 > (experimental). OK, I made the experiment -- and my small snippet still segfaults with both 3.3 and 3.4 checked out an hour or so ago. This is the assembler output I get on my system with present 3.4. I think I'm at a loss for further explanations, but feel free to ask me if you think you have a theory... W. .file "y.cc" .globl i .bss .align 4 .type i, @object .size i, 4 i: .zero 4 .text .align 2 .p2align 4,,15 .globl _Z5get_xv .type _Z5get_xv, @function _Z5get_xv: .LFB4: call .LPR0 addl $_GLOBAL_OFFSET_TABLE_, %eax pushl %ebp .LCFI0: movl i@GOT(%eax), %edx movl %esp, %ebp .LCFI1: popl %ebp movl (%edx), %eax ret .LFE4: .size _Z5get_xv, .-_Z5get_xv .align 2 .p2align 4,,15 .globl main .type main, @function main: .LFB5: pushl %ebp .LCFI2: movl %esp, %ebp .LCFI3: leal -8(%ebp), %eax pushl %ebx .LCFI4: subl $4, %esp .LCFI5: andl $-16, %esp call .LPR3 addl $_GLOBAL_OFFSET_TABLE_, %ebx movl i@GOT(%ebx), %ecx movl %eax, (%ecx) call _Z5get_xv@PLT movl -4(%ebp), %ebx xorl %eax, %eax leave ret .LFE5: .size main, .-main .LPR0: movl (%esp), %eax ret .LPR3: movl (%esp), %ebx ret .ident "GCC: (GNU) 3.4 20030520 (experimental)"
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> To: Wolfgang Bangerth <bangerth@ices.utexas.edu> Cc: Andrew Pinski <pinskia@physics.uc.edu>, gcc-bugs@gcc.gnu.org, lloyd@acm.jhu.edu, gcc-gnats@gcc.gnu.org Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 19:00:33 +0200 On Tue, May 20, 2003 at 10:26:37AM -0500, Wolfgang Bangerth wrote: > OK, I made the experiment -- and my small snippet still segfaults with > both 3.3 and 3.4 checked out an hour or so ago. This is the assembler > output I get on my system with present 3.4. I think I'm at a loss for > further explanations, but feel free to ask me if you think you have a > theory... Feeding this assembler file into gcc 3.2 on an Intel box works for me and the program doesn't crash! This might mean that we have an assembler/binutils problem here. Gruesse Christian -- THAT'S ALL FOLKS!
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Wolfgang Bangerth <bangerth@ices.utexas.edu> To: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de> Cc: Andrew Pinski <pinskia@physics.uc.edu>, <gcc-bugs@gcc.gnu.org>, <lloyd@acm.jhu.edu>, <gcc-gnats@gcc.gnu.org> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 12:05:35 -0500 (CDT) > Feeding this assembler file into gcc 3.2 on an Intel box works for me > and the program doesn't crash! This might mean that we have an > assembler/binutils problem here. Whereas if I do the same, it crashes. So you seem to have a point :-) My binutils are 2.11.92.0.10 20011021 (SuSE) (this is what SuSE shipped with 8.0). What do you have? W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Andrew Pinski <pinskia@physics.uc.edu> To: Andrew Pinski <pinskia@physics.uc.edu> Cc: Wolfgang Bangerth <bangerth@ices.utexas.edu>, Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>, <gcc-bugs@gcc.gnu.org>, <lloyd@acm.jhu.edu>, <gcc-gnats@gcc.gnu.org> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 13:14:22 -0400 I can reproduce it with `GNU assembler 2.11.93.0.2 20020207' tough so it looks like it binutils fault but it has already been fixed. Thanks, Andrew Pinski On Tuesday, May 20, 2003, at 13:08 US/Eastern, Andrew Pinski wrote: > Mine is the top of the tree from the fsf's tree: > GNU assembler 2.14.90 20030520 > > Thanks, > Andrew Pinski > > On Tuesday, May 20, 2003, at 13:05 US/Eastern, Wolfgang Bangerth wrote: > >> >>> Feeding this assembler file into gcc 3.2 on an Intel box works for me >>> and the program doesn't crash! This might mean that we have an >>> assembler/binutils problem here. >> >> Whereas if I do the same, it crashes. So you seem to have a point :-) >> >> My binutils are >> 2.11.92.0.10 20011021 (SuSE) >> (this is what SuSE shipped with 8.0). What do you have? >> >> W. >> >> ---------------------------------------------------------------------- >> --- >> Wolfgang Bangerth email: >> bangerth@ices.utexas.edu >> www: >> http://www.ices.utexas.edu/~bangerth/ >> >> >> >> > > >
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Wolfgang Bangerth <bangerth@ices.utexas.edu> To: Andrew Pinski <pinskia@physics.uc.edu> Cc: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>, <gcc-bugs@gcc.gnu.org>, <lloyd@acm.jhu.edu>, <gcc-gnats@gcc.gnu.org> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 14:10:17 -0500 (CDT) > I can reproduce it with `GNU assembler 2.11.93.0.2 20020207' tough so > it looks like it binutils fault but it has already been fixed. So what do we do with this, then? Since we silently generate non-working code, I'd prefer gcc work around the problem, but then I'm not in a position to contribute anything reasonable to this aim... W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Andrew Pinski <pinskia@physics.uc.edu> To: Wolfgang Bangerth <bangerth@ices.utexas.edu> Cc: Andrew Pinski <pinskia@physics.uc.edu>, Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>, <gcc-bugs@gcc.gnu.org>, <lloyd@acm.jhu.edu>, <gcc-gnats@gcc.gnu.org> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 15:19:43 -0400 Here is the differences between -O2 (works ---) and -O3 (does not work +++): --- testpic.O2.s Tue May 20 15:12:01 2003 +++ testpic.s Tue May 20 15:12:16 2003 @@ -12,13 +12,13 @@ .globl _Z5get_xv .type _Z5get_xv, @function _Z5get_xv: - call __i686.get_pc_thunk.cx - addl $_GLOBAL_OFFSET_TABLE_, %ecx + call __i686.get_pc_thunk.ax + addl $_GLOBAL_OFFSET_TABLE_, %eax pushl %ebp - movl i@GOT(%ecx), %eax + movl i@GOT(%eax), %edx movl %esp, %ebp popl %ebp - movl (%eax), %eax + movl (%edx), %eax ret .size _Z5get_xv, .-_Z5get_xv .align 2 @@ -28,26 +28,26 @@ main: pushl %ebp movl %esp, %ebp - leal -8(%ebp), %edx + leal -8(%ebp), %eax pushl %ebx subl $4, %esp andl $-16, %esp call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx - movl i@GOT(%ebx), %eax - movl %edx, (%eax) + movl i@GOT(%ebx), %ecx + movl %eax, (%ecx) call _Z5get_xv@PLT movl -4(%ebp), %ebx xorl %eax, %eax leave ret .size main, .-main - .section .gnu.linkonce.t.__i686.get_pc_thunk.cx,"ax",@progbits -.globl __i686.get_pc_thunk.cx - .hidden __i686.get_pc_thunk.cx - .type __i686.get_pc_thunk.cx, @function -__i686.get_pc_thunk.cx: - movl (%esp), %ecx + .section .gnu.linkonce.t.__i686.get_pc_thunk.ax,"ax",@progbits +.globl __i686.get_pc_thunk.ax + .hidden __i686.get_pc_thunk.ax + .type __i686.get_pc_thunk.ax, @function +__i686.get_pc_thunk.ax: + movl (%esp), %eax ret .section .gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits .globl __i686.get_pc_thunk.bx looks like putting the pc_thunk into eax is the problem. Thanks, Andrew Pinski On Tuesday, May 20, 2003, at 15:10 US/Eastern, Wolfgang Bangerth wrote: > >> I can reproduce it with `GNU assembler 2.11.93.0.2 20020207' tough so >> it looks like it binutils fault but it has already been fixed. > > So what do we do with this, then? Since we silently generate > non-working > code, I'd prefer gcc work around the problem, but then I'm not in a > position to contribute anything reasonable to this aim... > > W. > > ----------------------------------------------------------------------- > -- > Wolfgang Bangerth email: > bangerth@ices.utexas.edu > www: > http://www.ices.utexas.edu/~bangerth/ > > > >
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Andrew Pinski <pinskia@physics.uc.edu> To: Andrew Pinski <pinskia@physics.uc.edu> Cc: Wolfgang Bangerth <bangerth@ices.utexas.edu>, Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>, <gcc-bugs@gcc.gnu.org>, <lloyd@acm.jhu.edu>, <gcc-gnats@gcc.gnu.org> Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 15:28:18 -0400 The differences in the rtl shows up in testpic.cc.30.rnreg. The work around in this case is to run with -fno-rename-registers, but this might not work in all cases. Thanks, Andrew Pinski
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: Janis Johnson <janis187@us.ibm.com> To: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, lloyd@acm.jhu.edu, nobody@gcc.gnu.org, ebotcazou@libertysurf.fr Cc: Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Tue, 20 May 2003 15:32:32 -0700 The pc_thunk started going into %eax with this patch: > 2003-03-12 Eric Botcazou <ebotcazou@libertysurf.fr> > > PR optimization/9888 > * config/i386/i386.md (jcc_1): Fix range. > (jcc_2): Likewise. > (jump): LIkewise. > (doloop_end_internal): Likewise. > > 2003-03-12 Eric Botcazou <ebotcazou@libertysurf.fr> > > PR optimization/9888 > * config/i386/i386.md (movsi_1): Remove special alternatives > for %eax register. > (movsi_1_nointernunit): Likewise. > (movhi_1): Likewise. > * config/i386/i386.c (memory_address_length): Do not use > short displacement when there is no base. > (ix86_attr_length_address_default): Handle LEA instructions. This was tested using Wolfgang's smaller testcase and searching for '_GLOBAL_OFFSET_TABLE_, %eax' in the .s file. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10877
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> To: Wolfgang Bangerth <bangerth@ices.utexas.edu> Cc: Andrew Pinski <pinskia@physics.uc.edu>, gcc-bugs@gcc.gnu.org, lloyd@acm.jhu.edu, gcc-gnats@gcc.gnu.org Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Wed, 21 May 2003 10:30:33 +0200 On Tue, May 20, 2003 at 12:05:35PM -0500, Wolfgang Bangerth wrote: > > > Feeding this assembler file into gcc 3.2 on an Intel box works for me > > and the program doesn't crash! This might mean that we have an > > assembler/binutils problem here. > > Whereas if I do the same, it crashes. So you seem to have a point :-) > > My binutils are > 2.11.92.0.10 20011021 (SuSE) > (this is what SuSE shipped with 8.0). What do you have? Mine is 2.12.90.0.15 20020717 (SuSE) and it works with this version. regards Christian -- THAT'S ALL FOLKS!
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> To: Eric Botcazou <ebotcazou@libertysurf.fr> Cc: janis187@us.ibm.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, lloyd@acm.jhu.edu Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Wed, 21 May 2003 13:15:13 +0200 On Wed, May 21, 2003 at 10:42:30AM +0200, Eric Botcazou wrote: > Is it illegal for the pc_thunk to go into %eax instead of %ecx in that case? I don't know but there are apparently some gas/ld versions that make a mess of it (see the rest of this thread). Even if it is a gas Bug we may want to work around it. regards Christian -- THAT'S ALL FOLKS!
The following reply was made to PR optimization/10877; it has been noted by GNATS. From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> To: Wolfgang Bangerth <bangerth@ices.utexas.edu>, ebotcazou@libertysurf.fr Cc: Andrew Pinski <pinskia@physics.uc.edu>, gcc-bugs@gcc.gnu.org, lloyd@acm.jhu.edu, gcc-gnats@gcc.gnu.org Subject: Re: optimization/10877: [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 Date: Wed, 21 May 2003 14:39:38 +0200 [ Added Eric to cc because his patch might have triggered this gas bug. ] On Tue, May 20, 2003 at 12:05:35PM -0500, Wolfgang Bangerth wrote: > > Feeding this assembler file into gcc 3.2 on an Intel box works for me > > and the program doesn't crash! This might mean that we have an > > assembler/binutils problem here. > > Whereas if I do the same, it crashes. So you seem to have a point :-) This is definitely a gas Bug! The problem is the following instruction: addl $_GLOBAL_OFFSET_TABLE_, %eax This tells the assembler that we want the difference between the adress of this addl instruction and the start of the global offset table to be added to %eax. When translating this request into relocation records an R_386_GOTPC relocation is used. However, this relocation calculates the difference between the place where the relocation takes place and the start of the global offset table. Hence the assembler must add an addend to fix up the difference between the address of the addl instruction and the address of its immediate operand (the latter is the place of the relocation). Now in the %eax case gas emmits the 0x05 opcode for addl imm32,%eax with a length of 1 byte. If the register isn't %eax the assembler has to use the longer 0x81 0xc3 opcode. Both opcodes are followed by the immediate 32bit Operand. I.e. if %eax is used the addend for the R_386_GOTPC relocation must be 1 but for all other registers it must be 2 due to the different length of the opcode. This is what some gas versions seem to get wrong. So what should we do with this report? Do we want to work around this bug in gcc or should we close it and tell people to upgrade binutils. The bug is fixed at least since 2.12.90.0.15 20020717 (SuSE). regards Christian -- THAT'S ALL FOLKS!