[Bug middle-end/62103] Incorrect folding of bitfield in a union on big endian targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103 --- Comment #5 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Thu Aug 14 06:16:56 2014 New Revision: 213941 URL: https://gcc.gnu.org/viewcvs?rev=213941root=gccview=rev Log: 2014-08-14 Thomas Preud'homme thomas.preudho...@arm.com Backport from mainline 2014-08-12 Thomas Preud'homme thomas.preudho...@arm.com gcc/ PR middle-end/62103 * gimple-fold.c (fold_ctor_reference): Don't fold in presence of bitfields, that is when size doesn't match the size of type or the size of the constructor. gcc/testsuite/ PR middle-end/62103 * gcc.c-torture/execute/bitfld-6.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/gimple-fold.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-14 Ever confirmed|0 |1 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org --- i've bisected things back to r188118. before that commit, gcc compiles rtld.c fine and produces a working ldso. starting at that commit, we get segfaults. But not on the 4.7 branch, right? In any case, we need preprocessed sources.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org --- i've bisected things back to r188118. before that commit, gcc compiles rtld.c fine and produces a working ldso. starting at that commit, we get segfaults. In fact r188118 undoes a pessimization introduced just before in r188009 so the bug was very likely preexisting on the mainline.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #31 from Venkataramanan venkataramanan.kumar at amd dot com --- (In reply to Venkataramanan from comment #30) (In reply to Venkataramanan from comment #29) Hi Richard, I tried the patch you posted last on GCC patches, on top of GCC 4.9 on Aarch64. https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01324.html I am still getting same number of compare errors. Now I will try adding --param ggc-min-expand=100 --param ggc-min-heapsize=131072 to stage2 and stage3 flags. I am getting more compare errors in Aarch64 machine in this case. aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi.o differs aarch64-unknown-linux-gnu/libgcc/_fixxfdi_s.o differs aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi_s.o differs aarch64-unknown-linux-gnu/libgcc/_ctors_s.o differs aarch64-unknown-linux-gnu/libgcc/_floatdixf.o differs aarch64-unknown-linux-gnu/libgcc/_popcount_tab_s.o differs aarch64-unknown-linux-gnu/libgcc/_powixf2.o differs aarch64-unknown-linux-gnu/libgcc/unwind-sjlj.o differs aarch64-unknown-linux-gnu/libgcc/unwind-sjlj_s.o differs aarch64-unknown-linux-gnu/libgcc/crtendS.o differs gcc/sdbout.o differs gcc/c/c-lang.o differs gcc/graphite-poly.o differs gcc/graphite-dependences.o differs gcc/crtend.o differs gcc/vmsdbgout.o differs gcc/hw-doloop.o differs gcc/graphite-optimize-isl.o differs gcc/version.o differs gcc/target-globals.o differs gcc/graphite-interchange.o differs gcc/collect2-aix.o differs gcc/graphite-scop-detection.o differs gcc/loop-doloop.o differs gcc/graphite-blocking.o differs gcc/graphite-clast-to-gimple.o differs gcc/build/min-insn-modes.o differs gcc/build/version.o differs gcc/graphite-sese-to-poly.o differs gcc/insn-peep.o differs gcc/insn-enums.o differs gcc/xcoffout.o differs gcc/crtendS.o differs libbacktrace/atomic.o differs libiberty/pic/safe-ctype.o differs libiberty/pic/getopt.o differs libiberty/pic/obstack.o differs libiberty/pic/fnmatch.o differs libiberty/pic/getopt1.o differs libiberty/safe-ctype.o differs libiberty/getopt.o differs libiberty/obstack.o differs libiberty/fnmatch.o differs libiberty/getopt1.o differs I will try to test the patch on x86_64 machine now. Richard, I thought I used existing build directory for the patch test. So did another build with gcc 4.9 + garbage collector tuning flags for stage2/3 on Aarch64. (Snip) STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param ggc-min-expand=100 --param ggc-min-heapsize=131072 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param ggc-min-expand=100 --param ggc-min-heapsize=131072 (Snip) Bootstrap passes cleanly.
[Bug c++/62130] New: ld.exe: nios2_work.elf: Not enough room for program headers, try linking with -N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62130 Bug ID: 62130 Summary: ld.exe: nios2_work.elf: Not enough room for program headers, try linking with -N Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: qiweistar at 163 dot com I tried to compile a project in Ecplise on windows 7. gcc version 4.1.2 GNU ld version 2.17.50 20060817 The linker fails with Not enough room for program headers, try linking with -N ld.exe: final link failed: Bad value collect2: ld returned 1 exit status make: *** [nios2_work.elf] Error 1 I studied the man pages and all newsgroups, and I asked some newsgroups, but had no success. Is this an error or is there a possibility to surround this error ? Please help ! Thanks a lot, Build of configuration Nios II for project nios2_work make all Info: Building F:/program/FPGA/xieyifenxiyi/double_core/NiosII_0/nios2_work_bsp/ make --no-print-directory -C F:/program/FPGA/xieyifenxiyi/double_core/NiosII_0/nios2_work_bsp/ [BSP build complete] Info: Linking nios2_work.elf nios2-elf-g++ -T'F:/program/FPGA/xieyifenxiyi/double_core/NiosII_0/nios2_work_bsp//linker.x' -msys-crt0='F:/program/FPGA/xieyifenxiyi/double_core/NiosII_0/nios2_work_bsp//obj/HAL/src/crt0.o' -msys-lib=hal_bsp -LF:/program/FPGA/xieyifenxiyi/double_core/NiosII_0/nios2_work_bsp/ -msmallc -Wl,-Map=nios2_work.map -O0 -g -Wall -EL -mno-hw-div -mhw-mul -mno-hw-mulx -o nios2_work.elf obj/main/main.o -lm d:/altera/11.0/nios2eds/bin/gnu/h-i686-mingw32/bin/../lib/gcc/nios2-elf/4.1.2/../../../../nios2-elf/bin/ld.exe: nios2_work.elf: Not enough room for program headers, try linking with -N d:/altera/11.0/nios2eds/bin/gnu/h-i686-mingw32/bin/../lib/gcc/nios2-elf/4.1.2/../../../../nios2-elf/bin/ld.exe: final link failed: Bad value collect2: ld returned 1 exit status make: *** [nios2_work.elf] Error 1
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #14 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #12) i've bisected things back to r188118. before that commit, gcc compiles rtld.c fine and produces a working ldso. starting at that commit, we get segfaults. But not on the 4.7 branch, right? In any case, we need preprocessed sources. I bet the function f mentioned in the testcase from https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00932.html is enough to reproduce the issue. DT_ADDRTAGIDX (dyn-d_tag) gets preprocessed as (0x6eff - dyn-d_tag). DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM is the same as 34+0+16+3+12.
[Bug tree-optimization/62114] [graphite] ICE using -floop-parallelize-all and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114 --- Comment #1 from Leandro Nini drfiemost at email dot it --- Backtrace generated with gcc version 4.9.2 20140813 (prerelease) # LANG=C gcc/cc1 -O2 -floop-parallelize-all -ffast-math /mnt/doc/cvt.i vprintf getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked putc_unlocked putchar_unlocked feof_unlocked ferror_unlocked __signbitf __signbit __signbitl lgamma lgammaf lgammal gamma gammaf gammal tgamma tgammaf tgammal __bswap_32 __bswap_64 atoi atol atoll gnu_dev_major gnu_dev_minor gnu_dev_makedev bsearch atof mymalloc Pobsopen Pobsclose Pobspath Pobsbarriers addpt Bezier append_bezier Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-program profile_estimate devirt cp inline pure-const static-varAssembling functions: Pobsopen cvt.c: In function 'Pobsopen': cvt.c:62:12: internal compiler error: Segmentation fault 0xb2a43e crash_signal ../../gcc-4.9-20140813/gcc/toplev.c:337 0x7f12fad2098f ??? /usr/src/glibc/glibc-2.19/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x1201529 subtract_commutative_associative_deps ../../gcc-4.9-20140813/gcc/graphite-dependences.c:430 0x1201927 compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**) ../../gcc-4.9-20140813/gcc/graphite-dependences.c:502 0x1201b99 loop_level_carries_dependences ../../gcc-4.9-20140813/gcc/graphite-dependences.c:566 0x1201d07 loop_is_parallel_p(loop*, hash_tablebb_pbb_hasher, xcallocator, int) ../../gcc-4.9-20140813/gcc/graphite-dependences.c:598 0x11fe45d translate_clast_for_loop ../../gcc-4.9-20140813/gcc/graphite-clast-to-gimple.c:1200 0x11fe512 translate_clast_for ../../gcc-4.9-20140813/gcc/graphite-clast-to-gimple.c:1224 0x11fe792 translate_clast ../../gcc-4.9-20140813/gcc/graphite-clast-to-gimple.c:1307 0x11fe886 translate_clast ../../gcc-4.9-20140813/gcc/graphite-clast-to-gimple.c:1327 0x11ff3b6 gloog(scop*, hash_tablebb_pbb_hasher, xcallocator) ../../gcc-4.9-20140813/gcc/graphite-clast-to-gimple.c:1712 0x11fb371 graphite_transform_loops() ../../gcc-4.9-20140813/gcc/graphite.c:304 0x11fb406 graphite_transforms ../../gcc-4.9-20140813/gcc/graphite.c:332 0x11fb534 execute ../../gcc-4.9-20140813/gcc/graphite.c:416
[Bug target/62128] Use vpalignr for AVX2 rotation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62128 Stupachenko Evgeny evstupac at gmail dot com changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #1 from Stupachenko Evgeny evstupac at gmail dot com --- Confirm. A part of the patch fixing this discussed at: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01434.html The other part is generation of corresponding pattern for rotation. I'll create corresponding patch.
[Bug fortran/62131] New: Openmp Regression 4.9.1 : Subobject of an allocatable array not allowed in OMP ATOMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62131 Bug ID: 62131 Summary: Openmp Regression 4.9.1 : Subobject of an allocatable array not allowed in OMP ATOMIC Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com layzrc raised this problem on comp.lang.fortran https://groups.google.com/forum/#!topic/comp.lang.fortran/lVzeHW_X1aw module storage integer,allocatable :: nerrs(:,:) end module program atomic use storage allocate(nerrs(10,10)) !$omp parallel do do k=1,10 call uperrs(k,1) enddo !$omp end parallel do stop contains subroutine uperrs(i,io) integer,intent(in) :: i,io !$omp atomic nerrs(i,io)=nerrs(i,io)+1 end subroutine end gfortran -fopenmp atomic.f90 atomic.f90:18.29: nerrs(i,io)=nerrs(i,io)+1 1 Error: !$OMP ATOMIC with ALLOCATABLE variable at (1) I believe this is a wrong and causes a bad regression, because `nerrs(i,io)` is not an allocatable variable. I believe the section 2.12.6 of OpenMP 4 concerns situations when the whole variable being updated or assigned is allocatable (e.g. allocatable scalars) and it causes possible re-allocation.
[Bug tree-optimization/62114] [graphite] ICE using -floop-parallelize-all and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Created attachment 33317 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33317action=edit Reduced testcase Confirmed, attaching reduced testcase
[Bug tree-optimization/62114] [graphite] ICE using -floop-parallelize-all and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||aarch64 Last reconfirmed||2014-8-14 Known to work||5.0 Known to fail||4.9.1 --- Comment #3 from ktkachov at gcc dot gnu.org --- Confirmed on aarch64 4.9.1, trunk works, didn't try 4.8 though
[Bug tree-optimization/62114] [graphite] ICE using -floop-parallelize-all and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|aarch64 |aarch64, x86_64 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #32 from Richard Biener rguenth at gcc dot gnu.org --- Yeah, to summarize: - Using --param ggc-min-expand=100 --param ggc-min-heapsize=131072 fixes LTO bootstrap (I tested x86_64 on the 4.9 branch) - Using the patch from comment #26 doesn't fix LTO bootstrap but makes build/genconfig.o no longer to miscompare Thus we seem to have a multitude of GC-related IL differences. Ugh.
[Bug sanitizer/62132] New: [5.0 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132 Bug ID: 62132 Summary: [5.0 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, ygribov at gcc dot gnu.org Host: x86_64-apple-darwin13 Target: x86_64-apple-darwin13 Build: x86_64-apple-darwin13 On x86_64-apple-darwin13 with -m32 the following tests fail after r213807: Running target unix/-m32 FAIL: c-c++-common/asan/misalign-1.c -O0 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O1 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O3 -fomit-frame-pointer output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O3 -g output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -Os output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 -flto -flto-partition=none output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 -flto output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O0 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O1 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O3 -fomit-frame-pointer output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O3 -g output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -Os output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 -flto -flto-partition=none output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 -flto output pattern test, is = In 64 bit mode the output is = ==48043==ERROR: AddressSanitizer: unknown-crash on address 0x7fff5ba3f3bf at pc 0x1041c0bf2 bp 0x7fff5ba3f2f0 sp 0x7fff5ba3f2e8 READ of size 4 at 0x7fff5ba3f3bf thread T0 #0 0x1041c0bf1 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10bf1) #1 0x1041c0e8f (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10e8f) Address 0x7fff5ba3f3bf is located in stack of thread T0 at offset 175 in frame #0 0x1041c0caf (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10caf) ... while in 32 bit mode, it is = ==48035==ERROR: AddressSanitizer: unknown-crash on address 0xbffda4cf at pc 0x26b19 bp 0xbffda3d8 sp 0xbffda3cc READ of size 4 at 0xbffda4cf thread T0 #0 0x26b18 (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1b18) Address 0xbffda4cf is located in stack of thread T0 at offset 175 in frame #0 0x26bef (/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1bef) ... i.e., the #1 line is missing. Revision r213806 is OK.
[Bug tree-optimization/62079] [4.9 Regression] ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62079 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Aug 14 08:56:49 2014 New Revision: 213950 URL: https://gcc.gnu.org/viewcvs?rev=213950root=gccview=rev Log: 2014-08-14 Richard Biener rguent...@suse.de PR rtl-optimization/62079 * recog.c (peephole2_optimize): If peep2_do_cleanup_cfg run cleanup_cfg. * g++.dg/pr62079.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr62079.C Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/62079] [4.9 Regression] ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62079 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.9/5 Regression] ICE: in |[4.9 Regression] ICE: in |calc_dfs_tree, at |calc_dfs_tree, at |dominance.c:401 with|dominance.c:401 with |-fnon-call-exceptions |-fnon-call-exceptions Known to fail|5.0 | --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug middle-end/62090] [5 Regression] ice in compute_may_aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62090 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|c |middle-end Resolution|--- |FIXED Summary|ice in compute_may_aliases |[5 Regression] ice in ||compute_may_aliases --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/62090] [5 Regression] ice in compute_may_aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62090 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Aug 14 09:02:18 2014 New Revision: 213951 URL: https://gcc.gnu.org/viewcvs?rev=213951root=gccview=rev Log: 2014-08-14 Richard Biener rguent...@suse.de PR tree-optimization/62090 * builtins.c (fold_builtin_sprintf): Move to gimple-fold.c. (fold_builtin_2): Do not fold sprintf. (fold_builtin_3): Likewise. * gimple-fold.c (gimple_fold_builtin_sprintf): New function moved from builtins.c. (gimple_fold_builtin): Fold sprintf. * gcc.dg/pr62090.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr62090.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/62132] [5.0 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug fortran/62125] Nested select type not accepted (rejects valid)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62125 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-14 CC||burnus at gcc dot gnu.org Version|fortran-dev |5.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.5 up to trunk (5.0). However, while I don't see why the code would be invalid, I am not 100% sure it is: at least (As a reference, ifort accepts this code.) does not prove it, fort being known to be quite lax about the standard.
[Bug c++/62127] [5.0 Regression] ICE with VLA in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-14 CC||hubicka at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r212111.
[Bug target/61713] ICE when building c++ code with atomic functions for thumb1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61713 --- Comment #7 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Aug 14 09:32:17 2014 New Revision: 213954 URL: https://gcc.gnu.org/viewcvs?rev=213954root=gccview=rev Log: [optabs.c] Fix ICE when expanding single-threaded version of atomic_test_and_set Backport from mainline 2014-08-04 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/61713 * gcc/optabs.c (expand_atomic_test_and_set): Do not try to emit move to subtarget in serial version if result is ignored. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61756.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/optabs.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/62133] New: internal compiler error:in classify_argument, at config/i386/i386.c:6240 when using #pragma GCC target (arch=core-avx2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62133
Bug ID: 62133
Summary: internal compiler error:in classify_argument, at
config/i386/i386.c:6240 when using #pragma GCC target
(arch=core-avx2)
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sampath.pamidi at gmail dot com
Compiler Output:
gcc -g testtarget.c
In file included from
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/immintrin.h:56:0,
from testtarget.c:4:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/avxintrin.h: In function
â_mm256_load_si256â:
/usr/lib64/gcc/x86_64-suse-linux/4.8/include/avxintrin.h:869:1: internal
compiler error: in classify_argument, at config/i386/i386.c:6240
_mm256_load_si256 (__m256i const *__P)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
***
testtarget.c:
#pragma GCC push_options
#pragma GCC target (arch=core-avx2)
#include immintrin.h
int main()
{
__m256i const *rem;
_mm256_load_si256( (__m256i*) rem );
}
#pragma GCC pop_options
***
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)
[Bug fortran/62125] Nested select type not accepted (rejects valid)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62125 --- Comment #2 from mrestelli mrestelli at gmail dot com --- I can not say 100% that the code is correct, but at least reading 8.6 The SELECT TYPE Construct of The Fortran 2003 Handbook I don't see why it shouldn't. Notice that: among rules and restrictions, 1. says The selector must be polymorphic. and then In the block following a CLASS IS type guard, the associating entity is polymorphic and has the same declared type as the selector. The type parameter values are those of the declared type of the selector. So, after the type guard class is(t2) I understand that u is a polymorphic variable of type class(t2) which can be used as the selector of a nested select type construct. (Assuming the code is not legal, I would then claim that the error message is not very clear, since inside the SELECT TYPE construct the type of u is t2, not t1)
[Bug driver/62105] sanitizer libraries in wrong command line position in link spec file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62105 --- Comment #2 from Julian Taylor jtaylor.debian at googlemail dot com --- -whole-archive applies to static libraries, gcc links a shared library by default using -static-libtsan does not add libtsan at all: $ gcc-4.10 test.c -static-libtsan -fsanitize=thread -v -fPIC -shared 21 | grep --color tsan $ ldd -r a.out undefined symbol: __tsan_init(./a.out) undefined symbol: __tsan_func_exit(./a.out) undefined symbol: __tsan_func_entry(./a.out) undefined symbol: __tsan_write8(./a.out) undefined symbol: __tsan_read8(./a.out)
[Bug driver/62105] sanitizer libraries in wrong command line position in link spec file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62105 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Julian Taylor from comment #0) when linking a file with -fsanitize=* the sanatizer library (e.g. -ltsan is placed before the object on the command line: gcc-4.10 test.c -fsanitize=thread -v -fPIC -shared 21 | grep --color tsan [...] -ltsan /tmp/cc6ovqw5.o -lgcc --as-needed -lgcc_s [...] This might be specific to libtsan, not all the sanitizer libs, I think tsan is handled differently. On a sort of not really related point, the gcc driver links -lstdc++ before -llsan which means C++ programs linked to libstdc++ don't get the replacement operator new from lsan, it should be -llsan -lstdc++
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #33 from Richard Biener rguenth at gcc dot gnu.org --- Another difference - graphite-interchange.o - is due to streaming the indexed decl for fprintf differently. stage2 streams [1968] = tree_list 0x76703ac8 [1969] = identifier_node 0x766ddf20 [1970] = identifier_node 0x76706210 [1971] = tree_list 0x76703af0 [1972] = tree_list 0x76703c30 [1973] = tree_list 0x76707488 [1974] = tree_list 0x767861b8 [1975] = tree_list 0x767861e0 [1976] = tree_list 0x74dddaf0 [1977] = tree_list 0x74dddac8 [1978] = function_type 0x74de05e8 [1979] = identifier_node 0x76781840 [1980] = function_decl 0x76784d00 while stage3 [1968] = tree_list 0x76703ac8 [1969] = identifier_node 0x766ddf20 [1970] = identifier_node 0x76706210 [1971] = tree_list 0x76703af0 [1972] = tree_list 0x76703c30 [1973] = tree_list 0x76707488 [1974] = tree_list 0x767861b8 [1975] = tree_list 0x767861e0 [1976] = function_type 0x74de05e8 [1977] = identifier_node 0x76781840 [1978] = function_decl 0x76784d00 the tree_list differences come from stage2 streaming TYPE_ARG_TYPEs while stage3 producing a reference to previously written ones (streamed for __gmp_fprintf). Note that stage3 re-uses (aka shares) TYPE_ARG_TYPEs for fprintf and __gmp_fprintf while stage2 does not (the FUNCTION_TYPE itself is not shared). I don't even see where we would share TYPE_ARG_TYPEs but not the FUNCTION_TYPE itself... maybe it happens when parsing first builds a function type without attributes and then later appends attributes to them?
[Bug c++/62134] New: ICE with template alias in c++11 / c++1y mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62134 Bug ID: 62134 Summary: ICE with template alias in c++11 / c++1y mode Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lloda at bluewin dot ch Created attachment 33318 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33318action=edit A test case. The problematic section is marked with MAKE_ICE. Somewhat reduced case0.C attached. $CXX -v Using built-in specs. COLLECT_GCC=/opt/gcc-4.9/bin/g++ COLLECT_LTO_WRAPPER=/mnt/end/opt/gcc-4.9.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../src/gcc-4.9.1/configure --prefix=/opt/gcc-4.9.1 --enable-lto --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.1 (GCC) $CXX case0.C -DMAKE_ICE -std=c++11 case0.C: In substitution of ‘templateclass A using type = PermutationSignstd::tuple, R [with A = std::tuple]’: case0.C:100:67: required from ‘const int FindCombinationstd::tuple, std::tuplestd::tuple ::where’ case0.C:135:27: required from here case0.C:115:58: internal compiler error: in retrieve_specialization, at cp/pt.c:1048 template class A using type = PermutationSignP, A; ^ 0x55ebb7 retrieve_specialization ../../../src/gcc-4.9.1/gcc/cp/pt.c:1045 0x570136 tsubst_decl ../../../src/gcc-4.9.1/gcc/cp/pt.c:11045 0x568e57 tsubst(tree_node*, tree_node*, int, tree_node*) ../../../src/gcc-4.9.1/gcc/cp/pt.c:11525 0x57160b instantiate_template_1 ../../../src/gcc-4.9.1/gcc/cp/pt.c:15538 0x57160b instantiate_template(tree_node*, tree_node*, int) ../../../src/gcc-4.9.1/gcc/cp/pt.c:15588 0x568f78 instantiate_alias_template ../../../src/gcc-4.9.1/gcc/cp/pt.c:15618 0x568f78 tsubst(tree_node*, tree_node*, int, tree_node*) ../../../src/gcc-4.9.1/gcc/cp/pt.c:11552 0x56cc35 lookup_template_class_1 ../../../src/gcc-4.9.1/gcc/cp/pt.c:7660 0x56cc35 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../../src/gcc-4.9.1/gcc/cp/pt.c:7886 0x569590 tsubst(tree_node*, tree_node*, int, tree_node*) ../../../src/gcc-4.9.1/gcc/cp/pt.c:11781 0x570f65 tsubst_qualified_id ../../../src/gcc-4.9.1/gcc/cp/pt.c:12426 0x5617d1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../../src/gcc-4.9.1/gcc/cp/pt.c:14411 0x561310 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../../src/gcc-4.9.1/gcc/cp/pt.c:14332 0x565e0f tsubst_expr ../../../src/gcc-4.9.1/gcc/cp/pt.c:14016 0x569a4c tsubst_template_arg ../../../src/gcc-4.9.1/gcc/cp/pt.c:9454 0x56dda2 tsubst_template_args ../../../src/gcc-4.9.1/gcc/cp/pt.c:9993 0x56e2c7 tsubst_aggr_type ../../../src/gcc-4.9.1/gcc/cp/pt.c:10190 0x568725 tsubst(tree_node*, tree_node*, int, tree_node*) ../../../src/gcc-4.9.1/gcc/cp/pt.c:12122 0x56dda2 tsubst_template_args ../../../src/gcc-4.9.1/gcc/cp/pt.c:9993 0x568948 tsubst(tree_node*, tree_node*, int, tree_node*) ../../../src/gcc-4.9.1/gcc/cp/pt.c:11909 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59093 Matt Thompson matthew.thompson at nasa dot gov changed: What|Removed |Added Version|4.8.1 |4.9.1 --- Comment #7 from Matt Thompson matthew.thompson at nasa dot gov --- I'm not sure if anyone is even looking at this bug anymore, but I wanted to say it is still present in gcc 4.9.1. Using the test from ja...@gcc.gnu.org: $ gfortran --version GNU Fortran (GCC) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran test_from_gcc.F90 test_from_gcc.F90: In function ‘mapl_locstreamget’: test_from_gcc.F90:23:0: internal compiler error: Segmentation fault GRIDIM = LocStream%Ptr%Tiling(:)%IM ^ 0x50f628 ??? ../sysdeps/x86_64/elf/start.S:113 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. The bug also still exists with 4.8.3. Does anyone have any idea if this will ever be fixed?
[Bug fortran/62135] New: f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62135
Bug ID: 62135
Summary: f951: internal compiler error: Segmentation fault
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: avathis at esd dot ece.ntua.gr
Created attachment 33319
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33319action=edit
Error with program listing
If (by mistake) in a SELECT CASE block, you type a statement like:
CASE ('2':'7','9':'0'),
gfortran crashes without giving any clue about the error.
The only output is:
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
If instead you type the statement as:
CASE ('9':'0'),
program compiles normally, the same is true if you type:
CASE ('2':'7','0':'9').
Full test program is attached.
[Bug fortran/62135] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62135 --- Comment #1 from Anastasios Vathis avathis at esd dot ece.ntua.gr --- Version of gfortran/gcc: GNU Fortran (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
[Bug middle-end/62092] libgomp.c++/target-2.C FAIL while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62092 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-14 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33320 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33320action=edit gcc5-pr62092.patch Try following patch?
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #15 from Mike Frysinger vapier at gentoo dot org --- (In reply to Andrew Pinski from comment #11) i tried 4.8.3 w/those two patches applied but still see the crash :( (In reply to Eric Botcazou from comment #12) correct, gcc-4.6.4 gcc-4.7.3 work fine
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #16 from Mike Frysinger vapier at gentoo dot org --- Created attachment 33321 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33321action=edit rtld.i preprocessed source the preprocessed output is the same between 4.7.4 4.8.3 (checked with `diff`) this was generated with: $ gcc rtld.c -E -dD -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wundef -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes -fPIC -D'SYSCONFDIR=/etc'-U_FORTIFY_SOURCE -I../include -I/home/vapier/glibc/build/elf -I/home/vapier/glibc/build -I../sysdeps/unix/sysv/linux/ia64 -I../sysdeps/ia64/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ia64/fpu -I../sysdeps/ia64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -DNOT_IN_libc=1 -DIS_IN_rtld=1 -DIN_LIB=rtld -D_ASM_IA64_CURRENT_H -o /home/vapier/glibc/build/elf/rtld.i
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #17 from Mike Frysinger vapier at gentoo dot org --- (In reply to Eric Botcazou from comment #13) fwiw, i took latest 4.8 branch and reverted that change, and ldso works i'll test r188009 and related too though
[Bug c++/62129] [4.9/5 Regression] internal compiler error: in output_constant, at varasm.c:4755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62129 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.2 Summary|internal compiler error: in |[4.9/5 Regression] internal |output_constant, at |compiler error: in |varasm.c:4755 |output_constant, at ||varasm.c:4755
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #34 from Venkataramanan venkataramanan.kumar at amd dot com --- Richard, What I understand is that instead of using tune flags for garbage collection, need to try and fix the object code differences?
[Bug middle-end/62092] libgomp.c++/target-2.C FAIL while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62092 --- Comment #2 from Ilya Verbin iverbin at gmail dot com --- Yes, this fixes the issue. Thank you.
[Bug tree-optimization/62031] [4.8/4.9/5 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- For some reason predictive commoning thinks that the loads of p_bm-metricEntries_[idx][0] and [1] are invariant in the innermost loop. Because: (Data Dep: #(Data Ref: # bb: 9 # stmt: _14 = p_bm_10(D)-metricEntries_[idx_40][0]; # ref: p_bm_10(D)-metricEntries_[idx_40][0]; # base_object: *p_bm_10(D); # Access function 0: 0 # Access function 1: idx_40 # Access function 2: 0 #) #(Data Ref: # bb: 9 # stmt: p_bm_10(D)-metricEntries_[idx_40][0] = _24; # ref: p_bm_10(D)-metricEntries_[idx_40][0]; # base_object: *p_bm_10(D); # Access function 0: 0 # Access function 1: idx_40 # Access function 2: 0 #) (no dependence) ) err...? There is a anti-dependence here. Oh. Data dependence in dr_may_alias_p happily uses DR_BASE_OBJECT as input to the alias oracle but in this case DR_BASE_OBJECT is *p_bm_10(D) which is an object of size 0 ... mem_ref 0x7686a280 type record_type 0x768691f8 entries_item_t type_0 BLK size integer_cst 0x766c4ca8 constant 0 I have a patch.
[Bug c++/62129] [4.9/5 Regression] internal compiler error: in output_constant, at varasm.c:4755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62129 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-14 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r212439.
[Bug tree-optimization/62113] [graphite] ICE using -floop-parallelize-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62113 --- Comment #1 from Leandro Nini drfiemost at email dot it --- Created attachment 33322 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33322action=edit Reduced source
[Bug c++/62136] New: pack expansion failure in an alignment-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62136
Bug ID: 62136
Summary: pack expansion failure in an alignment-specifier
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 33323
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33323action=edit
testcase.cpp
templateclass... Ts
struct alignas(Ts...) A { };
int main () {
}
The above is valid C++ according to [temp.variadic]p4, and should not be
rejected, `gcc` however issues the following diagnostic:
testcase.cpp:2:18: error: expected ‘)’ before ‘...’ token
struct alignas(Ts...) A { };
^
testcase.cpp:2:18: error: expected ‘)’ before ‘...’ token
testcase.cpp:2:18: error: expected identifier before ‘...’ token
testcase.cpp:2:18: error: expected unqualified-id before ‘...’ token
testcase.cpp:2:28: warning: extra ‘;’ [-Wpedantic]
struct alignas(Ts...) A { };
^
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #35 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #34 from Venkataramanan venkataramanan.kumar at amd dot com --- Richard, What I understand is that instead of using tune flags for garbage collection, need to try and fix the object code differences? Yes, it points at real bugs. OTOH fixing that may not be suitable for the release branches, neither is passing fixed values for GC parameters. So I'm not quite sure what a suitable workaround is (well, make sure !defined ENABLE_GC_CHECKING !defined ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 for bootstrap-lto, that is, init_ggc_heuristics () is executed in the same way)
[Bug lto/62067] lto-lang.c:549: too many calls to va_end on some code paths ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62067 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Aug 14 13:13:41 2014 New Revision: 213960 URL: https://gcc.gnu.org/viewcvs?rev=213960root=gccview=rev Log: 2014-08-14 Richard Biener rguent...@suse.de PR lto/62067 * lto-lang.c (def_fn_type): Fix error handling wrt va_end. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-lang.c
[Bug tree-optimization/62113] [graphite] ICE using -floop-parallelize-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62113 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog Target||arm, aarch64, x86_64 Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-14 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.4, 4.9.1, 5.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed on 4.9.1 and current trunk on arm and aarch64. Didn't try 4.8
[Bug tree-optimization/62081] [5 Regression] ICE: in fix_loop_structure, at loop-init.c:208 with -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts -fno-tree-reassoc -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62081 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Aug 14 13:14:24 2014 New Revision: 213961 URL: https://gcc.gnu.org/viewcvs?rev=213961root=gccview=rev Log: 2014-08-14 Richard Biener rguent...@suse.de PR tree-optimization/62081 * tree-ssa-loop.c (pass_fix_loops): New pass. (pass_tree_loop::gate): Do not fixup loops here. * tree-pass.h (make_pass_fix_loops): Declare. * passes.def: Schedule pass_fix_loops before GIMPLE loop passes. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.def trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-loop.c
[Bug tree-optimization/62081] [5 Regression] ICE: in fix_loop_structure, at loop-init.c:208 with -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts -fno-tree-reassoc -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62081 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail|4.10.0 |5.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ada/40986] [4.8/4.9/5 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986 --- Comment #19 from Markus Schöpflin markus.schoepflin at comsoft dot de --- Confirming. I can no longer reproduce the issue with 4.8.2.
[Bug lto/62067] lto-lang.c:549: too many calls to va_end on some code paths ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62067 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/62135] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62135 --- Comment #2 from Anastasios Vathis avathis at esd dot ece.ntua.gr --- In any case, there sould be a SYNTAX ERROR issued
[Bug fortran/62131] [4.9.1 Regression] OpenMP: Subobject of an allocatable array not allowed in OMP ATOMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62131 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp, rejects-valid CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.9.3 Summary|Openmp Regression 4.9.1 : |[4.9.1 Regression] OpenMP: |Subobject of an allocatable |Subobject of an allocatable |array not allowed in OMP|array not allowed in OMP |ATOMIC |ATOMIC --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- To summon up: It's not about !$OMP ATOMIC with ALLOCATABLE variable at (1) being the wrong check - it's about having a warning for a nonallocatable variable. The point is: Even if a is allocatable, a(1,2) is not allocatable - and for dt%b it would depend on b and not on a. I think the OpenMP constraint is there to avoid that (re)allocation on assignment gets triggered for atomic assignments. The current code, cf. line 2744 of the gcc/fortran/openmp.c, uses: var = code-expr1-symtree-n.sym; ... if (var-attr.allocatable) I think the simplest would be to use: if (gfc_expr_attr (code-expr1).allocatable)) However, there might be other spots in the code where using var looks at the wrong thing for component references (like: var%comp). For instance, || expr2_tmp-symtree-n.sym == var) might reject var%b = var%a code - which may or may not be intended.
[Bug target/62100] c++11 threads invoke pure virtual function on arm embedded system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 --- Comment #7 from Peter A. Bigot pab at pabigot dot com --- DEAR PEOPLE FROM THE FUTURE: The problem is that OpenEmbedded used target-specific flags to build the libraries, but did not ensure that the compiler was configured to default to the corresponding architecture. Thus the compiler was defaulting to armv5t while the libraries were built for armv7-a. Until fixed in OpenEmbedded upstream a cleaner workaround is to add -mcpu=cortex-a8 which comes closer to matching the assumptions of the libraries. See http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg55490.html
[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Ramana Radhakrishnan from comment #6) We need preprocessed source for someone to actually try this. CC'ing Vlad as LRA maintainer / author. Thanks for reporting this. Sorry, I am busy with other things right now. I'll start to work on the PR in September.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Evandro Menezes from comment #5) Created attachment 33249 [details] Dhrystone, part 2 of 3 I firstly observed this issue when looking into Dhrystone built with fairly standard options: -O2 -fno-short-enums -fno-inline -fno-inline-functions -fno-inline-small-functions -fno-inline-functions-called-once -fomit-frame-pointer -funroll-all-loops If I add -mno-lra, the code size in dhry_1.o is about 2% smaller. Evandro, thanks for reporting this. Sorry, I am busy with other thing these days. I'll start to work on this PR in September to try to make some progress for the next GCC release. May be a better remeaterialization in LRA I am working on now will help the PR too.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #7 from Evandro Menezes e.menezes at samsung dot com --- (In reply to Vladimir Makarov from comment #6) Evandro, thanks for reporting this. Sorry, I am busy with other thing these days. I'll start to work on this PR in September to try to make some progress for the next GCC release. May be a better remeaterialization in LRA I am working on now will help the PR too. Vladimir, I was thinking about using the hook function to avoid using FPR, at least when -Os is specified, for the time being. This way, registers would still be allocated by the LRA, but this side-effect would be under control. Or do y'all think that it's better to wait a little while longer?
[Bug fortran/62135] ICE with invalid SELECT CASE selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62135 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-14 CC||burnus at gcc dot gnu.org Summary|f951: internal compiler |ICE with invalid SELECT |error: Segmentation fault |CASE selector Ever confirmed|0 |1 Known to fail||4.6.3, 5.0 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- ICEs in 0x62c9b1 resolve_select ../../gcc/fortran/resolve.c:7764
[Bug c/62024] __atomic_always_lock_free is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #4) Whatever we do for __atomic_always_lock_free, note that we'll probably need to find some way for ATOMIC_*_LOCK_FREE (in stdatomic.h) to expand to something usable in #if. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_458.htm Couldn't we just map ATOMIC_*_LOCK_FREE macros (in stdatomic.h) to __GCC_ATOMIC_*_LOCK_FREE macros defined in c-cppbuiltin.c:cpp_atomic_builtins? FWIW, libsupc++ does exactly that. If this approach makes sense, I can prepare a patch with testcase(s).
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #8 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Evandro Menezes from comment #5) Created attachment 33249 [details] Dhrystone, part 2 of 3 I firstly observed this issue when looking into Dhrystone built with fairly standard options: -O2 -fno-short-enums -fno-inline -fno-inline-functions -fno-inline-small-functions -fno-inline-functions-called-once -fomit-frame-pointer -funroll-all-loops If I add -mno-lra, the code size in dhry_1.o is about 2% smaller. Evandro, thanks for reporting this. Sorry, I am busy with other thing these days. I'll start to work on this PR in September to try to make some progress for the next GCC release. May be a better remeaterialization in LRA I am working on now will help the PR too. (In reply to Evandro Menezes from comment #7) (In reply to Vladimir Makarov from comment #6) Evandro, thanks for reporting this. Sorry, I am busy with other thing these days. I'll start to work on this PR in September to try to make some progress for the next GCC release. May be a better remeaterialization in LRA I am working on now will help the PR too. Vladimir, I was thinking about using the hook function to avoid using FPR, at least when -Os is specified, for the time being. This way, registers would still be allocated by the LRA, but this side-effect would be under control. Or do y'all think that it's better to wait a little while longer? If it works and it is ok for ARM mainteiners, it is ok for me too. I will look at this with the point of LRA, can be the code decreased or not. Your solution is on the machine-dependent part. So it is up to you and ARM maintainers. I think you should not wait for what I may or may not find in LRA itself to fix it.
[Bug fortran/62107] libgomp.fortran/target2.f90 error while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-14 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33324 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33324action=edit gcc5-pr62107.patch Untested fix. Can you try it with separate mem offloading?
[Bug c++/62137] New: Poor error recovery when parsing for-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62137
Bug ID: 62137
Summary: Poor error recovery when parsing for-loops
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
This has to be a common mistake:
manuel@gcc10:~$ cat parseerr.cc
void foo(void)
{
for (int k, k 20; k++);
}
Yet we give a not very good diagnostic:
parseerr.cc:3:17: error: expected initializer before ‘’ token
for (int k, k 20; k++);
^
parseerr.cc:3:17: error: expected ‘;’ before ‘’ token
parseerr.cc:3:17: error: expected primary-expression before ‘’ token
My guess is that k 20 is parsed as a declaration of type int, when that
fails something goes wrong, and instead of backtracking to ,, the parser
tries to finish the declaration starting from k but finds instead of ;.
The last error, well, who knows!
After seeing the first error, there are perhaps two better options:
* If we know we are in a loop header, backtrack to after consuming, assume we
have seen ; and continue.
* If not, simply skip to next ;
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #36 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #35) On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #34 from Venkataramanan venkataramanan.kumar at amd dot com --- Richard, What I understand is that instead of using tune flags for garbage collection, need to try and fix the object code differences? Yes, it points at real bugs. OTOH fixing that may not be suitable for the release branches, neither is passing fixed values for GC parameters. So I'm not quite sure what a suitable workaround is (well, make sure !defined ENABLE_GC_CHECKING !defined ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 for bootstrap-lto, that is, init_ggc_heuristics () is executed in the same way) Or better yet recommend with LTO bootstrap, bootstrap4.
[Bug c/62138] New: Poor error recovery when parsing for-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62138
Bug ID: 62138
Summary: Poor error recovery when parsing for-loops
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
This is the C version of PR62137:
manuel@gcc10:~$ cat parseerr.c
void foo(void)
{
for (int k, k 20; k++);
}
manuel@gcc10:~$ ~/test1/213518M/build/gcc/cc1 parseerr.c -std=c99
parseerr.c: In function ‘foo’:
parseerr.c:3:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘’ token
for (int k, k 20; k++);
^
parseerr.c:3:26: error: expected ‘;’ before ‘)’ token
for (int k, k 20; k++);
^
The first error doesn't make any sense.
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Thu Aug 14 16:13:59 2014 New Revision: 213970 URL: https://gcc.gnu.org/viewcvs?rev=213970root=gccview=rev Log: Fix if-conversion pass for dead type-unsafe code 2014-08-14 Tom de Vries t...@codesourcery.com PR rtl-optimization/62004 PR rtl-optimization/62030 * ifcvt.c (rtx_interchangeable_p): New function. (noce_try_move, noce_process_if_block): Use rtx_interchangeable_p. * emit-rtl.c (mem_attrs_eq_p): Remove static. * emit-rtl.h (mem_attrs_eq_p): Declare. * gcc.dg/pr62004.c: New test. * gcc.dg/pr62030.c: Same. * gcc.target/mips/pr62030-octeon.c: Same. Added: trunk/gcc/testsuite/gcc.dg/pr62004.c trunk/gcc/testsuite/gcc.dg/pr62030.c trunk/gcc/testsuite/gcc.target/mips/pr62030-octeon.c Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.h trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004 --- Comment #5 from vries at gcc dot gnu.org --- Author: vries Date: Thu Aug 14 16:13:59 2014 New Revision: 213970 URL: https://gcc.gnu.org/viewcvs?rev=213970root=gccview=rev Log: Fix if-conversion pass for dead type-unsafe code 2014-08-14 Tom de Vries t...@codesourcery.com PR rtl-optimization/62004 PR rtl-optimization/62030 * ifcvt.c (rtx_interchangeable_p): New function. (noce_try_move, noce_process_if_block): Use rtx_interchangeable_p. * emit-rtl.c (mem_attrs_eq_p): Remove static. * emit-rtl.h (mem_attrs_eq_p): Declare. * gcc.dg/pr62004.c: New test. * gcc.dg/pr62030.c: Same. * gcc.target/mips/pr62030-octeon.c: Same. Added: trunk/gcc/testsuite/gcc.dg/pr62004.c trunk/gcc/testsuite/gcc.dg/pr62030.c trunk/gcc/testsuite/gcc.target/mips/pr62030-octeon.c Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.h trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/62131] [4.9/5 Regression] OpenMP: Subobject of an allocatable array not allowed in OMP ATOMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62131 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-14 Target Milestone|4.9.3 |4.9.2 Summary|[4.9.1 Regression] OpenMP: |[4.9/5 Regression] OpenMP: |Subobject of an allocatable |Subobject of an allocatable |array not allowed in OMP|array not allowed in OMP |ATOMIC |ATOMIC Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) The current code, cf. line 2744 of the gcc/fortran/openmp.c, uses: var = code-expr1-symtree-n.sym; ... if (var-attr.allocatable) I think the simplest would be to use: if (gfc_expr_attr (code-expr1).allocatable)) That looks good to me, preapproved for trunk/4.9.2 with a testcase. However, there might be other spots in the code where using var looks at the wrong thing for component references (like: var%comp). For instance, || expr2_tmp-symtree-n.sym == var) might reject var%b = var%a code - which may or may not be intended. Fix that is non-easy though. var is used e.g. for the expr_references_sym checks. Some of those are used to complain about invalid code, but if expr1-ref is non-NULL, then we may reject valid code. Say !$omp atomic write var(1) = var(2) is fine, yet we'll complain. Those could be fixed by only calling expr_references_sym if expr1-ref is NULL, and simply not diagnose it at all otherwise. Or expr_references_sym could be enhanced not to take symbol, but the EXPR_VARIABLE gfc_expr * instead, and it could just try to compare the refs too. I believe in the spec when it talks about x, it should be always the same sequence of tokens, so say !$omp atomic var(i) = var(j) + 1 is likely invalid even if i has the same value as j, the standard requires that no other expression may reference the same memory as x (etc.), but that is pretty much impossible to check. Anyway, bigger issue is the atomic swap (for which I'm guilty as the one who requested the addition of that into the standard). For that unfortunately the being conservative is bad, but the current state is bad too. !$omp atomic capture v = var(i) var(i) = var(j) + var(k) !$omp end atomic (of course, invalid with i == j or i == k) should be valid atomic swap that we likely mishandle right now, while !$omp atomic capture v = var(i) var(i) = var(j) + var(i) !$omp end atomic is not a capture. So, I'm afraid we need to improve expr_references_sym. And then there are the other comparisons you've mentioned, not sure what exactly we can do about those :(.
[Bug c/62139] New: Tilera tilepro: useless stack pointer operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62139
Bug ID: 62139
Summary: Tilera tilepro: useless stack pointer operations
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.parera at upm dot es
I made a C function to split a register into halves and return them as a
struct. The code works fine but adds a couple of useless instructions
concerning the stack that cause a performance penalty.
typedef struct {
uint32_t y0;
uint32_t y1;
} __tpro_split_t;
__tpro_split_t split(uint32_t a) {
__tpro_split_t res = {
.y0 = __insn_srai(__insn_shli(a, 16), 16),
.y1 = __insn_srai(a, 16)
};
return res;
}
The assembler code is
.cfi_startproc
{
shlir10, r0, 16
srair1, r0, 16
}
{
addisp, sp, -8== useless
.cfi_def_cfa_offset 8
srair0, r10, 16
}
{
addisp, sp, 8 == useless
.cfi_def_cfa_offset 0
jrplr
}
.cfi_endproc
I think that this issue is quite similar to those at bug #48941 but in this
case for Tilera TilePro architecture, and probably, also TileGx.
[Bug c/62140] New: [GCC-4.10.0] ICE: : in build2_stat, at tree.c:4265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62140 Bug ID: 62140 Summary: [GCC-4.10.0] ICE: : in build2_stat, at tree.c:4265 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sabrinadfs at gmail dot com GCC-4.10.0 (trunk) x86_64-apple-darwin11.4.2 Running the following test: make -s -C gcc check-gcc RUNTESTFLAGS=dg-torture.exp=pr53703.c --target_board=unix/-fsanitize=address GCC produced this ICE: /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c: In function 'usagi_getifaddrs': /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: in build2_stat, at tree.c:4265 /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) compiler exited with status 1 output is: /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c: In function 'usagi_getifaddrs': /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: in build2_stat, at tree.c:4265 /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) FAIL: gcc.dg/torture/pr53703.c -O0 (internal compiler error) FAIL: gcc.dg/torture/pr53703.c -O0 (test for excess errors) Excess errors: /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: in build2_stat, at tree.c:4265 /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) Executing on host: /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc -B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/ /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c -fno-diagnostics-show-caret -fdiagnostics-color=never-O1 -w -S -fsanitize=address -o pr53703.s(timeout = 300) spawn /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc -B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/ /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -w -S -fsanitize=address -o pr53703.s /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c: In function 'usagi_getifaddrs': /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: in build2_stat, at tree.c:4265 /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) compiler exited with status 1 output is: /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c: In function 'usagi_getifaddrs': /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: in build2_stat, at tree.c:4265 /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) FAIL: gcc.dg/torture/pr53703.c -O1 (internal compiler error) FAIL: gcc.dg/torture/pr53703.c -O1 (test for excess errors) Excess errors: /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: in build2_stat, at tree.c:4265 /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c:47:5: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) Executing on host: /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc -B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/ /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c -fno-diagnostics-show-caret -fdiagnostics-color=never-O2 -w -S -fsanitize=address -o pr53703.s(timeout = 300) spawn /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc -B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/ /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -w -S -fsanitize=address -o pr53703.s /Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr53703.c: In function 'usagi_getifaddrs':
[Bug fortran/62076] [4.9/5 Regression] testsuite failure in udr2.90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62076 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Aug 14 16:39:07 2014 New Revision: 213971 URL: https://gcc.gnu.org/viewcvs?rev=213971root=gccview=rev Log: PR fortran/62076 * openmp.c (gfc_match_omp_clauses): When failed to match operator name, defined op name or name, set buffer to empty string. Don't call gfc_find_omp_udr if buffer is empty string. (gfc_match_omp_declare_reduction): Call gfc_undo_symbols () before calling gfc_free_omp_udr. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c
[Bug fortran/62107] libgomp.fortran/target2.f90 error while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107 Ilya Verbin iverbin at gmail dot com changed: What|Removed |Added CC||iverbin at gmail dot com --- Comment #2 from Ilya Verbin iverbin at gmail dot com --- This patch causes internal compiler errors on target2.f90 and target3.f90: libgomp/testsuite/libgomp.fortran/target2.f90: In function ‘foo’: libgomp/testsuite/libgomp.fortran/target2.f90:11:0: error: incorrect sharing of tree nodes *f.659 #pragma omp target map(to:MEM[(c_char *)D.5393] [len: D.5392]) map(alloc:d [pointer assign, bias: D.5398]) map(to:*n.562 [len: 4]) map(alloc:n [pointer assign, bias: 0]) map(tofrom:r [len: 4]) map(tofrom:*(c_char *) k.data [len: D.5825]) map(to:k [pointer set, len: 48]) map(alloc:(integer(kind=4)[0:] *) k.data [pointer assign, bias: 0]) map(tofrom:*j [len: 4]) map(alloc:j [pointer assign, bias: 0]) map(tofrom:ubound.12 [len: 8]) map(tofrom:*i [len: D.3148]) map(alloc:i [pointer assign, bias: 0]) map(tofrom:h [len: 4]) map(tofrom:offset.10 [len: 8]) map(tofrom:stride.9 [len: 8]) map(tofrom:ubound.8 [len: 8]) map(tofrom:stride.7 [len: 8]) map(tofrom:ubound.6 [len: 8]) map(tofrom:*e.0 [len: D.3155]) map(alloc:e.0 [pointer assign, bias: 0]) map(tofrom:offset.4 [len: 8]) map(tofrom:stride.3 [len: 8]) map(tofrom:ubound.2 [len: 8]) map(tofrom:*c.0 [len: D.3159]) map(alloc:c.0 [pointer assign, bias: 0]) map(tofrom:ubound.0 [len: 8]) map(tofrom:*(c_char *) g.633-data [len: D.5813]) map(to:*g.633 [pointer set, len: 48]) map(alloc:(integer(kind=4)[0:] *) g.633-data [pointer assign, bias: 0]) map(alloc:g [pointer assign, bias: 0]) map(tofrom:**f.659 [len: 4]) map(alloc:*f.659 [pointer assign, bias: 0]) map(alloc:f [pointer assign, bias: 0]) map(tofrom:*b [len: D.3162]) map(alloc:b [pointer assign, bias: 0]) map(tofrom:*a [len: 4]) map(alloc:a [pointer assign, bias: 0]) [child fn: __target2_MOD_foo._omp_fn.4] libgomp/testsuite/libgomp.fortran/target2.f90:11:0: internal compiler error: verify_gimple failed 0xa79975 verify_gimple_in_cfg(function*, bool) ../../gcc/tree-cfg.c:4994 0x97fec1 execute_function_todo ../../gcc/passes.c:1749 0x981383 execute_todo ../../gcc/passes.c:1806
[Bug fortran/62076] [4.9/5 Regression] testsuite failure in udr2.90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62076 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Aug 14 16:44:21 2014 New Revision: 213972 URL: https://gcc.gnu.org/viewcvs?rev=213972root=gccview=rev Log: PR fortran/62076 * openmp.c (gfc_match_omp_clauses): When failed to match operator name, defined op name or name, set buffer to empty string. Don't call gfc_find_omp_udr if buffer is empty string. (gfc_match_omp_declare_reduction): Call gfc_undo_symbols () before calling gfc_free_omp_udr. Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/openmp.c
[Bug c/62024] __atomic_always_lock_free is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Thu, 14 Aug 2014, mpolacek at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #4) Whatever we do for __atomic_always_lock_free, note that we'll probably need to find some way for ATOMIC_*_LOCK_FREE (in stdatomic.h) to expand to something usable in #if. http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_458.htm Couldn't we just map ATOMIC_*_LOCK_FREE macros (in stdatomic.h) to __GCC_ATOMIC_*_LOCK_FREE macros defined in c-cppbuiltin.c:cpp_atomic_builtins? FWIW, libsupc++ does exactly that. If this approach makes sense, I can prepare a patch with testcase(s). Yes, I think that should work.
[Bug c++/54377] Consider default arguments in wrong number of template arguments diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54377 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Aug 14 17:00:45 2014 New Revision: 213973 URL: https://gcc.gnu.org/viewcvs?rev=213973root=gccview=rev Log: /cp 2014-08-14 Paolo Carlini paolo.carl...@oracle.com PR c++/54377 * pt.c (coerce_template_parms): Improve error message vs default arguments. /testsuite 2014-08-14 Paolo Carlini paolo.carl...@oracle.com PR c++/54377 * g++.dg/template/pr54377.C: New. * g++.dg/cpp0x/pr54377.C: Likewise. * g++.dg/cpp0x/alias-decl-2.C: Adjust. * g++.dg/cpp0x/pr51226.C: Likewise. * g++.dg/cpp0x/variadic2.C: Likewise. * g++.dg/parse/too-many-tmpl-args1.C: Likewise. * g++.dg/template/dtor3.C: Likewise. * g++.dg/template/qualttp4.C: Likewise. * g++.dg/template/spec28.C: Likewise. * g++.old-deja/g++.brendan/crash8.C: Likewise. * g++.old-deja/g++.pt/ttp7.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr54377.C trunk/gcc/testsuite/g++.dg/template/pr54377.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr51226.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic2.C trunk/gcc/testsuite/g++.dg/parse/too-many-tmpl-args1.C trunk/gcc/testsuite/g++.dg/template/dtor3.C trunk/gcc/testsuite/g++.dg/template/qualttp4.C trunk/gcc/testsuite/g++.dg/template/spec28.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash8.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp7.C
[Bug c++/54377] Consider default arguments in wrong number of template arguments diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54377 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 5.0.
[Bug c++/62101] deleted definitions of friend functions are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62101 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 14 17:11:26 2014 New Revision: 213974 URL: https://gcc.gnu.org/viewcvs?rev=213974root=gccview=rev Log: PR c++/62101 * decl.c (grokdeclarator): Move the check for friend initializers.. * decl2.c (grokfield) ..here. Postpone early return for friends until after the initializer check. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr62101.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c
[Bug fortran/62107] libgomp.fortran/target2.f90 error while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #33324|0 |1 is obsolete|| --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33325 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33325action=edit gcc5-pr62107.patch Oops, sorry, this should fix that.
[Bug c++/62136] pack expansion fails in alignment-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62136 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- dup *** This bug has been marked as a duplicate of bug 59012 ***
[Bug c++/59012] alignas does not support parameter pack expansions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59012 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||filip.roseen at gmail dot com --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 62136 has been marked as a duplicate of this bug. ***
[Bug fortran/62107] libgomp.fortran/target2.f90 error while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107 --- Comment #4 from Ilya Verbin iverbin at gmail dot com --- Great! Now all fortran tests pass with separate memory.
[Bug tree-optimization/13962] [tree-ssa] make fold use alias information to optimize pointer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- While looking at some unrelated issue, I noticed the following: _41 = operator new (28); ... if (_41 != _S_empty_rep_storage) which happens with a simple use of std::string (with some extra inlining). __builtin_malloc(42)==var is not optimized either, so it isn't (only) an issue with operator new. If the general case is too dangerous, maybe there is at least some subset that could safely be optimized?
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #37 from Sven C. Dack sven.c.dack at virginmedia dot com --- ... trying Index: config/bootstrap-lto.mk === --- config/bootstrap-lto.mk (revision 213899) +++ config/bootstrap-lto.mk (working copy) @@ -2,6 +2,6 @@ # FIXME: Our build system is not yet able to use gcc-ar wrapper, so we need # to go with -ffat-lto-objects. -STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects -STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param ggc-min-expand=100 --param ggc-min-heapsize=131072 +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param ggc-min-expand=100 --param ggc-min-heapsize=131072 STAGEprofile_CFLAGS += -fno-lto It works for me, too. It has compiled 4.9.2-20140806 --with-build-config=bootstrap-lto and --with-boot-ldflags=-fuse-linker-plugin successfully. It is now running the testsuite.
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Revision: 213970 Modified property: svn:log Modified: svn:log at Thu Aug 14 17:48:43 2014 -- --- svn:log (original) +++ svn:log Thu Aug 14 17:48:43 2014 @@ -6,7 +6,6 @@ PR rtl-optimization/62030 * ifcvt.c (rtx_interchangeable_p): New function. (noce_try_move, noce_process_if_block): Use rtx_interchangeable_p. -* emit-rtl.c (mem_attrs_eq_p): Remove static. * emit-rtl.h (mem_attrs_eq_p): Declare. * gcc.dg/pr62004.c: New test.
[Bug c/62141] New: [GCC-4.10.0] ICE: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62141 Bug ID: 62141 Summary: [GCC-4.10.0] ICE: Segmentation fault: 11 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sabrinadfs at gmail dot com GCC-4.10.0 (trunk) x86_64-apple-darwin11.4.2 Running the following test: make -s -C gcc check-gcc RUNTESTFLAGS=dg-torture.exp=Wsizeof-pointer-memaccess1.c --target_board=unix/-fsanitize=address GCC produced these ICEs: ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c: In function 'f3': ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Segmentation fault: 11 ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) FAIL: gcc.dg/torture/Wsizeof-pointer-memaccess1.c -O0 (internal compiler error) FAIL: gcc.dg/torture/Wsizeof-pointer-memaccess1.c -O0 (test for excess errors) Excess errors: ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Segmentation fault: 11 ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c: In function 'f3': ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Segmentation fault: 11 ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) FAIL: gcc.dg/torture/Wsizeof-pointer-memaccess1.c -O2 (internal compiler error) FAIL: gcc.dg/torture/Wsizeof-pointer-memaccess1.c -O2 (test for excess errors) Excess errors: ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Segmentation fault: 11 ../gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c:486:1: internal compiler error: Abort trap: 6 xgcc: internal compiler error: Abort trap: 6 (program cc1) The detailed log is attached. Can anyone confirm this bug? Thanks, Sabrina Souto.
[Bug c/62141] [GCC-4.10.0] ICE: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62141 --- Comment #1 from Sabrina Souto sabrinadfs at gmail dot com --- Created attachment 33326 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33326action=edit Log of the test execution
[Bug fortran/62142] New: internal compiler error: Segmentation fault (X = X - L*floor(X/L))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62142 Bug ID: 62142 Summary: internal compiler error: Segmentation fault (X = X - L*floor(X/L)) Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ondrej.certik at gmail dot com Created attachment 33327 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33327action=edit Source file to reproduce the segfault $ cat test_segfault.f90 program test_segfault implicit none integer, parameter :: dp=kind(0.d0) real(dp) :: L real(dp), allocatable :: X(:) X = X - L*floor(X/L) end program $ gfortran -v test_segfault.f90 Driving: gfortran -v test_segfault.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/local/certik/bld/gcc/5att4mtprf52/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/local/certik/bld/gcc/5att4mtprf52 --enable-checking=release --enable-languages=fortran,c,c++ --with-local-prefix=/local/certik/bld/gcc/5att4mtprf52 --with-gmp=/local/certik/bld/gmp/vadkrj43wtyr --with-mpc=/local/certik/bld/mpc/sushaq7ufe2f --with-mpfr=/local/certik/bld/mpfr/vxwmnxjsshse --with-cloog=/local/certik/bld/cloog/x3kd73rwqkzj --with-isl=/local/certik/bld/isl/lfrjunwloawr --enable-clocale=gnu --enable-__cxa_atexit --enable-shared --enable-threads=posix --disable-multilib --libdir=/local/certik/bld/gcc/5att4mtprf52/lib --with-stage1-ldflags='-L/local/certik/bld/cloog/x3kd73rwqkzj/lib -Wl,-rpath=/local/certik/bld/cloog/x3kd73rwqkzj/lib -L/local/certik/bld/gmp/vadkrj43wtyr/lib -Wl,-rpath=/local/certik/bld/gmp/vadkrj43wtyr/lib -L/local/certik/bld/isl/lfrjunwloawr/lib -Wl,-rpath=/local/certik/bld/isl/lfrjunwloawr/lib -L/local/certik/bld/mpc/sushaq7ufe2f/lib -Wl,-rpath=/local/certik/bld/mpc/sushaq7ufe2f/lib -L/local/certik/bld/mpfr/vxwmnxjsshse/lib -Wl,-rpath=/local/certik/bld/mpfr/vxwmnxjsshse/lib -L/local/certik/bld/patchelf/k3rloj265ogt/lib -Wl,-rpath=/local/certik/bld/patchelf/k3rloj265ogt/lib -L/local/certik/bld/zlib/3el5ccejre7b/lib -Wl,-rpath=/local/certik/bld/zlib/3el5ccejre7b/lib' --with-boot-ldflags='-L/local/certik/bld/cloog/x3kd73rwqkzj/lib -Wl,-rpath=/local/certik/bld/cloog/x3kd73rwqkzj/lib -L/local/certik/bld/gmp/vadkrj43wtyr/lib -Wl,-rpath=/local/certik/bld/gmp/vadkrj43wtyr/lib -L/local/certik/bld/isl/lfrjunwloawr/lib -Wl,-rpath=/local/certik/bld/isl/lfrjunwloawr/lib -L/local/certik/bld/mpc/sushaq7ufe2f/lib -Wl,-rpath=/local/certik/bld/mpc/sushaq7ufe2f/lib -L/local/certik/bld/mpfr/vxwmnxjsshse/lib -Wl,-rpath=/local/certik/bld/mpfr/vxwmnxjsshse/lib -L/local/certik/bld/patchelf/k3rloj265ogt/lib -Wl,-rpath=/local/certik/bld/patchelf/k3rloj265ogt/lib -L/local/certik/bld/zlib/3el5ccejre7b/lib -Wl,-rpath=/local/certik/bld/zlib/3el5ccejre7b/lib' Thread model: posix gcc version 4.9.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /local/certik/bld/gcc/5att4mtprf52/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/f951 test_segfault.f90 -quiet -dumpbase test_segfault.f90 -mtune=generic -march=x86-64 -auxbase test_segfault -version -fintrinsic-modules-path /local/certik/bld/gcc/5att4mtprf52/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/finclude -o /tmp/ccliCcO4.s GNU Fortran (GCC) version 4.9.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.1, GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.9.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.1, GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 test_segfault.f90: In function ‘test_segfault’: test_segfault.f90:6:0: internal compiler error: Segmentation fault X = X - L*floor(X/L) ^ 0x90f44f crash_signal ../.././gcc/toplev.c:337 0x604e0d is_runtime_conformable ../.././gcc/fortran/trans-expr.c:7856 0x604e1b is_runtime_conformable ../.././gcc/fortran/trans-expr.c:7856 0x611aa4 gfc_trans_assignment_1 ../.././gcc/fortran/trans-expr.c:8117 0x5e3fc5 trans_code ../.././gcc/fortran/trans.c:1639 0x6033bb gfc_generate_function_code(gfc_namespace*) ../.././gcc/fortran/trans-decl.c:5653 0x5a2f80 translate_all_program_units ../.././gcc/fortran/parse.c:4953 0x5a2f80 gfc_parse_file() ../.././gcc/fortran/parse.c:5150 0x5e0025 gfc_be_parse_file ../.././gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. When I execute gfortran -v -save-temps test_segfault.f90, it doesn't produce preprocessed sources, I assume the segfault happens in the parser. I have isolated the
[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
There are two issues seen with the testcase. First is that ipa-devirt misses
the ctor call that can be easily fixed by:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 213969)
+++ ipa-devirt.c(working copy)
@@ -2663,6 +2663,8 @@
* BITS_PER_UNIT;
op = TREE_OPERAND (op, 0);
}
+ else if (DECL_P (op))
+ ;
else
{
tci-speculative = true;
I am testing this patch.
However even with this change we won't devirtualize because we believe that we
can not reffer to the virtual method.
The node is:
(gdb) p snode-dump (stderr)
_ZNK1A5m_fn1Ev/3 (virtual SnmpSyntax* A::m_fn1() const) @0x76dad8a0
Type: function definition analyzed
Visibility: external public weak comdat comdat_group:_ZNK1A5m_fn1Ev one_only
virtual
Address is taken.
References:
Referring: _ZTV1A/12 (addr)
Availability: available
First run: 0
Function flags: body
Called by:
Calls:
I wonder what we should do with both external and comdat here. Jason, can we
devirtualize?
The constructor is keyed to other compilation unit here, but we are provided
with a body
that we will never use (modulo the tree-ssa-pre bug that brings the reference
into code).
I can imagine implementing logic to make us to devirtualize only when inlining
and never introduce
direct refernece otherwise, but it would be quite work - so far we always need
the intermediate
reference before inlining. (Basically we will need to make ipa-devirt to
produce direct call and
revert if inliner fails to inline the function at the end of IPA queue).
Honza
[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Honza, your comment belongs to PR62091. This is the wrong bug.
[Bug c++/62143] New: unlimited number of class name qualifiers allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62143
Bug ID: 62143
Summary: unlimited number of class name qualifiers allowed
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haynberg at sig dot com
I'm not sure if this is a bug or allowed by the standard. Either way, it's
strange this is allowed.
$ cat t.cpp
#include iostream
using namespace std;
struct X {
void foo();
};
// an unlimited number of X::s are allowed !!
void X::X::X::X::X::foo()
{
cout ctor endl;
}
// if you uncomment this, you'll get a redefinition error
// void X::foo()
// {
//cout ctor endl;
// }
int main()
{
X x;
x.foo();
}
$ g++ t.cpp
$ a.out
ctor
$ g++ -v
...
gcc version 4.8.2 (GCC)
...
$ uname -isr
Linux 3.0.38-0.5-default x86_64
[Bug inline-asm/62144] New: Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
Bug ID: 62144
Summary: Frame pointer required, but reserved error with
-fomit-frame-pointer but only with -m32 -O2
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Created attachment 33328
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33328action=edit
(Example program)
The following error is unexpected. We use -fomit-frame-pointer to allow us to
reserve a register, but apparently it is required anyway -- but only when
optimization is turned to -O2 and when compiled at -m32.
$ cat t.i
register int x0 asm (bp);
static char x1[4096];
int strlen (char *);
void x2 ();
void
x3 ()
{
switch (0)
case 0:
x2 (0);
int x4 = strlen (x1);
if (x1[x4] == '\n')
x2 ();
}
$ gcc-archive/trunk/213772/bin/gcc -c t.i -m32 -fomit-frame-pointer
$ gcc-archive/trunk/213772/bin/gcc -c t.i -O1 -m32 -fomit-frame-pointer
$ gcc-archive/trunk/213772/bin/gcc -c t.i -O2 -m32 -fomit-frame-pointer
t.i: In function ‘x3’:
t.i:6:1: error: frame pointer required, but reserved
x3 ()
^
t.i:1:14: note: for ‘x0’
register int x0 asm (bp);
^
$
Although the examples above use trunk, this also occurs with the 4.9 branch at
the same revision.
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091
--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
I added the comment to wrong PR so I am moving it here:
Hi,
There are two issues seen with the testcase. First is that ipa-devirt misses
the ctor call that can be easily fixed by:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 213969)
+++ ipa-devirt.c(working copy)
@@ -2663,6 +2663,8 @@
* BITS_PER_UNIT;
op = TREE_OPERAND (op, 0);
}
+ else if (DECL_P (op))
+ ;
else
{
tci-speculative = true;
I am testing this patch.
However even with this change we won't devirtualize because we believe that we
can not reffer to the virtual method.
The node is:
(gdb) p snode-dump (stderr)
_ZNK1A5m_fn1Ev/3 (virtual SnmpSyntax* A::m_fn1() const) @0x76dad8a0
Type: function definition analyzed
Visibility: external public weak comdat comdat_group:_ZNK1A5m_fn1Ev one_only
virtual
Address is taken.
References:
Referring: _ZTV1A/12 (addr)
Availability: available
First run: 0
Function flags: body
Called by:
Calls:
I wonder what we should do with both external and comdat here. Jason, can we
devirtualize?
The constructor is keyed to other compilation unit here, but we are provided
with a body
that we will never use (modulo the tree-ssa-pre bug that brings the reference
into code).
I can imagine implementing logic to make us to devirtualize only when inlining
and never introduce
direct refernece otherwise, but it would be quite work - so far we always need
the intermediate
reference before inlining. (Basically we will need to make ipa-devirt to
produce direct call and
revert if inliner fails to inline the function at the end of IPA queue).
[Bug fortran/62106] [4.9/5 Regression] Adding a scalar variable to an array constructor gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Thu Aug 14 18:52:12 2014 New Revision: 213980 URL: https://gcc.gnu.org/viewcvs?rev=213980root=gccview=rev Log: 2014-08-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/62106 * gfortran.h (symbol_attribute): Add fe_temp flag. * frontend-passes.c (is_fe_temp): New function. (create_var): Don't add a temporary for an already created variable or for a constant. (combine_ARRAY_constructor): Remove special handling for constants. 2014-08-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/62106 * gfortran.dg/array_constructor_49.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_49.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/gfortran.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/62142] internal compiler error: Segmentation fault (X = X - L*floor(X/L))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62142 --- Comment #1 from Ondřej Čertík ondrej.certik at gmail dot com --- One can actually isolate it even further (the same stacktrace): program test_segfault implicit none real, allocatable :: X(:) X = floor(X) end program
[Bug fortran/62142] internal compiler error: Segmentation fault (X = X - L*floor(X/L))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62142 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Ondřej Čertík from comment #0) Created attachment 33327 [details] Source file to reproduce the segfault $ cat test_segfault.f90 program test_segfault implicit none integer, parameter :: dp=kind(0.d0) real(dp) :: L real(dp), allocatable :: X(:) X = X - L*floor(X/L) end program (snip) When I execute gfortran -v -save-temps test_segfault.f90, it doesn't produce preprocessed sources, I assume the segfault happens in the parser. I have isolated the segfault, it happens in a large codebase and prevents its compilation (the array is allocated in our code, the above is the simplest code to reproduce the problem). This is my first bug report, please let me know if you need further information. For such a short program, we don't necessarily need -save-temps. Note, your reduce test case is nonconforming code because it uses L and X in a RHS expression without being defined. With the small change program test_segfault implicit none integer, parameter :: dp=kind(0.d0) real(dp) :: L real(dp), allocatable :: X(:) L = 42 X = [1, 2] X = X - L*floor(X/L) end program the code is now conforming and it still exhibits the bug. I suspect that the bug is due to a combination of -frealloc-lhs and that floor is generated as inline code. With -frealloc-lhs, I get the same ICE that you find. With -fno-realloc-lhs, I get a compiled executable but it segfaults at runtime because x = [1,2] obviously won't work. If I add an allocate(x(2)) prior to x = [1,2], then -fno-realloc-lhs produced executable runs as expected. So, as a workaround explicitly allocate memory and use -fno-realloc-lhs.
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 33329 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33329action=edit Path I am testing The disagreemeng actually turned out to be subtle bug in tree-ssa-alias.c where function_entry_reached was incorrectly incorrectly initialized to false during recursive walk :( I am testing the following patch that makes us to not devirtualize in this case. We still ought to solve the visibility issues
[Bug fortran/62142] internal compiler error: Segmentation fault (X = X - L*floor(X/L))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62142 --- Comment #3 from Ondřej Čertík ondrej.certik at gmail dot com --- Thanks Steve for the quick reply! I tried -fno-realloc-lhs and it fixes the problem for us (we always allocate arrays explicitly).
[Bug ada/40986] [4.8/4.9/5 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED CC||charlet at gcc dot gnu.org Version|4.4.1 |4.8.2 Resolution|--- |FIXED --- Comment #20 from Arnaud Charlet charlet at gcc dot gnu.org --- Closing then
[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071 --- Comment #5 from Jason Merrill jason at redhat dot com --- On 08/14/2014 02:10 PM, Jan Hubicka wrote: I wonder what we should do with both external and comdat here. Jason, can we devirtualize? No, we're setting comdat now to avoid devirtualization, because we can't be confident that we'll be able to refer to the definition where it gets emitted. The constructor is keyed to other compilation unit here, but we are provided with a body that we will never use (modulo the tree-ssa-pre bug that brings the reference into code). Hmm, we might consider overriding DECL_EXTERNAL so that there's a definition available for devirtualization. Jason
[Bug c++/62145] New: match rulers in overload functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62145
Bug ID: 62145
Summary: match rulers in overload functions
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
For this small program, G++ and clang++ don't agree with each other:
1. cat x2.c
#include stdio.h
char f(...) { return '\1'; };
int f(void*) { return 999; }
constexpr int t2(int n) { return sizeof f(n*0); }
int main()
{
char b[ t2(0) ];
printf(sizeof b is %d\n, sizeof(b));
return 0;
}
2.
$ g++ -std=c++0x x2.cpp
$ ./a.out
sizeof b is 4
$ clang++ -std=c++11 x2.cpp
$ ./a.out
sizeof b is 1
It shows G++ is calling f(void*), but clang++ is calling f(...). which one is
right?
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #38 from Sven C. Dack sven.c.dack at virginmedia dot com --- The testsuite run looks good: # of expected passes105750 # of unexpected failures3 # of expected failures252 # of expected passes87886 # of unexpected failures2 # of unexpected successes2 # of expected failures443 # of expected passes9246 # of unexpected failures6 # of expected failures41 # of expected passes689 # of expected passes26 # of expected failures3 # of expected passes54 Only 13 unexpected results, but these might be in there with or without LTO. I have not crossed checked it against a standard bootstrap yet.
[Bug c++/62145] match rulers in overload functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62145 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I think clang due to n*0 is not a NULL POINTER constant expression. This is like PR 59704.
[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz --- On 08/14/2014 02:10 PM, Jan Hubicka wrote: I wonder what we should do with both external and comdat here. Jason, can we devirtualize? No, we're setting comdat now to avoid devirtualization, because we can't be confident that we'll be able to refer to the definition where it gets emitted. We had issues where function body was not produced because it is not reachable by the frontend's definition and it would be comdat otherwise. The case of inline function whose out of line body is keyed to another unit seems bit different... The constructor is keyed to other compilation unit here, but we are provided with a body that we will never use (modulo the tree-ssa-pre bug that brings the reference into code). Hmm, we might consider overriding DECL_EXTERNAL so that there's a definition available for devirtualization. I can always implement logic to use it only when it is inlined, but that will probably drag in references to other symbols belonging to the class... Honza
