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
GCC 3.3 miscompiles what is (AFAIK) valid C++ code if it is compiled with -O3 -fPIC on x86. The code in question is attached. I have the following information: $ g++-3.3 -v Reading specs from /usr/local/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Configured with: ../gcc-3.3/configure --prefix=/usr/local/gcc-3.3 --enable-threads Thread model: posix gcc version 3.3 The code is accepted by GCC 2.95.3, 3.0.4, 3.1, and 3.2. With all of these versions, the code works correctly with -O3 -fPIC (and various other combinations of -O and -fPIC). The code works with 3.3 if -O2 or lower is specified, or if -O3 without -fPIC/-fpic is used. One interesting thing is that if the variable local_foo is declared as: static foo* local_foo; then it works. It also doesn't work if local_foo is declared as a non-static global (rather than in an anonymous namespace), presumably because anonymous namespace members aren't (IIRC) linked as static in GCC. I only have 3.2, so it's possible this was introduced in later 3.2 versions rather than the 3.3 branch. BTW, I've checked, and the resulting binary does use the gcc 3.3 versions of libgcc and libstdc++, so it's not that. Release: 3.3 Environment: RedHat 7.3, AMD Athlon, glibc 2.2.5, kernel 2.4.19, binutils 2.11.93.0.2 How-To-Repeat: Here is exactly what I'm seeing. This is with a printf that runs right before we exit from main; the version attached has the include of <stdio.h> and the printf call commented out. $ g++-3.3 -O3 -fPIC gccbug.cpp $ ./a.out Segmentation fault $ g++-3.3 -O2 -fPIC gccbug.cpp $ ./a.out I guess we didn't crash $ g++-3.3 -O3 gccbug.cpp $ ./a.out I guess we didn't crash $ g++-2.95.3 -O3 -fPIC gccbug.cpp $ ./a.out I guess we didn't crash $ g++-3.0.4 -O3 -fPIC gccbug.cpp $ ./a.out I guess we didn't crash $ g++-3.1 -O3 -fPIC gccbug.cpp $ ./a.out I guess we didn't crash $ g++-3.2 -O3 -fPIC gccbug.cpp $ ./a.out I guess we didn't crash
State-Changed-From-To: open->analyzed 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.
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/
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)"
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/
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 13:08:53 -0400 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/ > > > >
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/ >> >> >> >> > > >
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/
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/ > > > >
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
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
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!
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!
From: Eric Botcazou <ebotcazou@libertysurf.fr> To: janis187@us.ibm.com Cc: 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 10:42:30 +0200 > 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. Is it illegal for the pc_thunk to go into %eax instead of %ecx in that case? -- Eric Botcazou
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!
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!
Should we have a workaround for the gas bug or should we change the requirements for gas to higher?
I don't see how we could devise a robust workaround: it is my understanding that the register allocator is free to assign any GP register to the pc_thunk. But you might want to ask the maintainer of the x86 port.
Subject: Re: [Bug optimization/10877] [3.3/3.4 regression] miscompilation with -O3 -fPIC on x86 > ------- Additional Comments From ebotcazou@gcc.gnu.org 2003-05-25 06:09 ------- > I don't see how we could devise a robust workaround: it is my understanding that > the register allocator is free to assign any GP register to the pc_thunk. There's no reason I shouldnt' believe this. But we then need to document the requirement on newer binutils, possibly pointing to this particular PR. Would you mind, or...? W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
I was not involved in the analysis phase of this bug so I don't think I'm the right person to submit a patch.
*** Bug 11152 has been marked as a duplicate of this bug. ***
This is a documentation bug because a binutils (gas) bug that causes this problem.
I've traced the failure to between binutils 2.13 and 2.13.1. 2.13 fails, 2.13.1 works with this testcase.
*** Bug 11438 has been marked as a duplicate of this bug. ***
Subject: Bug 10877 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: wilson@gcc.gnu.org 2003-07-11 23:08:50 Modified files: gcc : ChangeLog gcc/doc : install.texi Log message: Patch from Dara Hazeghi. PR optimization/10877 * doc/install.tex: Update required binutils for i?86-*-linux* Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.651&r2=1.16114.2.652 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/install.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.151.2.44&r2=1.151.2.45
A newer binutils, 13.1 is required now and this is documented for 3.3.1 and the mainline, so closing as fixed.
*** Bug 12079 has been marked as a duplicate of this bug. ***
*** Bug 12484 has been marked as a duplicate of this bug. ***
*** Bug 12708 has been marked as a duplicate of this bug. ***
*** Bug 13476 has been marked as a duplicate of this bug. ***