[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-13 23:02:09 UTC --- Created attachment 26318 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26318 test findenv Test of findenv found in http://www.opensource.apple.com/source/Libc/Libc-498.1.7/stdlib/getenv-fbsd.c . Debugging seesion: (gdb) b my_findenv Breakpoint 1 at 0x187b: file pr51784_1.c, line 62. (gdb) run Starting program: /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out Breakpoint 1, my_findenv (name=0x356c GCOV_PREFIX_STRIP, offset=0xbfffd93c, environ=0xbfffd9b4) at pr51784_1.c:62 62} (gdb) p/x _NSGetEnviron() $1 = 0x40a8 (gdb) p/x *_NSGetEnviron() $2 = 0xbfffd9b4 (gdb) p/x **_NSGetEnviron() Cannot access memory at address 0xbfffd9b4 (gdb) p *environ $3 = 0xbfffdb58 PATH=/opt/gcc/gcc4.7a/bin/:/sw64/bin:/sw64/sbin:/opt/gcc/gcc4.7a/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin:/Users/dominiq/geant4.9/bin/Darwin-g++:/usr/t... (gdb) p environ[0] $10 = 0xbfffdb58 PATH=/opt/gcc/gcc4.7a/bin/:/sw64/bin:/sw64/sbin:/opt/gcc/gcc4.7a/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin:/Users/dominiq/geant4.9/bin/Darwin-g++:/usr/t... ... (gdb) p environ[69] $79 = 0xbfffed25 GCOV_PREFIX_STRIP=foo (gdb) c Continuing. foo Program exited normally.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-13 23:11:40 UTC --- Created attachment 26319 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26319 patch for libgcc/libgcov.c to debug findenv Patch to use the findenv in http://www.opensource.apple.com/source/Libc/Libc-498.1.7/stdlib/getenv-fbsd.c . Debugging session [macbook] f90/bug% /opt/gcc/gcc4.7p/bin/gcc pr44777_db.c -fprofile-generate -D_PROFILE_GENERATE -m32 -g -save-temps [macbook] f90/bug% gdb a.out ... (gdb) b 25 Breakpoint 1 at 0x28bb: file pr44777_db.c, line 25. (gdb) run Starting program: /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out Breakpoint 1, y (a=0) at pr44777_db.c:25 25goto xlab; (gdb) p/x _NSGetEnviron() $1 = 0x50a8 (gdb) p/x *_NSGetEnviron() $2 = 0xbfffd9b4 (gdb) p/x **_NSGetEnviron() Cannot access memory at address 0xbfffd9b4 (gdb) stepi 0x28bd25goto xlab; (gdb) stepi 0x28c325goto xlab; (gdb) stepi 0x28c5 in y (a=-1881144004) at pr44777_db.c:25 25goto xlab; (gdb) stepi 0x28c825goto xlab; (gdb) stepi 0x29a2 in x (a=-1881144004) at pr44777_db.c:29 29 y (a); (gdb) stepi 0x29a5 in x (a=1) at pr44777_db.c:29 29 y (a); (gdb) stepi 0x29ab29 y (a); (gdb) stepi 0x29ae29 y (a); (gdb) stepi 0x29b129 y (a); (gdb) stepi 0x29b429 y (a); (gdb) stepi 0x29b729 y (a); (gdb) stepi 0x29bd29 y (a); (gdb) p/x _NSGetEnviron() $3 = 0x50a8 (gdb) p/x *_NSGetEnviron() $4 = 0xbfffd9b4 (gdb) p/x **_NSGetEnviron() Cannot access memory at address 0xbfffd9b4 (gdb) x/x 0x29bd 0x29bd x+162:0x89084189 (gdb) stepi 0x29c029 y (a); (gdb) p/x _NSGetEnviron() $5 = 0x50a8 (gdb) p/x *_NSGetEnviron() $6 = 0xc000d9b4 - address changed from 0xbfffd9b4 to 0xc000d9b4 (gdb) p/x **_NSGetEnviron() Cannot access memory at address 0xc000d9b4 (gdb) x/x 0x29c0 0x29c0 x+165:0x8b0c5189 (gdb) stepi 31 return a; (gdb) stepi 0x29c631 return a; (gdb) x/x 0x29c6 0x29c6 x+171:0x2857838d (gdb) stepi 0x29cc31 return a; (gdb) x/x 0x29cc 0x29cc x+177:0x8b14508b (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x3198 in my_findenv (name=0x45cf GCOV_PREFIX_STRIP, offset=0xbfffd79c, environ=0xc000d9b4) at ../../../../p_work/libgcc/libgcov.c:296 296for (p = environ; (cp = *p) != NULL; ++p) { (gdb) c Continuing. Program terminated with signal SIGSEGV, Segmentation fault. pr44777_db.c is the original test with '#define DEPTH 1000' replaced with '#define DEPTH 1'. If I am not mistaken, findenv crashes because the address for environ has been changed from 0xbfffd9b4 to 0xc000d9b4 at the end of the proc 'x'.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-13 23:35:13 UTC --- (In reply to comment #14) (gdb) stepi 0x29bd29 y (a); (gdb) p/x _NSGetEnviron() $3 = 0x50a8 (gdb) p/x *_NSGetEnviron() $4 = 0xbfffd9b4 (gdb) p/x **_NSGetEnviron() Cannot access memory at address 0xbfffd9b4 (gdb) x/x 0x29bd 0x29bd x+162:0x89084189 (gdb) stepi 0x29c029 y (a); (gdb) p/x _NSGetEnviron() $5 = 0x50a8 (gdb) p/x *_NSGetEnviron() $6 = 0xc000d9b4 - address changed from 0xbfffd9b4 to 0xc000d9b4 disas x would be interesting here to find out what insn is at 0x29c0 and what is around that. If I am not mistaken, findenv crashes because the address for environ has been changed from 0xbfffd9b4 to 0xc000d9b4 at the end of the proc 'x'.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-13 23:46:47 UTC --- disas x would be interesting here to find out what insn is at 0x29c0 and what is around that. 0x291b +0:push %ebp 0x291c +1:mov%esp,%ebp 0x291e +3:push %edi 0x291f +4:push %esi 0x2920 +5:push %ebx 0x2921 +6:sub$0x3c,%esp 0x2924 +9:call 0x2660 0x2929 +14:lea-0x18(%ebp),%eax 0x292c +17:mov%eax,-0x24(%ebp) 0x292f +20:mov%esp,-0x20(%ebp) 0x2932 +23:lea0x2833(%ebx),%eax 0x2938 +29:mov(%eax),%eax 0x293a +31:lea0x282f(%ebx),%edx 0x2940 +37:mov(%edx),%edx 0x2942 +39:mov%edx,0x10(%esp) 0x2946 +43:lea-0xe(%ebx),%edx 0x294c +49:mov%edx,0xc(%esp) 0x2950 +53:movl $0x0,0x4(%esp) 0x2958 +61:movl $0x0,0x8(%esp) 0x2960 +69:mov%eax,(%esp) 0x2963 +72:call 0x4420 __gcov_indirect_call_profiler 0x2968 +77:lea0x282f(%ebx),%eax 0x296e +83:movl $0x0,(%eax) 0x2974 +89:lea0x2857(%ebx),%eax 0x297a +95:mov0x4(%eax),%edx 0x297d +98:mov(%eax),%eax 0x297f +100:add$0x1,%eax 0x2982 +103:adc$0x0,%edx 0x2985 +106:lea0x2857(%ebx),%ecx 0x298b +112:mov%eax,(%ecx) 0x298d +114:mov%edx,0x4(%ecx) 0x2990 +117:lea-0x24(%ebp),%eax 0x2993 +120:mov0x8(%ebp),%edx 0x2996 +123:mov%edx,(%esp) 0x2999 +126:mov%eax,%ecx 0x299b +128:call 0x283e y 0x29a0 +133:jmp0x29c3 x+168 0x29a2 +135:lea0x18(%ebp),%ebp = 0x29a5 +138:lea0x2857(%ebx),%eax 0x29ab +144:mov0xc(%eax),%edx 0x29ae +147:mov0x8(%eax),%eax 0x29b1 +150:add$0x1,%eax 0x29b4 +153:adc$0x0,%edx 0x29b7 +156:lea0x2857(%ebx),%ecx 0x29bd +162:mov%eax,0x8(%ecx) 0x29c0 +165:mov%edx,0xc(%ecx) 0x29c3 +168:mov0x8(%ebp),%esi 0x29c6 +171:lea0x2857(%ebx),%eax 0x29cc +177:mov0x14(%eax),%edx 0x29cf +180:mov0x10(%eax),%eax 0x29d2 +183:add$0x1,%eax 0x29d5 +186:adc$0x0,%edx 0x29d8 +189:lea0x2857(%ebx),%ecx 0x29de +195:mov%eax,0x10(%ecx) 0x29e1 +198:mov%edx,0x14(%ecx) 0x29e4 +201:mov%esi,%eax 0x29e6 +203:add$0x3c,%esp 0x29e9 +206:pop%ebx 0x29ea +207:pop%esi 0x29eb +208:pop%edi 0x29ec +209:pop%ebp 0x29ed +210:ret and the registers evolution is (gdb) stepi 0x29b429 y (a); (gdb) info registers eax0xdb52c000-615333888 ecx0xbfffd934-1073751756 edx0xbfff49151 ebx0x284b10315 esp0xbfffd9100xbfffd910 ebp0xbfffd9580xbfffd958 esi0x51a020896 edi0x00 eip0x29b40x29b4 x+153 eflags 0x396[ PF AF SF TF IF ] cs 0x1723 ss 0xbfffd934-1073751756 ds 0x1f31 es 0x1f31 fs 0x00 gs 0x3755 (gdb) stepi 0x29b729 y (a); (gdb) info registers eax0xdb52c000-615333888 ecx0xbfffd934-1073751756 edx0xbfff49151 ebx0x284b10315 esp0xbfffd9100xbfffd910 ebp0xbfffd9580xbfffd958 esi0x51a020896 edi0x00 eip0x29b70x29b7 x+156 eflags 0x306[ PF TF IF ] cs 0x1723 ss 0xbfffd934-1073751756 ds 0x1f31 es 0x1f31 fs 0x00 gs 0x3755 (gdb) stepi 0x29bd29 y (a); (gdb) info registers eax0xdb52c000-615333888 ecx0x50a220642 edx0xbfff49151 ebx0x284b10315 esp0xbfffd9100xbfffd910 ebp0xbfffd9580xbfffd958 esi0x51a020896 edi0x00 eip0x29bd0x29bd x+162 eflags 0x306[ PF TF IF ] cs 0x1723 ss 0x50a220642 ds 0x1f31 es 0x1f31 fs 0x00 gs 0x3755 (gdb) stepi 0x29c029 y (a); (gdb) info registers eax0xdb52c000-615333888 ecx0x50a220642 edx0xbfff49151 ebx0x284b10315 esp0xbfffd9100xbfffd910 ebp0xbfffd9580xbfffd958 esi0x51a020896 edi0x00 eip
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-14 00:38:18 UTC --- Sounds like i?86-darwin target bug. The %ebx value is wrong, should be 0x2929 instead (i.e. the point after call __x86.get_pc_thunk.bx in x, but most probably is the point after call __x86.get_pc_thunk.bx in y instead. Seems on Darwin %ebx (or whatever the PIC register is) contains the address after the call to the get_pc_thunk, and thus each function has it different and therefore non-local goto on i?86-darwin must restore %ebx, but clearly it doesn't. On i?86-linux this bug doesn't exist, because %ebx there is the address of _GLOBAL_OFFSET_TABLE_ - nonlocal goto is only possible within the same CU and thus will have the same _GOT_ value, so nothing needs to be restored. Similarly on x86_64-linux, where there is no PIC pointer, but %rip addressing is used. Doesn't look like a regression to me though, if the above is the case, then probably darwin never supported nonlocal gotos in pic code (which is the default there).
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-14 00:54:05 UTC --- Probably for TARGET_MACHO !TARGET_64BIT flag_pic you want to define nonlocal_goto_receiver pattern that would compute the right PIC pointer value at that point (not sure if the assembler/linker would be happy by doing something like call ___x86.get_pc_thunk.bx L1: add $(L002$pb-L1), %ebx in the nonlocal goto receiver.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-11 08:20:27 UTC --- (In reply to comment #8) The main difference between r182587 and r182980 with -m32 is @@ -50,18 +50,26 @@ L3: movl4(%eax), %esp jmp*%edx L2: +leal___gcov0_y.1704-L001$pb(%ebx), %eax +movl28(%eax), %edx +movl24(%eax), %eax +addl$1, %eax +adcl$0, %edx +leal___gcov0_y.1704-L001$pb(%ebx), %esi +movl%eax, 24(%esi) +movl%edx, 28(%esi) movl8(%ebp), %eax subl$1, %eax movl%eax, (%esp) call_y.1704 leal___gcov0_y.1704-L001$pb(%ebx), %eax -movl28(%eax), %edx -movl24(%eax), %eax +movl36(%eax), %edx +movl32(%eax), %eax addl$1, %eax adcl$0, %edx leal___gcov0_y.1704-L001$pb(%ebx), %ecx -movl%eax, 24(%ecx) -movl%edx, 28(%ecx) +movl%eax, 32(%ecx) +movl%edx, 36(%ecx) leal-8(%ebp), %esp popl%ebx LCFI3: There is no bug in that, we record one more counter starting with 182920, but there is also the additional space reserved for it in the array.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-apple-darwin10 |x86_64-apple-darwin* Host|x86_64-apple-darwin10 |x86_64-apple-darwin* Build|x86_64-apple-darwin10 |x86_64-apple-darwin* --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-11 21:10:03 UTC --- The test passes if I revert r182920. Dominique, please see why __findenv segfaults. (1) My knowledge of gdb (and C) is very shallow, (2) I don't have access to the source for __findenv (3) I don't know to what I'ld look for. Stepping through __findenv I reach Program received signal SIGSEGV, Segmentation fault. 0x900949d9 in __findenv () from /usr/lib/libSystem.B.dylib (gdb) info registers eax0x00 ecx0x9009497b-1878439557 edx0x1117 ebx0x236a9066 esp0xbfffd7980xbfffd798 ebp0xbfffd7a80xbfffd7a8 esi0xc000d9e0-1073686048 edi0x369b13979 eip0x900949d90x900949d9 __findenv+85 eflags 0x10306[ PF TF IF RF ] cs 0x1723 ss 0x9009497b-1878439557 ds 0x1f31 es 0x1f31 fs 0x00 gs 0x3755 With r182920 reverted I see (gdb) stepi 0x900949d9 in __findenv () from /usr/lib/libSystem.B.dylib (gdb) info registers eax0x00 ecx0x9009497b-1878439557 edx0x1117 ebx0x236a9066 esp0xbfffd7980xbfffd798 ebp0xbfffd7a80xbfffd7a8 esi0xbfffd9e0-1073751584 edi0x369b13979 eip0x900949d90x900949d9 __findenv+85 eflags 0x306[ PF TF IF ] cs 0x1723 ss 0x9009497b-1878439557 ds 0x1f31 es 0x1f31 fs 0x00 gs 0x3755 (gdb) stepi 0x900949db in __findenv () from /usr/lib/libSystem.B.dylib (gdb) info registers eax0x00 ecx0x9009497b-1878439557 edx0x1117 ebx0xbfffdb80-1073751168 esp0xbfffd7980xbfffd798 ebp0xbfffd7a80xbfffd7a8 esi0xbfffd9e0-1073751584 edi0x369b13979 eip0x900949db0x900949db __findenv+87 eflags 0x306[ PF TF IF ] cs 0x1723 ss 0x9009497b-1878439557 ds 0x1f31 es 0x1f31 fs 0x00 gs 0x3755 Note that the test fails also on powerpc-apple-darwin9 with both -m32 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x3f50 0x1ee0 in x () at /opt/gcc/work/gcc/testsuite/gcc.dg/tree-prof/pr44777.c:29 29 y (a); (gdb) bt #0 0x1ee0 in x () at /opt/gcc/work/gcc/testsuite/gcc.dg/tree-prof/pr44777.c:29 #1 0x2044 in main () at /opt/gcc/work/gcc/testsuite/gcc.dg/tree-prof/pr44777.c:39 and -m64 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00023028 0x00011848 in gcov_exit () at ../../../../work/libgcc/libgcov.c:302 302 if (gfi_ptr gfi_ptr-key != gi_ptr) (gdb) bt #0 0x00011848 in gcov_exit () at ../../../../work/libgcc/libgcov.c:302 #1 0x0001174c in gcov_exit () at ../../../../work/libgcc/libgcov.c:274 Previous frame identical to this frame (gdb could not unwind past this frame) for gcc 4.4.6, 4.5.3, 4.6.2, and trunk. It passes with -m32 for 4.3.4 20090511 for GNAT GPL 2009 (20090511). The failures seem different: should I open another PR?
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org 2012-01-11 21:31:19 UTC --- we have the source - it looks like inherited stdlib from FreeBSD. http://www.opensource.apple.com/source/Libc/Libc-498.1.7/stdlib/getenv-fbsd.c however, more debugging is going to be needed.. I guess we're going to have to look at what is set up for at exit .. and if that's getting broken (or this is revealing a lingering bug).
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-01-09 Ever Confirmed|0 |1 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-09 12:02:44 UTC --- Dominique, please see why __findenv segfaults.
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-08 12:10:02 UTC --- Created attachment 26269 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26269 assembler for r182980 with -m32 Compiled with -O0 -m32 -fprofile-generate [macbook] f90/bug% /opt/gcc/gcc4.7a/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc/gcc4.7a/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.7a/libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin10.8.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc4.7a --enable-languages=c,c++,fortran,ada,lto --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-cloog=/opt/mp --enable-cloog-backend=isl --enable-lto Thread model: posix gcc version 4.7.0 20120107 (experimental) [trunk revision 182980p4] (GCC)
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-08 12:12:23 UTC --- Created attachment 26270 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26270 assembler for r182587 with -m32 Compiled with -O0 -m32 -fprofile-generate [macbook] f90/bug% /opt/gcc/gcc4.7a-182587/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc/gcc4.7a-182587/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.7a-182587/bin/../libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin10.8.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc4.7a --enable-languages=c,c++,ada,lto --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-cloog=/opt/mp --enable-cloog-backend=isl --enable-lto Thread model: posix gcc version 4.7.0 20111221 (experimental) [trunk revision 182587p3] (GCC)
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-08 12:13:42 UTC --- Created attachment 26271 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26271 assembler for r182980 with -m64 (default) Compiled with -O0 -fprofile-generate
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-08 12:14:55 UTC --- Created attachment 26272 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26272 assembler for r182587 with -m64 (default) Compiled with -O0 -fprofile-generate
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-08 12:15:46 UTC --- Created attachment 26273 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26273 preprocessed file compiled with -O0 -fprofile-generate
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-08 12:18:42 UTC --- The main difference between r182587 and r182980 with -m32 is @@ -50,18 +50,26 @@ L3: movl4(%eax), %esp jmp*%edx L2: +leal___gcov0_y.1704-L001$pb(%ebx), %eax +movl28(%eax), %edx +movl24(%eax), %eax +addl$1, %eax +adcl$0, %edx +leal___gcov0_y.1704-L001$pb(%ebx), %esi +movl%eax, 24(%esi) +movl%edx, 28(%esi) movl8(%ebp), %eax subl$1, %eax movl%eax, (%esp) call_y.1704 leal___gcov0_y.1704-L001$pb(%ebx), %eax -movl28(%eax), %edx -movl24(%eax), %eax +movl36(%eax), %edx +movl32(%eax), %eax addl$1, %eax adcl$0, %edx leal___gcov0_y.1704-L001$pb(%ebx), %ecx -movl%eax, 24(%ecx) -movl%edx, 28(%ecx) +movl%eax, 32(%ecx) +movl%edx, 36(%ecx) leal-8(%ebp), %esp popl%ebx LCFI3:
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-07 21:33:27 UTC --- Looks like an OS bug, not GCC bug, if getenv segfaults...
[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-01-07 22:40:07 UTC --- Looks like an OS bug, not GCC bug, if getenv segfaults... Well, revision 182587 uses the same OS and does not segfault. Also 'exit (0)' is used in many tests that pass.