[Bug rtl-optimization/36321] Optimization higher or equal to -O2 produce wrong code
--- Comment #5 from nightstrike at gmail dot com 2008-05-25 06:54 --- I am regtesting it now. Note that it will take a very long time to complete (several days). This does apply to 4.3 and 4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
[Bug bootstrap/36324] New: Bootstrap comparison failure with BOOT_CFLAGS=-pg (trunk r135848)
Trying to create a compiler that can be run in gprof, $ ../../SOURCES/gcc/configure --prefix=/opt/gnat/fsf/wavefront \ --enable-languages=c,c++,ada --enable-debug $ make BOOT_CFLAGS='-pg' rm -f stage_current make[3]: Leaving directory `/usr/src/packages/BUILD/build-gcc' Comparing stages 2 and 3 warning: ./cc1plus-checksum.o differs warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./c-pch.o differs ./c-objc-common.o differs ./c-decl.o differs ./c-semantics.o differs ./c-dump.o differs ./attribs.o differs ./c-cppbuiltin.o differs ./c-pretty-print.o differs ./c-parser.o differs ./c-omp.o differs ./c-lang.o differs ./c-typeck.o differs ./c-lex.o differs ./c-common.o differs ./build/genautomata.o differs ./build/genmodes.o differs ./build/gcov-iov.o differs ./build/gengtype-lex.o differs ./build/genflags.o differs ./build/genemit.o differs ./build/rtl.o differs ./build/genopinit.o differs ./build/read-rtl.o differs ./build/genextract.o differs ./build/errors.o differs ./build/ggc-none.o differs ./build/genattr.o differs ./build/gencodes.o differs ./build/genconstants.o differs ./build/genmddeps.o differs ./build/print-rtl.o differs ./build/vec.o differs ./build/genconditions.o differs ./build/genoutput.o differs ./build/gengenrtl.o differs ./build/gencondmd.o differs ./build/gensupport.o differs ./build/gencheck.o differs ./build/genattrtab.o differs ./build/genpreds.o differs ./build/genpeep.o differs ./build/genconfig.o differs ./build/gengtype-parse.o differs ./build/min-insn-modes.o differs ./build/gengtype.o differs ./build/genrecog.o differs ./c-gimplify.o differs ./dummy-checksum.o differs ./c-format.o differs ./c-ppoutput.o differs ./stub-objc.o differs ./tree-mudflap.o differs ./c-aux-info.o differs ./tree-browser.o differs ./prefix.o differs ./c-pragma.o differs ./cppdefault.o differs ./c-incpath.o differs ./main.o differs ./c-opts.o differs ./c-convert.o differs ./c-errors.o differs make[2]: *** [compare] Error 1 Is this supposed to work? Thanks. -- Summary: Bootstrap comparison failure with BOOT_CFLAGS=-pg (trunk r135848) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliver dot kellogg at eads dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36324
[Bug fortran/36323] Inside an interface, gfortran does not know about selected_real_kind
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-24 22:49 --- Your program is invalid * * * INTERFACE FUNCTION F(X) RESULT (FUNCTION_VALUE) REAL(REAL_12), INTENT(IN) :: X Use either: a) REAL(SELECTED_REAL_KIND(P=12)), INTENT(IN) :: X b) IMPORT :: REAL_12 REAL(REAL_12) ... c) IMPORT REAL(REAL_12) ... The IMPORT statement (b and c) is part of Fortran 2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36323
[Bug fortran/36323] New: Inside an interface, gfortran does not know about selected_real_kind
FUNCTION AFUN (F, A) & RESULT (RESULT) IMPLICIT NONE INTEGER, PARAMETER :: REAL_12 = SELECTED_REAL_KIND(P=12) INTERFACE FUNCTION F(X) RESULT (FUNCTION_VALUE) REAL(REAL_12), INTENT(IN) :: X! REAL_12 not recognized REAL(REAL_12) :: FUNCTION_VALUE ! REAL_12 not recognized END FUNCTION F END INTERFACE REAL(REAL_12), INTENT(IN):: A! REAL_12 is recognized END FUNCTION AFUN -- Summary: Inside an interface, gfortran does not know about selected_real_kind Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: MyForumUsage at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36323
[Bug middle-end/36294] gcc exited and told me to report a bug (details follow)
--- Comment #6 from paulbeard at gmail dot com 2008-05-24 20:16 --- (In reply to comment #5) > GCC is running out of memory. > > Oh. I'll add a swapfile and see how that goes. > It still just grinds until I kill the process. I have since worked around this problem by installing the package, rather than building from source: I will leave the same information over the GNOME bugtracker. If I can provide any other information, let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
[Bug preprocessor/36320] Required diagnosis of syntax error missed
--- Comment #2 from tromey at gcc dot gnu dot org 2008-05-24 18:04 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-24 16:21:05 |2008-05-24 18:04:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320
[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code
--- Comment #4 from ubizjak at gmail dot com 2008-05-24 17:54 --- (In reply to comment #3) > Sorry, I missed to install the new compiler :} > Yes, it works, assembler looks now fine. Can you please regtest the patch on your target? BTW: Is this a regression for 4.3 and 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #8 from jaydub66 at gmail dot com 2008-05-24 17:52 --- I have a patch which can handle this test case, see http://gcc.gnu.org/ml/fortran/2008-05/msg00296.html It's not complete yet, and some details need to be fixed, but the basic functionality is there. I hope it can be committed to trunk quite soon. Cheers, Janus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-05-24 17:01 --- (In reply to comment #1) Sorry, I missed to install the new compiler :} Yes, it works, assembler looks now fine. Thanks, Kai .file "" .section .rdata,"dr" LC0: .ascii "%s %s\12\0" .text .p2align 4,,15 .globl _foo .def_foo; .scl2; .type 32; .endef _foo: pushq %rbp movq%rsp, %rbp movq%rsi, -16(%rbp) movq%rdi, -8(%rbp) movq%rbx, -24(%rbp) subq$64, %rsp call_strlen leal15(%rax,%rax,2), %ecx subq$32, %rsp leaq32(%rsp), %rsi movslq %ecx,%rdi leaq30(%rdi), %rdx andq$-16, %rdx movq%rdx, %rax call___chkstk movl$121, %edx leaq32(%rsp), %rbx leal-1(%rcx), %eax movl$2021161080, (%rsi) movb$0, 4(%rsi) movq%rbx, %rcx movslq %eax,%r8 call_memset leaqLC0(%rip), %rcx movq%rbx, %r8 movq%rsi, %rdx movb$0, -1(%rbx,%rdi) call_printf movq-24(%rbp), %rbx movq-16(%rbp), %rsi movq-8(%rbp), %rdi leave ret .def_strlen;.scl2; .type 32; .endef .def_memset;.scl2; .type 32; .endef .def_printf;.scl2; .type 32; .endef -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code
--- Comment #2 from ktietz at gcc dot gnu dot org 2008-05-24 16:36 --- (In reply to comment #1) > Can you try this patch: > > Index: i386.md > === > --- i386.md (revision 135849) > +++ i386.md (working copy) > @@ -19707,7 +19707,7 @@ > (set_attr "length" "5")]) > > (define_insn "allocate_stack_worker_64" > - [(set (match_operand:DI 0 "register_operand" "=a") > + [(set (match_operand:DI 0 "register_operand" "+a") > (unspec_volatile:DI [(match_dup 0)] UNSPECV_STACK_PROBE)) > (set (reg:DI SP_REG) (minus:DI (reg:DI SP_REG) (match_dup 0))) > (clobber (reg:DI R10_REG)) > I tried it. There is no difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
[Bug preprocessor/36320] Required diagnosis of syntax error missed
--- Comment #1 from tromey at gcc dot gnu dot org 2008-05-24 16:21 --- Confirmed. This seems like a weird design to me, but my reading of the standard text agrees with yours. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-24 16:21:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320
[Bug fortran/36322] New: ICE with PROCEDURE using a complicated interface
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4 The full program should be checked after fixing this problem. ==28722== Invalid read of size 4 ==28722==at 0x407597: gfc_is_compile_time_shape (array.c:2184) ==28722==by 0x46B11B: resolve_symbol (resolve.c:6811) ==28722==by 0x477326: traverse_ns (symbol.c:3014) ==28722==by 0x4659DF: resolve_types (resolve.c:9179) module other_fun use ISO_C_BINDING implicit none character, allocatable, save :: my_message(:) abstract interface function abstract_fun(x) use ISO_C_BINDING import my_message implicit none integer(C_INT) x(:) character(size(my_message),C_CHAR) abstract_fun(size(x)) end function abstract_fun end interface contains subroutine get_funloc(x) procedure(abstract_fun):: x end subroutine get_funloc end module other_fun -- Summary: ICE with PROCEDURE using a complicated interface Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
[Bug rtl-optimization/36321] Optimization higher or eqaul to -O2 produce wrong code
--- Comment #1 from ubizjak at gmail dot com 2008-05-24 16:03 --- Can you try this patch: Index: i386.md === --- i386.md (revision 135849) +++ i386.md (working copy) @@ -19707,7 +19707,7 @@ (set_attr "length" "5")]) (define_insn "allocate_stack_worker_64" - [(set (match_operand:DI 0 "register_operand" "=a") + [(set (match_operand:DI 0 "register_operand" "+a") (unspec_volatile:DI [(match_dup 0)] UNSPECV_STACK_PROBE)) (set (reg:DI SP_REG) (minus:DI (reg:DI SP_REG) (match_dup 0))) (clobber (reg:DI R10_REG)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
[Bug rtl-optimization/16967] Iterating gcse.c CPROP and PRE does not reach a fixed point
--- Comment #13 from steven at gcc dot gnu dot org 2008-05-24 15:37 --- This happens again on PPC. No test case yet. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
[Bug rtl-optimization/36321] New: Optimization higher or eqaul to -O2 produce wrong code
For the i386 stack probing feature there is a non-standard argument register %eax used for internal __chkstk call. If the code is translate with gcc with optimization level one or less, code is fine. For -O2 and higher, the argument %eax for __chkstk is optimized out. The following source is a short test-case for this: #include #include #include #include void foo(char *str) { int len = strlen ("ABCDE"); int len2 = len + strlen (str); char *a = (char *) alloca(len); char *b = (char *) alloca(len2*3); memset (a,'x',len-1); a[len-1]=0; memset (b,'y',len2*3-1); b [len2*3-1]=0; printf ("%s %s\n", a, b); } For optimization -O2 the following assembler is produced (I mark the bad code by !): .file "" .section .rdata,"dr" LC0: .ascii "%s %s\12\0" .text .p2align 4,,15 .globl _foo .def_foo; .scl2; .type 32; .endef _foo: pushq %rbp movq%rsp, %rbp movq%rsi, -16(%rbp) movq%rdi, -8(%rbp) movq%rbx, -24(%rbp) subq$64, %rsp call_strlen subq$32, %rsp ! leal15(%rax,%rax,2), %ecx leaq32(%rsp), %rsi movslq %ecx,%rdi call___chkstk movl$121, %edx leaq32(%rsp), %rbx leal-1(%rcx), %eax movl$2021161080, (%rsi) movb$0, 4(%rsi) movq%rbx, %rcx movslq %eax,%r8 call_memset leaqLC0(%rip), %rcx movq%rbx, %r8 movq%rsi, %rdx movb$0, -1(%rbx,%rdi) call_printf movq-24(%rbp), %rbx movq-16(%rbp), %rsi movq-8(%rbp), %rdi leave ret .def_strlen;.scl2; .type 32; .endef .def_memset;.scl2; .type 32; .endef .def_printf;.scl2; .type 32; .endef For optimization -O1 correct assembly is produced: .file "" .section .rdata,"dr" LC0: .ascii "%s %s\12\0" .text .globl _foo .def_foo; .scl2; .type 32; .endef _foo: pushq %rbp movq%rsp, %rbp movq%rbx, -24(%rbp) movq%rsi, -16(%rbp) movq%rdi, -8(%rbp) subq$96, %rsp movq%rcx, %rdi movl$0, %eax movq$-1, %rcx repne scasb notq%rcx leaq32(%rsp), %rsi leal12(%rcx,%rcx,2), %ecx movslq %ecx,%rdi leaq30(%rdi), %rax andq$-16, %rax call___chkstk leaq32(%rsp), %rbx movl$2021161080, (%rsi) movb$0, 4(%rsi) subl$1, %ecx movslq %ecx,%r8 movl$121, %edx movq%rbx, %rcx call_memset movb$0, -1(%rbx,%rdi) movq%rbx, %r8 movq%rsi, %rdx leaqLC0(%rip), %rcx call_printf movq-24(%rbp), %rbx movq-16(%rbp), %rsi movq-8(%rbp), %rdi leave ret .def_memset;.scl2; .type 32; .endef .def_printf;.scl2; .type 32; .endef -- Summary: Optimization higher or eqaul to -O2 produce wrong code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: 86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36321
[Bug rtl-optimization/34503] Issues with constant/copy propagation implementation in gcse.c
--- Comment #7 from steven at gcc dot gnu dot org 2008-05-24 14:31 --- I have found a test case for the issue mentioned in comment #4. And it comes from gcc itself: static int *free_phinodes[10 - 2]; /* was 'tree' */ static unsigned long free_phinode_count; void init_phinodes (void) { int i; for (i = 0; i < 10 - 2; i++) free_phinodes[i] = ((void *)0); free_phinode_count = 0 } When compiling this on powerpc-unknown-elf with r135815 and with the options "-O2 -fdump-rtl-gcse1-slim", I get the following RTL at the end of the GCSE pass: 37 NOTE_INSN_BASIC_BLOCK 36 NOTE_INSN_FUNCTION_BEG 39 r164:SI=high(`*.LANCHOR0') 40 r166:SI=r164:SI+low(`*.LANCHOR0') REG_DEAD: r164:SI REG_EQUAL: `*.LANCHOR0' 75 r153:SI=r166:SI REG_EQUAL: `*.LANCHOR0' 73 r165:SI=r166:SI+0x20 REG_DEAD: r167:SI REG_EQUAL: const(`*.LANCHOR0'+0x20) L46: 42 NOTE_INSN_BASIC_BLOCK 43 r156:SI=0x0 44 [r153:SI]=r156:SI REG_EQUAL: 0x0 45 r153:SI=r153:SI+0x4 71 r157:SI=r166:SI REG_EQUAL: `*.LANCHOR0' 50 r160:CC=cmp(r153:SI,r165:SI) REG_EQUAL: cmp(r153:SI,const(`*.LANCHOR0'+0x20)) 51 pc={(r160:CC!=0x0)?L46:pc} REG_DEAD: r160:CC REG_BR_PROB: 0x222e 52 NOTE_INSN_BASIC_BLOCK 56 [r157:SI+0x20]=r156:SI REG_DEAD: r157:SI REG_DEAD: r156:SI REG_EQUAL: 0x0 This is the dump *after* CPROP2, so the post-PRE-GCSE const/copy pass has run. Note the REG_EQUAL note on insn 71: "r157:SI=r166:SI {REG_EQUAL: `*.LANCHOR0'}". This is a reg-reg copy insn, but CPROP2 does not record the copy. Instead it records that r157 is equal to the REG_EQUAL note value. The result is that CPROP2 fails to copy propagate r166 into insn 56 (where r157 reaches and dies, so the copy propagation would eliminate r157). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503
[Bug fortran/36316] type mismatch in binary expression caught by verify_gimple
--- Comment #4 from burnus at gcc dot gnu dot org 2008-05-24 11:02 --- CONFIRM. Due to the missing checking it works with openSUSE's 4.1, 4.2, 4.3; however, if one studies the source code, it is also wrong in other 4.x besides 4.4. The current test case fails only on systems where c_intptr_t == 8, but it can easily be modified to show the same problem on c_intptr_t == 4 systems by changing in INTEGER :: global_length,local_start,local_end,nchnks END TYPE distributed_vector INTEGER into INTEGER(8) (which in turn fixes the program in -m64 systems). The original dump shows the problem: caininad_scale_distvec () integer(kind=8) D.1027; integer(kind=4) D.1026; integer(kind=4) D.1025; D.1023 = &pvazg; D.1025 = D.1023->local_start; D.1026 = D.1023->local_end; D.1027 = D.1026 - D.1025; // which is integer(8) = integer(4) - integer(4) D.1023->local_start; and D.1023->local_end; are used in: REAL, DIMENSION(handle1%local_start:handle1%local_end) ::multiply_dv_dv -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-05-24 11:02:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36316
[Bug preprocessor/36320] New: Required diagnosis of syntax error missed
The syntax error in #elif below is not diagnosed with (say) --std=c99 -pedantic-errors. int z; #if 1 #elif #endif Syntax is: elif-group: # elif constant-expression new-line groupopt and constant expression cannot be empty. The syntax relaxation of 6.10p4 does not apply as the group that the #elif lies in (beginning with the #if) is not skipped. -- Summary: Required diagnosis of syntax error missed Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320