[Bug c/55125] segfault when declaration of the struct's array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55125 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Closing.
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com --- enough --enable-checking=yes
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 --- Comment #3 from Alexander Potapenko glider at google dot com --- Should be fine to disable this test on Darwin due to what Yury said.
[Bug lto/56706] [4.8 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Summary|[4.8/4.9 Regression]|[4.8 Regression] failure |failure building CP2K at|building CP2K at -flto -O2 |-flto -O2 | --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- The 4.9 problem is gone, not sure which revision fixed this, the only thing I noticed was this comment. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375#c195 and I have now a couple of LTO builds as part of our daily gcc tester, so I'll notice quickly if it regresses. Not sure if it is worth keeping the bug open for 4.8, I guess there will be other issues popping up with 4.8 anyway.
[Bug tree-optimization/59374] [4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59374 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Dec 5 09:12:29 2013 New Revision: 205694 URL: http://gcc.gnu.org/viewcvs?rev=205694root=gccview=rev Log: 2013-12-05 Richard Biener rguent...@suse.de PR tree-optimization/59374 * tree-vect-data-refs.c (vect_slp_analyze_data_ref_dependence): Commonize known and unknown dependence case fixing the allowed read-write dependence case and dropping code that should not matter. * gcc.dg/torture/pr59374-1.c: New testcase. * gcc.dg/torture/pr59374-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59374-1.c trunk/gcc/testsuite/gcc.dg/torture/pr59374-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Dec 5 09:20:51 2013 New Revision: 205696 URL: http://gcc.gnu.org/viewcvs?rev=205696root=gccview=rev Log: 2013-12-05 Richard Biener rguent...@suse.de PR tree-optimization/56787 * gcc.dg/vect/pr56787.c: Adjust to not require vector float division. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr56787.c
[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Maybe it works now.
[Bug tree-optimization/59374] [4.8 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59374 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression]|[4.8 Regression] |-ftree-slp-vectorize breaks |-ftree-slp-vectorize breaks |unique_ptr's move |unique_ptr's move |constructor |constructor Known to fail|4.9.0 | --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 --- Comment #11 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #10) Maybe it works now. PASSes on arm* now, thanks.
[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 --- Comment #5 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Dec 5 09:56:03 2013 New Revision: 205698 URL: http://gcc.gnu.org/viewcvs?rev=205698root=gccview=rev Log: 2013-12-05 Yury Gribov y.gri...@samsung.com PR sanitizer/59368 * Makefile.am (gcc_version): Added gcc_version. * Makefile.in: Regenerate. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/Makefile.am trunk/libsanitizer/Makefile.in
[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 Jan-Benedict Glaw jbg...@lug-owl.de changed: What|Removed |Added CC||jbg...@lug-owl.de --- Comment #15 from Jan-Benedict Glaw jbg...@lug-owl.de --- Some fallout for an unused variable, see eg. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=50585 : g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../../gcc/gcc/c-family/c-common.c ../../../gcc/gcc/c-family/c-common.c: In function ‘tree_node* c_sizeof_or_alignof_type(location_t, tree, bool, bool, int)’: ../../../gcc/gcc/c-family/c-common.c:5007:9: error: unused variable ‘field’ [-Werror=unused-variable] tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE, ^ cc1plus: all warnings being treated as errors
[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org Known to work||4.9.0 Summary|[4.7, 4.8, 4.9 Regression] |[4.7, 4.8 Regression] |regcprop incorrectly looks |regcprop incorrectly looks |through parallel register |through parallel register |swap operation |swap operation Known to fail|4.9.0 | --- Comment #14 from Steven Bosscher steven at gcc dot gnu.org --- fixed on trunk, see comment #13
[Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 --- Comment #6 from Yury Gribov y.gribov at samsung dot com --- Dmitry, please close if trunk works for you.
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 --- Comment #4 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Dec 5 10:00:47 2013 New Revision: 205699 URL: http://gcc.gnu.org/viewcvs?rev=205699root=gccview=rev Log: 2013-12-05 Yury Gribov y.gri...@samsung.com PR sanitizer/59369 * c-c++-common/asan/pr59063-1.c: Disable on non-Linux platforms. * c-c++-common/asan/pr59063-2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/pr59063-1.c trunk/gcc/testsuite/c-c++-common/asan/pr59063-2.c
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 --- Comment #5 from Yury Gribov y.gribov at samsung dot com --- Mac should be fine now. Jack, could you check and close?
[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317 --- Comment #4 from Robert Suchanek robert.suchanek at imgtec dot com --- Created attachment 31384 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31384action=edit LRA dump for testcase
[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317 --- Comment #5 from Robert Suchanek robert.suchanek at imgtec dot com --- Dump attached. Ah, it's not triggered on mips16-linux target but mips-elf. I double checked it with the same svn revision.
[Bug sanitizer/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|bootstrap |sanitizer Resolution|--- |FIXED --- Comment #7 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- .
[Bug target/59393] [4.8/4.9 regression] mips16 code size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||mips16 Target Milestone|--- |4.8.3 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- bb 2: s_4 = key_3(D)-S[0]; ... _15 = _14 * 8; _16 = s_4 + _15; _17 = *_16; ... _21 = _20 * 8; _22 = s_4 + _21; _23 = *_22; ... formerly we'd have created _17 = MEM[key_3].S[_14]; ... _23 = MEM[key_3].S[_20]; which isn't a valid transform. That eventually gets us better addressing mode selection? At RTL this probably (didn't verify) re-associates the key_3 + offsetof(S) + index * 8 expression to a more suitable way and by-passes the multiple-use restriction of combine (forwprop here un-CSEs key_3 + offsetof(S)). In a loop IVOPTs would be the one to utilize target addressing mode information and eventually generate a TARGET_MEM_REF. In non-loops we have SLSR (gimple-ssa-strength-reduction.c) that could serve as a vehicle to generate TARGET_MEM_REFs (it doesn't). In the end I would point at RTL forwprop which is supposed to improve addressing-mode selection. At least on x86_64 I see leaq144(%rsi), %rax ... xorq4096(%rax,%rbx,8), %r8 addl6144(%rax,%r9,8), %r8d as well (and %rsi is live as well), instead of folding the 144 into the dereference offset. forwprop sees (insn 8 5 9 2 (parallel [ (set (reg/v/f:DI 85 [ s ]) (plus:DI (reg/v/f:DI 991 [ key ]) (const_int 144 [0x90]))) (clobber (reg:CC 17 flags)) ... (insn 20 19 21 3 (set (reg:DI 998 [ *_22 ]) (mem:DI (plus:DI (mult:DI (reg:DI 995) (const_int 8 [0x8])) (reg/v/f:DI 85 [ s ])) [2 *_22+0 S8 A64])) ... and then combine folds in an additional addition: Trying 18 - 20: Successfully matched this instruction: (set (reg:DI 998 [ *_22 ]) (mem:DI (plus:DI (plus:DI (mult:DI (reg:DI 994 [ D.1883 ]) (const_int 8 [0x8])) (reg/v/f:DI 85 [ s ])) (const_int 2048 [0x800])) [2 *_22+0 S8 A64])) but of course doesn't consider insn 8 (it's cross basic-block and it has multiple uses). Now there isn't any further forwprop pass after combine (which would maybe now fold in the addition - not sure). Certainly ira/lra/reload do not consider materializing the def in-place either instead of spilling it for you. Not sure how the situation is on mips16, but in the end RTL optimizers are supposed to fixup anything related to addressing mode selection.
[Bug target/59390] presence of __attribute__((target(fma))) declaration breaks __builtin_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-05 Ever confirmed|0 |1 Known to fail||4.7.3, 4.8.2, 4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-05 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Can you try a GCC 4.9 prerelease? The usual workaround is to disable debuginfo generation. And yes, reducing the testcase to a few input files is necessary - you can bisect the linker inputs by adding -r -nostdlibs (performing a partial link).
[Bug tree-optimization/59387] wrong code (hangs) at -Os on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59387 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-05 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/59388] [4.7/4.8/4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work|4.8.2 | Summary|[4.9 Regression] ICE on |[4.7/4.8/4.9 Regression] |valid code at -O1 and above |ICE on valid code at -O1 |on x86_64-linux-gnu |and above on ||x86_64-linux-gnu Known to fail||4.8.2 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- This really is 4.7+ regression, you just need --enable-checking=yes compiler on the branches to reproduce (otherwise it is a silent wrong-code ? ). I'll have a look soon.
[Bug c++/59381] ICE in get_expr_operands, in tree-ssa-operands.c:1035
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59381 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed in 4.7.3.
[Bug c++/59394] New: Unused code generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59394 Bug ID: 59394 Summary: Unused code generated Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: smal.root at gmail dot com Target: AVR Created attachment 31385 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31385action=edit source code GCC: avr-gcc -v Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.8.2/lto-wrapper Target: avr Configured with: /build/avr-gcc/src/gcc-4.8.2/configure --disable-cloog-version-check --disable-install-libiberty --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-linker-build-id --disable-nls --disable-werror --enable-__cxa_atexit --enable-checking=release --enable-clocale=gnu --enable-cloog-backend=isl --enable-gnu-unique-object --enable-gold --enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin --enable-shared --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr --with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld --with-plugin-ld=ld.gold --with-system-zlib Thread model: single gcc version 4.8.2 (GCC) OS: Arch Linux Linux 3.12.0-1-ARCH #1 SMP PREEMPT Wed Nov 6 09:06:27 CET 2013 x86_64 GNU/Linux Command line: avr-gcc -Wall -mmcu=atxmega64a3 -DF_CPU=1600UL -mno-interrupts -Os -pedantic-errors -pedantic -std=c++11 -Wfatal-errors -Wall -I/usr/avr/include -c main.cpp -o obj/Release/main.o main.cpp: In function 'int main()': main.cpp:55:21: warning: variable 'tval32' set but not used [-Wunused-but-set-variable] volatile uint32_t tval32; ^ avr-g++ -o bin/Release/lambda_test.elf obj/Release/main.o -mmcu=atxmega64a3 -Wl,-Map=bin/Release/lambda_test.map,--cref Output size is 7,92 KB Running project post-build steps avr-size bin/Release/lambda_test.elf text databssdechexfilename 850 0 2400 3250cb2 bin/Release/lambda_test.elf avr-objdump -h -S bin/Release/lambda_test.elf bin/Release/lambda_test.lss Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 1 warnings (0 minutes, 0 seconds) Source file: attached main.cpp Generated assembly: attached lambda_test.lss Problem. A. As you can see in generated assembly: 1. function Sort_OldStyle(_Z13Sort_OldStylev) contain(as inline) functions Sort and Sort_OldStyle_Internal 2. function Sort_NewStyle(_Z13Sort_NewStylev) contain(as inline) functions Sort and lambda-expression B. But also generated code contain unneded: 1. function Sort(_Z4SortPV5SPairS1_PFvRS0_E) 2. function Sort_OldStyle_Internal(_Z22Sort_OldStyle_InternalRV5SPair) 3. lambda-expression(_ZZ13Sort_NewStylevENUlRV5SPairE_4_FUNES1_) Why gcc include functions from B-list if they already exist in functions of list A? Also why gcc use inline for function Sort and don't use call with -Os used?
[Bug c++/59394] Unused code generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59394 --- Comment #1 from smalcom smal.root at gmail dot com --- Created attachment 31386 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31386action=edit generated assembly
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #4 from Markus Trippelsdorf octoploid at yandex dot com --- I've tested this on my Gentoo box and cannot reproduce the issue on trunk or gcc-4.8 branch. So it is most likely already fixed.
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-05 Ever confirmed|0 |1 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Btw, the change suggests a workaround - use -fwrapv. And indeed, the loop does not terminate for c == 32768, but that's a bug in the testcase, signed short 32768 is always true (both promote to int, and i++ wraps at 32767). That i++ now correctly wraps 'defined' also means that IV analysis is pessimized as it can not assume that 'i' does not wrap nor can it assume that the loop terminates. But that's just the awkward way the testcase is written (without the C standard in mind ...). You may also try -funsafe-loop-optimizations that makes us optimistically assume IVs don't overflow and loops terminate. confirmed, but I think this one needs more analysis on _what_ transform we want to happen and then get assessment on if that is a valid transform at all.
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #5 from jpakkane at gmail dot com --- I retried this with Gcc 4.8.2 on trusty and no longer get the crash. I have not tried to reproduce David Kredba's issue so that might still remain.
[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Jan-Benedict Glaw from comment #15) Some fallout for an unused variable, see eg. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=50585 : g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../../gcc/gcc/c-family/c-common.c ../../../gcc/gcc/c-family/c-common.c: In function ‘tree_node* c_sizeof_or_alignof_type(location_t, tree, bool, bool, int)’: ../../../gcc/gcc/c-family/c-common.c:5007:9: error: unused variable ‘field’ [-Werror=unused-variable] tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE, ^ cc1plus: all warnings being treated as errors Should be fixed now.
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 --- Comment #3 from Dmitry G. Dyachenko dimhen at gmail dot com --- first FAIL r205461
[Bug middle-end/58956] [4.7/4.8 Regression] wrong code at -O1 and above (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58956 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Dec 5 13:10:20 2013 New Revision: 205709 URL: http://gcc.gnu.org/viewcvs?rev=205709root=gccview=rev Log: 2013-12-05 Richard Biener rguent...@suse.de Backport from mainline 2013-11-19 Richard Biener rguent...@suse.de PR middle-end/58956 * tree-ssa-ter.c (find_replaceable_in_bb): Avoid forwarding loads into stmts that may clobber it. * gcc.dg/torture/pr58956.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58956.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-ter.c
[Bug fortran/59395] New: internal compiler error (memory access error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395 Bug ID: 59395 Summary: internal compiler error (memory access error) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: demarchie at web dot de I receive an ICE when compiling this source code with 4.8.1 and 4.8.2: module mymod implicit none integer, parameter :: k = selected_real_kind(1,1) ! no bug with k = 4 type t integer :: m ! can't swap this line with next one procedure(f), pointer, nopass :: a,b ! have to be at least two of them end type interface integer function f(n) integer :: n end function end interface end module mymod program test use mymod end program test * Output from gfortran source.f90 -save-temps -v 1 gfortran 4.8.1 on OpenBSD/macppc Driving: egfortran source.f90 -save-temps -v -l gfortran -l m Using built-in specs. COLLECT_GCC=egfortran COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-unknown-openbsd5.4/4.8.1/lto-wrapper Target: powerpc-unknown-openbsd5.4 Configured with: /usr/obj/ports/gcc-4.8.1/gcc-4.8.1/configure --enable-libgcj --without-jar --verbose --program-transform-name='s,^,e,' --disable-nls --disable-checking --with-system-zlib --disable-libmudflap --disable-libgomp --disable-tls --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t --with-gmp=/usr/local --enable-languages=c,c++,fortran,objc,java --disable-libstdcxx-pch --enable-cpp --enable-shared --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var --disable-silent-rules Thread model: posix gcc version 4.8.1 (GCC) COLLECT_GCC_OPTIONS='-save-temps' '-v' /usr/local/libexec/gcc/powerpc-unknown-openbsd5.4/4.8.1/f951 source.f90 -quiet -dumpbase source.f90 -auxbase source -version -fintrinsic-modules-path /usr/local/lib/gcc/powerpc-unknown-openbsd5.4/4.8.1/finclude -o source.s GNU Fortran (GCC) version 4.8.1 (powerpc-unknown-openbsd5.4) compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.8.1 (powerpc-unknown-openbsd5.4) compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=131072 f951 in free(): error: chunk is already free 0x86f96060 f951 in malloc(): error: recursive call egfortran: internal compiler error: Abort trap (program f951) libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. 2 gfortran 4.8.2-1 from fink on macppc OS 10.4 Angesteuert: /sw/bin/gfortran -mmacosx-version-min=10.4 source.f90 -save-temps -v -l gfortran -shared-libgcc Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=/sw/bin/gfortran COLLECT_LTO_WRAPPER=/sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/lto-wrapper Ziel: powerpc-apple-darwin8.11.0 Konfiguriert mit: ../gcc-4.8.2/configure --prefix=/sw AS=odas AS_FOR_TARGET=odas NM_FOR_TARGET=odnm LD_FOR_TARGET=odld AR_FOR_TARGET=odar LIPO_FOR_TARGET=odlipo OBJDUMP_FOR_TARGET=odobjdump RANLIB_FOR_TARGET=odranlib STRIP_FOR_TARGET=odstrip --prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=release --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8 --with-dwarf2 --disable-libjava-multilib --disable-libquadmath Thread-Modell: posix gcc-Version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-save-temps' '-v' '-shared-libgcc' /sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/f951 source.f90 -fPIC -quiet -dumpbase source.f90 -mmacosx-version-min=10.4 -auxbase source -version -fintrinsic-modules-path /sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/finclude -o source.s GNU Fortran (GCC) Version 4.8.2 (powerpc-apple-darwin8.11.0) kompiliert von GNU-C-Version 4.8.2, GMP-Version 5.1.3, MPFR-Version 3.1.2, MPC-Version 1.0.1. GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) Version 4.8.2 (powerpc-apple-darwin8.11.0) kompiliert von GNU-C-Version 4.8.2, GMP-Version 5.1.3, MPFR-Version 3.1.2, MPC-Version 1.0.1. GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 [address=61707265 pc=00826c94] source.f90: In Funktion »main«: source.f90:20:0: interner Compiler-Fehler: Speicherzugriffsverletzung [*] use mymod ^ libbacktrace could not find
[Bug fortran/59395] [4.8 Regression] internal compiler error (memory access error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch Known to work||4.7.2, 4.9.0 Summary|internal compiler error |[4.8 Regression] internal |(memory access error) |compiler error (memory ||access error) Known to fail||4.8.3 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- fails with 4.8.3, works with trunk and 4.7
[Bug target/59396] New: [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396
Bug ID: 59396
Summary: [avr] Wrong warning with ISR() and -flto
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Created attachment 31387
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31387action=edit
isr.c: The C source
Following source will throw a warning if compiled, e.g.,
$ avr-gcc isr.c -mmcu=atmega8 -flto
#define __INTR_ATTRS used, externally_visible
#define ISR(vector,...) \
void vector (void) __attribute__ ((signal,__INTR_ATTRS)) __VA_ARGS__; \
void vector (void)
#define ADC_vect __vector_14
ISR (ADC_vect)
{
}
int main()
{
return 0;
}
The defines are copy-pased from AVR-Libc and are the most common way to define
interrupt service routines: Use ISR() with a isr vector name.
The warning is:
In function '__vector_14':
isr.c:10:1: warning: '_vector_14' appears to be a misspelled signal handler
[enabled by default]
ISR (ADC_vect)
^
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target||avr Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-05 Ever confirmed|0 |1
[Bug sanitizer/59397] New: ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59397 Bug ID: 59397 Summary: ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, mpolacek at gcc dot gnu.org Created attachment 31388 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31388action=edit C++ test case, run as g++ -fsanitize=signed-integer-overflow The attached test case fails with: $ g++ -fsanitize=signed-integer-overflow -S test12.ii test12.ii: In function 'int s_vectorizeLoop()': test12.ii:15:29: internal compiler error: in ubsan_encode_value, at ubsan.c:143 dir = three::direction( t + dir ); ^ 0xbc9f03 ubsan_encode_value(tree_node*) ../../gcc/ubsan.c:143 0xbcb814 ubsan_build_overflow_builtin(tree_code, unsigned int, tree_node*, tree_node*, tree_node*) ../../gcc/ubsan.c:667 0xa2c020 ubsan_expand_si_overflow_addsub_check(tree_code, gimple_statement_base*) ../../gcc/internal-fn.c:175
[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59397 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-05 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, the problem is that we don't handle ENUMERAL_TYPEs (nor BOOLEAN_TYPEs). Will be fixed as a part of PR59333 fix. Thanks for report.
[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59397
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Reduced testcase for c-c++-common:
typedef enum E { A = -1 } e;
int
foo (void)
{
e e = A;
return e + 1;
}
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #6 from David Kredba nheghathivhistha at gmail dot com --- I reduced it to this: /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -Wl,--enable-new-dtags -Wl,--no-undefined -lc -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -shared -Wl,-soname,kigpart.so -o lib/kigpart.so CMakeFiles/kigpart.dir/scripting/python_scripter.o -L/usr/lib64/qt4 /usr/lib64/libkparts.so.4.11.4 /usr/lib64/libkutils.so.4.11.4 -lpython2.7 /usr/lib64/libboost_python-2.7-mt.so /usr/lib64/libktexteditor.so.4.11.4 /usr/lib64/libkemoticons.so.4.11.4 /usr/lib64/libkidletime.so.4.11.4 /usr/lib64/libkcmutils.so.4.11.4 /usr/lib64/libkprintutils.so.4.11.4 /usr/lib64/libkparts.so.4.11.4 /usr/lib64/libkio.so.5.11.4 /usr/lib64/qt4/libQtNetwork.so /usr/lib64/qt4/libQtXml.so /usr/lib64/libnepomukutils.so.4.11.4 /usr/lib64/libnepomuk.so.4.11.4 /usr/lib64/libkdeui.so.5.11.4 /usr/lib64/qt4/libQtGui.so /usr/lib64/qt4/libQtSvg.so -lsoprano /usr/lib64/libkdecore.so.5.11.4 /usr/lib64/qt4/libQtCore.so -lpthread /usr/lib64/qt4/libQtDBus.so -Wl,-rpath,/usr/lib64/qt4: -nostdlib lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706 All othe object files removed not let the ICE away. When python_scripter.o removed and other object files present on link command it did this: /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270: undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base const*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `__gnu_cxx::new_allocatorObjectCalcer*::allocate(unsigned long, void const*) [clone .isra.61]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:104: undefined reference to `operator new(unsigned long)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270: undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base const*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `void std::vectorObjectCalcer*, std::allocatorObjectCalcer* ::_M_range_initializestd::_Rb_tree_const_iteratorObjectCalcer* (std::_Rb_tree_const_iteratorObjectCalcer*, std::_Rb_tree_const_iteratorObjectCalcer*, std::forward_iterator_tag) [clone .isra.90]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270: undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base const*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `__gnu_cxx::new_allocatorObjectCalcer*::allocate(unsigned long, void const*) [clone .isra.61]': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:104: undefined reference to `operator new(unsigned long)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `operator++': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/bits/stl_tree.h:270: undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base const*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `deallocate': /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4/ext/new_allocator.h:110: undefined reference to `operator delete(void*)' /tmp/ccXU2sDY.ltrans13.ltrans.o: In function `void std::vectorObjectCalcer*, std::allocatorObjectCalcer*
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 --- Comment #4 from ktkachov at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #3) Working on this again. I'm on the 4th iteration of the fix. Bootstrapping on ARM boxes is painfully slow :( I could bootstrap a patch on arm-none-linux-gnueabihf if you'd like.
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 --- Comment #3 from Jeffrey A. Law law at redhat dot com --- Working on this again. I'm on the 4th iteration of the fix. Bootstrapping on ARM boxes is painfully slow :(
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 --- Comment #5 from Jeffrey A. Law law at redhat dot com --- How fast is your box? I'm using 4 processors on a calxeda system... It's painful, particularly when the first calxeda box's disk died, thus losing my build trees test results.
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #5) How fast is your box? I'm using 4 processors on a calxeda system... It's painful, particularly when the first calxeda box's disk died, thus losing my build trees test results. I'm using a Chromebook with 2 Cortex-A15s. I think it took about 5-6 hours to bootstrap last time I tried. I have a feeling your system might be faster :(
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #72 from Oleg Endo olegendo at gcc dot gnu.org ---
The original test case in PR 59343 is an interesting one with regard to T bit
optimizations (or the lack thereof):
void validate_number (char **numbertext)
{
char *ptr = *numbertext;
int valid = (ptr != 0) (*ptr);
for ( ; valid *ptr; ++ptr)
valid = (*ptr = '0');
if (!valid)
*numbertext = 0;
}
with -Os -m4 -mb it is compiled to:
_validate_number:
mov.l @r4,r2// [bb 2]
tst r2,r2
bt/s.L2
mov #0,r1
mov.b @r2,r1// [bb 3]
tst r1,r1
mov #-1,r1
negcr1,r1
.L2: // [bb 4]
mov #47,r3
.L3: // [bb 5]
tst r1,r1
bt .L4
mov.b @r2+,r1 // [bb 6]
tst r1,r1
bt/s.L8
cmp/gt r3,r1 // [bb 7]
bra .L3
movtr1
.L4:
mov.l r1,@r4 // [bb 8]
.L8:
rts
nop
The basic block starting with L3 (bb 5) has three different r1 inputs from [bb
2], [bb 3] and [bb 7]. When sh_treg_combine tries to trace r1 starting in [bb
5]:
tracing (reg/v:SI 1 r1 [orig:185 valid ] [185])
[bb 5]
set of reg not found. empty BB?
[bb 4]
set of reg not found (cstore)
set not found - aborting trace
Instead it should skip [bb 4] as it doesn't modify r1 or T bit and check [bb 3]
and [bb 2]. Because the setcc insns are not the same in [bb 2], [bb 3] and [bb
7], it would try to eliminate the cstores. However, in [bb 2] there is no real
cstore but a constant load, which can be replaced with a clrt or sett insn
respectively. The resulting code could be something like:
mov.l @r4,r2
mov #0,r1
tst r2,r2
bt/s.L2 // (*)
clrt
mov.b @r2,r1
tst r1,r1
movtr1
tst r1,r1// T = !T
.L2:
mov #47,r3
.L3:
bf .L4
mov.b @r2+,r1
tst r1,r1
bt/s.L8
bra .L3
cmp/gt r3,r1
.L4:
mov.l r1,@r4
.L8:
rts
nop
(*) The clrt insn actually has to be inserted before the conditional branch,
which is impossible as it modifies the branch condition. Putting it into the
delay slot however is OK, which is usually done by the DBR pass. A special
branch and set/clear T pseudo insn would be required (requires SH2+) which
produces the sequence above. A more complicated way would be to create new
basic blocks.
The basic block reordering or similar RTL pass and the clrt/sett optimization
pass should then be able to simplify the code further to:
mov.l @r4,r2
tst r2,r2
bf/s.L4
mov #0,r1
mov.b @r2,r1
tst r1,r1
bt/s.L4
mov #47,r3
.L3:
mov.b @r2+,r1
tst r1,r1
bt/s.L8
cmp/gt r3,r1
bt .L3
.L4:
mov.l r1,@r4
.L8:
rts
nop
[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59397 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Dec 5 18:03:44 2013 New Revision: 205714 URL: http://gcc.gnu.org/viewcvs?rev=205714root=gccview=rev Log: PR sanitizer/59333 PR sanitizer/59397 * ubsan.c: Include rtl.h and expr.h. (ubsan_encode_value): Add new parameter. If expanding, assign a stack slot for DECL_RTL of the temporary and call expand_assignment. Handle BOOLEAN_TYPE and ENUMERAL_TYPE. (ubsan_build_overflow_builtin): Adjust ubsan_encode_value call. * ubsan.h (ubsan_encode_value): Adjust declaration. * internal-fn.c (ubsan_expand_si_overflow_addsub_check): Move ubsan_build_overflow_builtin above expand_normal call. Surround this call with push_temp_slots and pop_temp_slots. (ubsan_expand_si_overflow_neg_check): Likewise. (ubsan_expand_si_overflow_mul_check): Likewise. testsuite/ * c-c++-common/ubsan/pr59333.c: New test. * c-c++-common/ubsan/pr59397.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr59333.c trunk/gcc/testsuite/c-c++-common/ubsan/pr59397.c Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c trunk/gcc/ubsan.h
[Bug sanitizer/59333] ICE with long long and -m32 -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59333 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Dec 5 18:03:44 2013 New Revision: 205714 URL: http://gcc.gnu.org/viewcvs?rev=205714root=gccview=rev Log: PR sanitizer/59333 PR sanitizer/59397 * ubsan.c: Include rtl.h and expr.h. (ubsan_encode_value): Add new parameter. If expanding, assign a stack slot for DECL_RTL of the temporary and call expand_assignment. Handle BOOLEAN_TYPE and ENUMERAL_TYPE. (ubsan_build_overflow_builtin): Adjust ubsan_encode_value call. * ubsan.h (ubsan_encode_value): Adjust declaration. * internal-fn.c (ubsan_expand_si_overflow_addsub_check): Move ubsan_build_overflow_builtin above expand_normal call. Surround this call with push_temp_slots and pop_temp_slots. (ubsan_expand_si_overflow_neg_check): Likewise. (ubsan_expand_si_overflow_mul_check): Likewise. testsuite/ * c-c++-common/ubsan/pr59333.c: New test. * c-c++-common/ubsan/pr59397.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr59333.c trunk/gcc/testsuite/c-c++-common/ubsan/pr59397.c Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c trunk/gcc/ubsan.h
[Bug sanitizer/59333] ICE with long long and -m32 -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59333 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug sanitizer/59397] ICE in ubsan_encode_value, at ubsan.c:143 for -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59397 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug ipa/58253] IPA-SRA creates calls with different arguments that the callee accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Thu Dec 5 18:07:08 2013 New Revision: 205715 URL: http://gcc.gnu.org/viewcvs?rev=205715root=gccview=rev Log: 2013-12-05 Martin Jambor mjam...@suse.cz PR ipa/58253 * ipa-prop.c (ipa_modify_formal_parameters): Create decls of non-BLKmode in their naturally aligned type. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug fortran/59398] New: Wrong bounds for allocatable result and for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398 Bug ID: 59398 Summary: Wrong bounds for allocatable result and for Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: loximann at gmail dot com The lower bounds of the result of an allocatable array-valued function are always set to 1. Also, I discovered that if LHS is allocated and has the same size as RHS, the bounds are not changed. This code illustrates it: program return_allocatable implicit none real, allocatable :: a(:) real, parameter :: b(-2:4)=[1,2,3,4,5,6,7] a=foo(3) print*,lbound(a),':',ubound(a) a=b print*,lbound(a),':',ubound(a) contains function foo(n) integer :: n real, allocatable :: foo(:) allocate(foo(-3:n)) foo=n end function end program The expected output is -3:3 -2:4 but instead I get 1:7 1:7
[Bug middle-end/59399] New: ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59399
Bug ID: 59399
Summary: ICE in expand_expr_real_1 with -m64
-fsanitize=signed-integer-overflow
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
On powerpc64-linux, I'm seeing a failure in the ubsan testsuite that causes an
ICE in expand_real_1, line 9484. A simplified test case is:
[bergner@igoo BUGS]$ cat bug.ii
void
foo (int i, int j)
{
volatile int k = j + i;
}
[bergner@igoo BUGS]$ /home/bergner/gcc/build/gcc-fsf-mainline-debug/gcc/cc1plus
-fpreprocessed -quiet -m64 -fsanitize=signed-integer-overflow bug.ii
bug.ii: In function ‘void foo(int, int)’:
bug.ii:4:22: internal compiler error: in expand_expr_real_1, at expr.c:9484
volatile int k = j + i;
^
0x107c1d2f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/expr.c:9484
0x107b9d57 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/expr.c:7927
0x109590af expand_expr
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/expr.h:453
0x1095a383 ubsan_expand_si_overflow_addsub_check(tree_code,
gimple_statement_base*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/internal-fn.c:182
0x1095b30f expand_UBSAN_CHECK_ADD
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/internal-fn.c:436
0x1095b467 expand_internal_call(gimple_statement_base*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/internal-fn.c:476
0x106071ab expand_call_stmt
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:2185
0x1060b9d3 expand_gimple_stmt_1
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:3154
0x1060c20f expand_gimple_stmt
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:3306
0x106149eb expand_gimple_basic_block
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:5146
0x106170db gimple_expand_cfg
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:5712
0x10617aff execute
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgexpand.c:5932
We're dying in the gcc_assert below:
/* Get the signedness to be used for this variable. Ensure we get
the same mode we got when the variable was declared. */
if (code == SSA_NAME
(g = SSA_NAME_DEF_STMT (ssa_name))
gimple_code (g) == GIMPLE_CALL)
{
gcc_assert (!gimple_call_internal_p (g));
pmode = promote_function_mode (type, mode, unsignedp,
gimple_call_fntype (g),
2);
}
The debugger shows g to be:
(gdb) p *g
$1 = {code = GIMPLE_CALL, no_warning = 0, visited = 0, nontemporal_move = 0,
plf = 0, modified = 0,
has_volatile_ops = 0, subcode = 64, uid = 0, location = 2147483648, num_ops =
5, bb = 0xfffb0070208,
next = 0xfffb00a00a0, prev = 0xfffb00a00a0}
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to gcc-bugzilla-f5d8 from comment #0) Created attachment 31327 [details] miscompilation testcase The attached testcase miscompiles on sh4 target if build with -Os BTW thanks for the test case. It's an interesting case for further optimizations of the sh_treg_combine pass (see PR 51244 comment 72).
[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375 --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Nobuhiro Iwamatsu from comment #4) Oleg and Kojima-san, thanks for your work. Yes, I was building on SH native. And I am using gcc 4.6.3 version in the host. Iwamatsu-san, if you have some time, could you please try building GCC 4.9? I'm sorry, but I don't have the right setup at hand to do it myself at the moment. Also, please notice that the current GCC 4.8 branch has some known problems in the SH parts (produces wrong code) -- I'm working on back porting some patches from 4.9.
[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 --- Comment #12 from Pat Haugen pthaugen at gcc dot gnu.org --- Working on PowerPC also.
[Bug c++/59052] Partial specialization of template with dependent non-type template argument not correctly resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59052 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- This is indeed the same issue as 59044. *** This bug has been marked as a duplicate of bug 59044 ***
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- *** Bug 59052 has been marked as a duplicate of this bug. ***
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/59390] presence of __attribute__((target(fma))) declaration breaks __builtin_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390 --- Comment #3 from Sriraman Tallam tmsriram at google dot com --- JFYI, I am seeing this issue even in gcc-4.7.
[Bug middle-end/59399] ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59399 --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org --- More hopefully useful gdb output: (gdb) pr decl_rtl (reg:DI 123 [ D.2805+-4 ]) (gdb) ptree exp var_decl 0xfffafe31a20 D.2805 type integer_type 0xfffafec0690 int sizes-gimplified public SI size integer_cst 0xfffafe027c0 constant 32 unit size integer_cst 0xfffafe027e0 constant 4 align 32 symtab 0 alias set -1 canonical type 0xfffafec0690 precision 32 min integer_cst 0xfffafe02760 -2147483648 max integer_cst 0xfffafe02780 2147483647 pointer_to_this pointer_type 0xfffafec16f8 used ignored SI file bug.ii line 2 col 1 size integer_cst 0xfffafe027c0 32 unit size integer_cst 0xfffafe027e0 4 align 32 context function_decl 0xfffb0068c00 foo (reg:DI 123 [ D.2805+-4 ]) (gdb) p DECL_MODE (exp) $8 = SImode (gdb) ptree ssa_name ssa_name 0xfffafea0708 type integer_type 0xfffafec0690 int sizes-gimplified public SI size integer_cst 0xfffafe027c0 constant 32 unit size integer_cst 0xfffafe027e0 constant 4 align 32 symtab 0 alias set -1 canonical type 0xfffafec0690 precision 32 min integer_cst 0xfffafe02760 -2147483648 max integer_cst 0xfffafe02780 2147483647 pointer_to_this pointer_type 0xfffafec16f8 visited var var_decl 0xfffafe31a20 D.2805def_stmt _3 = UBSAN_CHECK_ADD (j_1(D), i_2(D)); version 3
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org --- I think this can be closed.
[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040 --- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #11) As far as I can say, the targets with this problem are: avr, bfin, h8300, picochip and sh (for some subtargets of sh). On avr, bfin, h8300 and picochip, we're doomed anyway because there is no double-sized type at all. On sh, we could use long double math calls. I'm making this into an enhancement; it will probably be very painful, because most of the front-end assumes FLOAT_TYPE_SIZE == 32 and DOUBLE_TYPE_SIZE == 64. I think it would be easier to leave DOUBLE_TYPE_SIZE == 64 in all cases and use software fp if the hardware can't do double precision. If users insist on doubles being automatically truncated to floats then there should be a compiler switch for that. E.g. on SH we have -m4-single-only option to control this. On SH2E code would then use hardware fp for floats and software fp for doubles by default.
[Bug rtl-optimization/59317] [4.9 Regression] [LRA,MIPS] ICE: in check_rtl, at lra.c (insn does not satisfy constraints)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Dec 5 19:39:39 2013 New Revision: 205718 URL: http://gcc.gnu.org/viewcvs?rev=205718root=gccview=rev Log: 2013-12-05 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/59317 * lra-constraints.c (in_class_p): Don't ignore insn with constant as a source. 2013-12-05 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/59317 * testsuite/gcc.target/mips/pr59317.c: New. Added: trunk/gcc/testsuite/gcc.target/mips/pr59317.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug target/59385] gcc 4.9 fails to use fma with __attribute__((target(fma)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385 Sriraman Tallam tmsriram at google dot com changed: What|Removed |Added CC||davidxl at google dot com --- Comment #3 from Sriraman Tallam tmsriram at google dot com --- Removing the target attributes and using -ffast-math -ftree-vectorize -mfma on the command line is still not producing vfmadd132sd insn. Investigating.
[Bug middle-end/59399] ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59399 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-05 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Ouch. Reproduced on ppc64.
[Bug middle-end/27906] reload allocates register of live register variable to earlyclobber output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27906 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- I've tried this on rev 205674 (4.9) and it seems that time has fixed the issue.
[Bug ada/36939] Build Failure Ada SH2e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #22 from Oleg Endo olegendo at gcc dot gnu.org --- I think this actual problem is the same as PR 34040.
[Bug target/59189] [SH] machine_dependent_reorg (sh_reorg) creates broken basic block structures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59189 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- Maybe adding a conditional far branch insn, as mentioned in PR 54762, would fix this problem, or at least parts of it.
[Bug target/59400] New: [SH] gcc.c-torture/compile/pr55921.c fails with -O0 on big endian with FPU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59400
Bug ID: 59400
Summary: [SH] gcc.c-torture/compile/pr55921.c fails with -O0 on
big endian with FPU
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The test case gcc.c-torture/compile/pr55921.c has been failing for a while on
big endian targets with an FPU (e.g. SH4) when compiled with -O0.
Little endian seems OK.
typedef union
{
_Complex float cf;
long long ll;
} ucf;
void
foo (ucf *in, ucf *out, _Complex float r)
{
int i;
ucf ucf1;
_Complex float cf;
ucf1.ll = in[i].ll;
__asm ( : =r (cf) : r (ucf1.ll));
cf *= r;
__asm ( : =r (ucf1.ll) : r (cf));
out[i].ll = ucf1.ll;
}
compiled with -O0 -m4 -mb:
sh_tmp.cpp: In function 'foo':
sh_tmp.cpp:641:3: error: 'asm' operand requires impossible reload
__asm ( : =r (cf) : r (ucf1.ll));
^
sh_tmp.cpp:641:3: error: 'asm' operand requires impossible reload
sh_tmp.cpp:643:3: error: 'asm' operand requires impossible reload
__asm ( : =r (ucf1.ll) : r (cf));
^
sh_tmp.cpp:643:3: error: 'asm' operand requires impossible reload
[Bug target/59401] New: [SH] GBR addressing mode optimization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401
Bug ID: 59401
Summary: [SH] GBR addressing mode optimization produces wrong
code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The GBR addressing mode optimization which was added in 4.8 is buggy.
The following example:
struct tcb_t
{
int x, y, z, w;
};
int test_00 (int a, tcb_t* b)
{
tcb_t* tcb = (a 5) ? (tcb_t*)__builtin_thread_pointer () : b;
return tcb-w + tcb-x;
}
compiled with -O2 results in:
mov.l @(12,gbr),r0
mov r0,r2
mov.l @(0,gbr),r0
rts
add r2,r0
which is obviously wrong code. This is because sh_find_base_reg_disp in sh.c
will step insns outside the current basic block without any further
considerations. This is only OK to do if the predecessor basic block has a
fall through edge to the current basic block (i.e. there are no labels in
between). Otherwise the address reg in question might be set in multiple basic
blocks which must be analyzed.
In the above test case GBR addressing modes can't be used actually.
[Bug fortran/59398] Wrong bounds for allocatable result and for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf anlauf at gmx dot de --- Sergio, I'm not sure about the first assignment, but the behavior in the second case is certainly correct. On the first assignment, a is not allocated. On the second assignment, the shape of the RHS is the same, so you get the same result. If you modify your program as follows: program return_allocatable implicit none real, allocatable :: a(:) real, parameter :: b(-2:4)=[1,2,3,4,5,6,7] a=foo(3) print*,lbound(a),':',ubound(a) deallocate (a) a=b print*,lbound(a),':',ubound(a) deallocate (a) contains function foo(n) integer :: n real, allocatable :: foo(:) allocate(foo(-3:n)) foo=n end function end program You get: 1 : 7 -2 : 4 which is what you also get with Intel v14 and Crayftn 8.2.1. However, xlf 14.1.0.5 agrees with you: -3 : 3 -2 : 4 F2k8 states: 7.2.1.3 Interpretation of intrinsic assignments If the variable is an unallocated allocatable array, expr shall have the same rank. If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, ... If the variable is or becomes an unallocated allocatable variable, it is then allocated with ... • if expr is an array, the shape of expr with each lower bound equal to the corresponding element of LBOUND (expr ). Thus the assignment from the allocatable function result is broken.
[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
An example where the base address is retrieved from the GBR in one basic block,
but used in different basic blocks:
struct tcb_t
{
int x, y, z, w;
};
int test_01 (int a, tcb_t* b, int c)
{
tcb_t* tcb = (tcb_t*)__builtin_thread_pointer ();
return (a 5) ? tcb-x : tcb-w;
}
By coincidence it produces correct code:
mov r4,r0
tst #5,r0
bf .L7
mov.l @(12,gbr),r0
rts
nop
.L7:
rts
mov.l @(0,gbr),r0
A proper fix for this would be to collect all leaf values for the address
registers in question from all predecessor basic blocks as it's done in the
function sh_optimize_sett_clrt::find_last_ccreg_values in
sh_optimize_sett_clrt.cc.
[Bug fortran/59398] Wrong bounds for allocatable result and for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398 --- Comment #2 from Sergio Losilla loximann at gmail dot com --- There should be no need to deallocate. From the excerpt you copied: If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape. For the second, the obtained shape should *always* be the same. It looks like gfortran will not touch LHS if it is allocated and has the same size as RHS. And that should not be the case. By the way, the Intel compiler is quite crazy. Version 11 something works as expected in a platform I have access to, but 12 and 13 fail one or both assignments!
[Bug fortran/59398] Wrong bounds for allocatable result and for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398 --- Comment #3 from Harald Anlauf anlauf at gmx dot de --- (In reply to Sergio Losilla from comment #2) There should be no need to deallocate. From the excerpt you copied: If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape. shape(-3:3) == shape (-2:4) == shape(1:7) Shape is UBOUND-LBOUND+1. For the second, the obtained shape should *always* be the same. It looks like gfortran will not touch LHS if it is allocated and has the same size as RHS. And that should not be the case. No, gfortran is right here, see above. By the way, the Intel compiler is quite crazy. Version 11 something works as expected in a platform I have access to, but 12 and 13 fail one or both assignments! Funny! Would you please report to the Intel forum?
[Bug fortran/59395] [4.8 Regression] internal compiler error (memory access error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-05 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org --- This reduced test case also fails with 4.8.1: implicit none type t procedure(), pointer, nopass :: a,b end type end with the following error: *** Error in `/usr/lib/gcc/x86_64-linux-gnu/4.8/f951': double free or corruption (fasttop): 0x01bddec0 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x7f326bd12996] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z15gfc_free_symbolP10gfc_symbol+0x58)[0x5bc048] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5bc1f4] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5bc1e2] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5bc1eb] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z18gfc_free_namespaceP13gfc_namespace+0x4b)[0x5bbebb] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z17gfc_symbol_done_2v+0x10)[0x5bc460] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z10gfc_done_2v+0x9)[0x579299] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z14gfc_parse_filev+0x6ea)[0x58c88a] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x5c8306] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x8a5906] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951(_Z11toplev_mainiPPc+0x9ba)[0x8a73ca] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f326bcb3de5] /usr/lib/gcc/x86_64-linux-gnu/4.8/f951[0x51eebf]
[Bug fortran/59398] Wrong bounds for allocatable result and for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398 --- Comment #4 from Harald Anlauf anlauf at gmx dot de --- I also tested the modified case with NAG 5.3.2(951). It agrees with gfortran. I now wonder whether there is something special about allocatable function results.
[Bug target/51523] LTO keeps unneeded functions (mingw32 target)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51523 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Ok, due it is a linker-bug, I close this bug as invalid. If it is shown later that issue is however caused by gcc, please re-open.
[Bug sanitizer/59402] New: [4.9 Regression] bootstrap failure on x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402 Bug ID: 59402 Summary: [4.9 Regression] bootstrap failure on x32 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org r205700 breaks bootstrap for x32: http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00118.html 2 patches are posted at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00525.html as well as http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131202/197727.html
[Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.9.0
[Bug c++/59052] Partial specialization of template with dependent non-type template argument not correctly resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59052 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Dec 5 22:46:36 2013 New Revision: 205720 URL: http://gcc.gnu.org/viewcvs?rev=205720root=gccview=rev Log: PR c++/59044 PR c++/59052 * pt.c (most_specialized_class): Use the partially instantiated template for deduction. Drop the TMPL parameter. Added: trunk/gcc/testsuite/g++.dg/template/partial14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Dec 5 22:46:36 2013 New Revision: 205720 URL: http://gcc.gnu.org/viewcvs?rev=205720root=gccview=rev Log: PR c++/59044 PR c++/59052 * pt.c (most_specialized_class): Use the partially instantiated template for deduction. Drop the TMPL parameter. Added: trunk/gcc/testsuite/g++.dg/template/partial14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/59044] [4.8/4.9 Regression] Internal compiler error triggers when accessing a typedef in a specialized member class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Dec 5 23:28:25 2013 New Revision: 205723 URL: http://gcc.gnu.org/viewcvs?rev=205723root=gccview=rev Log: PR c++/59044 PR c++/59052 * pt.c (most_specialized_class): Use the partially instantiated template for deduction. Drop the TMPL parameter. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/partial14.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/59052] Partial specialization of template with dependent non-type template argument not correctly resolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59052 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Dec 5 23:28:25 2013 New Revision: 205723 URL: http://gcc.gnu.org/viewcvs?rev=205723root=gccview=rev Log: PR c++/59044 PR c++/59052 * pt.c (most_specialized_class): Use the partially instantiated template for deduction. Drop the TMPL parameter. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/partial14.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug target/59371] [4.8/4.9 Regression] Performance regression in GCC 4.8 and later versions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371 --- Comment #8 from Maciej W. Rozycki ma...@linux-mips.org --- Richard, I wasn't aware integer promotions applied here, thanks for pointing it out. New code is therefore correct while old one was not. Unfortunately neither -fwrapv nor -funsafe-loop-optimizations changes anything. Maciej
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org ---
Yeah, the issue is the use of frame-pointer ... instead we should use here
stack-pointer relative addressing as we are that way realigned stack-pointer
agnostic.
Following patch solves the issue. Could you give it a try?
Index: i386.c
===
--- i386.c(Revision 205719)
+++ i386.c(Arbeitskopie)
@@ -10934,18 +10934,21 @@ ix86_expand_prologue (void)
}
m-fs.sp_offset += allocate;
+ /* Use stack_pointer_rtx for relative addressing so that code
+ works for realigned stack, too. */
if (r10_live eax_live)
{
- t = choose_baseaddr (m-fs.sp_offset - allocate);
+ t = plus_constant (Pmode, stack_pointer_rtx, 0 - allocate);
emit_move_insn (gen_rtx_REG (word_mode, R10_REG),
gen_frame_mem (word_mode, t));
- t = choose_baseaddr (m-fs.sp_offset - allocate - UNITS_PER_WORD);
+ t = plus_constant (Pmode, stack_pointer_rtx,
+ 0 - allocate - UNITS_PER_WORD);
emit_move_insn (gen_rtx_REG (word_mode, AX_REG),
gen_frame_mem (word_mode, t));
}
else if (eax_live || r10_live)
{
- t = choose_baseaddr (m-fs.sp_offset - allocate);
+ t = plus_constant (Pmode, stack_pointer_rtx, 0 - allocate);
emit_move_insn (gen_rtx_REG (word_mode,
(eax_live ? AX_REG : R10_REG)),
gen_frame_mem (word_mode, t));
[Bug c++/59403] New: [4.8.2] Segmentation fault in crash_signal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59403 Bug ID: 59403 Summary: [4.8.2] Segmentation fault in crash_signal Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boaz at alum dot mit.edu Our project compiles OK with 4.8.1 ; however switching to 4.8.2 causes g++ to segfault !! When -v -save-temps is added to the command line options, the compilation passes OK !! $ uname -a Linux ws-boaz 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/paraccel/gcc_4_8_2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/opt/paraccel/gcc_4_8_2 --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.8.2 (GCC) --- $ g++ -c -g -DXEN_DEBUG -W -Wall -Werror -fdiagnostics-show-option -Wno-error=uninitialized -Wno-error=strict-overflow -Wno-error=strict-aliasing -Wno-unused-local-typedefs -I /home/paraccel/branches/gcc_4_8_2/obj/utils -L /home/paraccel/branches/gcc_4_8_2/obj/utils -DLINUX -DSYS=B4_2 -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/mb -I/home/paraccel/branches/gcc_4_8_2/src/sys -I/home/paraccel/branches/gcc_4_8_2/src/xen_utils -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/libpq -I/home/paraccel/branches/gcc_4_8_2/src/backup -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/catalog -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/commands -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/storage -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/nodes -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/access -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include/utils -I/home/paraccel/branches/gcc_4_8_2/obj/pg -I/home/paraccel/branches/gcc_4_8_2/src/pg/src/include -I/home/paraccel/branches/gcc_4_8_2/src/sysmgr -I/home/paraccel/branches/gcc_4_8_2/obj/backup /home/paraccel/branches/gcc_4_8_2/src/backup/backupdb.cpp In file included from /home/paraccel/branches/gcc_4_8_2/src/xen_utils/xen_global.hpp:11:0, from /home/paraccel/branches/gcc_4_8_2/src/xen_utils/xen_except.hpp:33, from /home/paraccel/branches/gcc_4_8_2/src/backup/backupdb.cpp:32: /home/paraccel/branches/gcc_4_8_2/src/xen_utils/bigint.hpp:17:7: internal compiler error: Segmentation fault class Bigint ^ 0x890fdf crash_signal ../.././gcc/toplev.c:332 0x6b2239 add_name_attribute ../.././gcc/dwarf2out.c:15722 0x6b2239 modified_type_die ../.././gcc/dwarf2out.c:10197 0x6b3c8b add_type_attribute ../.././gcc/dwarf2out.c:16497 0x6be2e9 gen_formal_parameter_die ../.././gcc/dwarf2out.c:17089 0x6bec16 gen_formal_types_die ../.././gcc/dwarf2out.c:17185 0x6aba6a gen_subprogram_die ../.././gcc/dwarf2out.c:17919 0x6afa28 gen_decl_die ../.././gcc/dwarf2out.c:19994 0x6b1570 gen_member_die ../.././gcc/dwarf2out.c:19045 0x6b1570 gen_struct_or_union_type_die ../.././gcc/dwarf2out.c:19117 0x6b1570 gen_tagged_type_die ../.././gcc/dwarf2out.c:19307 0x6b1c8e gen_type_die_with_usage ../.././gcc/dwarf2out.c:19454 0x6b0112 gen_decl_die ../.././gcc/dwarf2out.c:20017 0x7ff915 rest_of_type_compilation(tree_node*, int) ../.././gcc/passes.c:215 0x52c1d7 finish_struct_1(tree_node*) ../.././gcc/cp/class.c:6444 0x52cdfc finish_struct(tree_node*, tree_node*) ../.././gcc/cp/class.c:6609 0x5459c6 cp_parser_class_specifier_1 ../.././gcc/cp/parser.c:18412 0x5459c6 cp_parser_class_specifier ../.././gcc/cp/parser.c:18620 0x5459c6 cp_parser_type_specifier ../.././gcc/cp/parser.c:13682 0x5587b5 cp_parser_decl_specifier_seq ../.././gcc/cp/parser.c:11007 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. *** Error code 1
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-12-06
Ever confirmed|0 |1
--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
Issue is that for SEH-target we need to generate dw2 unwind-information so that
-fasynchronous-unwind-tables works proper.
Following patch should fix that:
Index: i386.c
===
--- i386.c (Revision 205719)
+++ i386.c (Arbeitskopie)
@@ -3698,6 +3698,9 @@ ix86_option_override_internal (bool main_args_p,
{
if (opts-x_optimize = 1 !opts_set-x_flag_omit_frame_pointer)
opts-x_flag_omit_frame_pointer = !USE_X86_64_FRAME_POINTER;
+ if (opts-x_flag_asynchronous_unwind_tables == 1
+ TARGET_SEH)
+ opts-x_flag_unwind_tables = 1;
if (opts-x_flag_asynchronous_unwind_tables == 2)
opts-x_flag_unwind_tables
= opts-x_flag_asynchronous_unwind_tables = 1;
[Bug lto/50351] An internal compiler error when building gcc4.6 using -flto -fuse-linker-plugin on Win7 mingw64 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-06 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- I rechecked reported issue with current trunk-version and didn't saw this ICE anymore. Also with newer 4.7 version I can't reproduce issue. Could you please retest and tell me if issue is still reproducable for you?
[Bug target/59390] presence of __attribute__((target(fma))) declaration breaks __builtin_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390
--- Comment #4 from Sriraman Tallam tmsriram at google dot com ---
Here is the problem. GCC adds target-specific builtins on demand. The FMA
target-specific builtin __builtin_ia32_vfmaddpd gets added via this
declaration:
void fun() __attribute__((target(fma)));
Specifically, the builtin __builtin_ia32_vfmaddpd gets added when
ix86_add_new_builtins is called from ix86_valid_target_attribute_tree when
processing this target attribute.
Now, when the vectorizer is processing the builtin __builtin_fma in function
other_fn(), it checks to see if this function is vectorizable and calls
ix86_builtin_vectorized_function in i386.c. That returns the builtin stored
here:
case BUILT_IN_FMA:
if (out_mode == DFmode in_mode == DFmode)
{
if (out_n == 2 in_n == 2)
return ix86_builtins[IX86_BUILTIN_VFMADDPD];
ix86_builtins[IX86_BUILTIN_VFMADDPD] would have contained NULL_TREE had the
builtin not been added by the previous target attribute. That is why the code
works if we remove the previous declaration.
The fix then is to not just return the builtin but to also check if the current
function's isa allows the use of the builtin. For instance, this patch would
solve the problem:
@@ -33977,7 +33977,13 @@ ix86_builtin_vectorized_function (tree fndecl, tre
if (out_mode == DFmode in_mode == DFmode)
{
if (out_n == 2 in_n == 2)
-return ix86_builtins[IX86_BUILTIN_VFMADDPD];
+{
+ if (ix86_builtins_isa[IX86_BUILTIN_VFMADDPD].isa
+ global_options.x_ix86_isa_flags)
+return ix86_builtins[IX86_BUILTIN_VFMADDPD];
+ else
+return NULL_TREE;
+}
but there are many instances of this usage in ix86_builtin_vectorized_function.
I will make a patch to cover all these cases and send for review.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #14 from Kai Tietz ktietz at gcc dot gnu.org --- Does this problem still exists for you with current 4.7 branch? For me recent bootstrap multilib 64-bit, and 32-bit are working without issues on 4.7.x
[Bug target/59375] internal compiler error: in expand_shift_1, at expmed.c:2245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375 --- Comment #6 from Nobuhiro Iwamatsu iwamatsu at nigauri dot org --- (In reply to Oleg Endo from comment #5) (In reply to Nobuhiro Iwamatsu from comment #4) Oleg and Kojima-san, thanks for your work. Yes, I was building on SH native. And I am using gcc 4.6.3 version in the host. Iwamatsu-san, if you have some time, could you please try building GCC 4.9? I'm sorry, but I don't have the right setup at hand to do it myself at the moment. Sure. I will build gcc 4.9 soon. When I get result, I report this bug. Also, please notice that the current GCC 4.8 branch has some known problems in the SH parts (produces wrong code) -- I'm working on back porting some patches from 4.9. I see. I am looking forward to your backport patch!
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
A small run-time testcase. It went into an finite loop at -O.
---
[hjl@gnu-mic-2 pr59379]$ cat main.c
#include stdlib.h
typedef unsigned long int __cpu_mask;
void *
__attribute__((malloc, noinline))
gomp_malloc (size_t s)
{
return malloc (s);
}
typedef struct
{
__cpu_mask __bits[1024 / (8 * sizeof (__cpu_mask))];
} cpu_set_t;
unsigned long gomp_cpuset_size __attribute__ ((visibility (hidden)));
cpu_set_t *gomp_cpusetp __attribute__ ((visibility (hidden)));
static unsigned long gomp_get_cpuset_size;
void
__attribute__ ((noinline))
gomp_init_num_threads (void)
{
gomp_cpuset_size = 8;
gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
do
{
gomp_get_cpuset_size = gomp_cpuset_size;
unsigned long i;
for (i = gomp_cpuset_size * 8; i; i--)
if ((__extension__
({ size_t __cpu = (i - 1);
__cpu 8 * (gomp_cpuset_size)
? const __cpu_mask *) ((gomp_cpusetp)-__bits))[((__cpu) / (8 *
sizeof (__cpu_mask)))] ((__cpu_mask) 1 ((__cpu) % (8 * sizeof
(__cpu_mask)) != 0
: 0;
})))
break;
gomp_cpuset_size = i) + (8 * sizeof (__cpu_mask)) - 1) / (8 * sizeof
(__cpu_mask))) * sizeof (__cpu_mask));
return;
}
while (1);
}
int
main ()
{
gomp_init_num_threads ();
return 0;
}
[hjl@gnu-mic-2 pr59379]$ make run
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/ -O -o x main.c
./x
make: *** wait: No child processes. Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes. Stop.
---
[Bug c++/59404] New: declaration shadowing template parameter wrongly accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59404
Bug ID: 59404
Summary: declaration shadowing template parameter wrongly
accepted
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sami.liedes at iki dot fi
Hi,
This code compiles with gcc -std=c++11 (but is rejected by clang++):
-
template typename T
struct A {
templatetypename T2
void f() {
typedef int T;
}
};
void g() {
Aint a;
a.fint();
}
-
However if the third line (templatetypename T2) is removed, GCC correctly
rejects the code because typedef int T shadows the template parameter T.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.8.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-7'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-7)
[Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kcc at gcc dot gnu.org --- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org --- Thanks for the report, H.J. I'll try to respond properly on Monday (-ish). Long term, everyone would benefit if you could setup a public build bot upstream.
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 --- Comment #6 from Andrew Church achurch+gcc at achurch dot org --- Still broken for me, sorry. Using SVN r205727 with the patch, the assembly now looks like: _bar: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 83 e4 f0and$0xfff0,%esp 6: 50 push %eax 7: b8 1c 10 00 00 mov$0x101c,%eax c: e8 00 00 00 00 call 11 _bar+0x11 d: DISP32 ___chkstk_ms 11: 29 c4 sub%eax,%esp 13: 8b 84 24 e4 ef ff ffmov-0x101c(%esp),%eax so it's using the stack pointer but the offset is in the wrong direction. Should 0 - allocate be just allocate in the plus_constant() calls?
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #15 from Dongsheng Song dongsheng.song at gmail dot com --- gcc 4.7.x never have such issue. for gcc 4.8.x or trunk, I did not build multilib long ago. because I can not build multilib which x64 use SEH, and x86 use SJLJ. I must build with SJLJ for x64 and x86.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #39 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Sergey Matveev from comment #37) I've patched LSan to use the real memset(). At least on my machine this brought no performance improvement compared to kcc's latest change (just FYI - not trying to make any point). After the latest sanitizer merge, I see a significant reduction in the overhead of -fsanitize=leak (overhead went down from ~20% to 5%). Nice!
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #40 from Kostya Serebryany kcc at gcc dot gnu.org --- Thanks for the feedback! Is there anything else left in this bug? If not, please close this one and open another for the next problem(s)
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #8 from Dongsheng Song dongsheng.song at gmail dot com --- It's hard to understand SEH reqiure unwind table in DWARF 2 format. can you give me a brief description ? Your patch does not help: $ cat EOF | ./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -O2 -o `mktemp` -c -x c++ -fasynchronous-unwind-tables - /dev/null #pragma GCC target(sse4a) EOF stdin:1:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH $ ./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-windows-gcc49/libexec/gcc/x86_64-w64-mingw32/4.9.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure --prefix=/home/cauchy/cross/x86_64-windows-gcc49 --with-sysroot=/home/cauchy/cross/x86_64-windows-gcc49 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=core2 --with-tune=generic Thread model: win32 gcc version 4.9.0 20131206 (experimental) (GCC) Build the gcc 4.9 x64 native compiler from the gcc 4.9 cross compiler still failed: x86_64-w64-mingw32-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include \ /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c In file included from /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:27:0, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/winnt.h:1495, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/minwindef.h:146, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windef.h:8, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windows.h:69, from /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c:29: /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:28: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4.2) ^ make[2]: *** [host-mingw32.o] Error 1 make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc/gcc' make[1]: *** [install-strip-gcc] Error 2 make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc' make: *** [install-strip] Error 2 $ svn info mingw-w64/trunk/ gcc/trunk/ Path: mingw-w64/trunk URL: svn://svn.code.sf.net/p/mingw-w64/code/trunk Repository Root: svn://svn.code.sf.net/p/mingw-w64/code Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1 Revision: 6392 Node Kind: directory Schedule: normal Last Changed Author: ktietz70 Last Changed Rev: 6392 Last Changed Date: 2013-12-05 18:06:07 +0800 (Thu, 05 Dec 2013) Path: gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID:
