[Bug tree-optimization/63569] [5.0 Regression] Wrong code with volatile and ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63569 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Any progress with fixing this bug? It still breaks building the Linux kernel with 5.0: net/core/dev.c: In function ‘dev_change_net_namespace.part.22’: net/core/dev.c:7285:1: internal compiler error: in verify_ssa, at tree-ssa.c:939 subsys_initcall(net_dev_init); ^
[Bug middle-end/61225] [5 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #15 from Zhenqiang Chen zhenqiang.chen at arm dot com --- Thank you for the reminder. I will rework the patch.
[Bug ipa/63970] [4.9/5 Regression] gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63970
--- Comment #4 from wmi at google dot com ---
(In reply to Jan Hubicka from comment #3)
Created attachment 34047 [details]
Patch
Something like this (untested) may work
Thanks! I tested your patch after minor change. It passed bootstrap and
regression. It also solved the performance regression we saw in internal
benchmarks.
+ if (origin_node !origin_node-used_as_abstract_origin)
+{
+ origin_node-used_as_abstract_origin = true;
+ enqueue_node (origin_node, first, reachable); // enqueue_node
moved here
+ gcc_assert (!origin_node-prev_sibling_clone);
+ gcc_assert (!origin_node-next_sibling_clone);
+ for (origin_node = origin_node-clones; origin_node;
+ origin_node = origin_node-next_sibling_clone)
+if (origin_node-decl == DECL_ABSTRACT_ORIGIN (node-decl))
+ origin_node-used_as_abstract_origin = true;
+}
Wei.
[Bug lto/63998] gcc.dg/lto/pr60820 fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63998
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 20 Nov 2014, dominiq at lps dot ens.fr wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63998
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
If so, it would probably need
// { dg-additional-options -Wl,-undefined,dynamic_lookup { target
*-*-darwin* } }
// { dg-additional-options -Wl,-flat_namespace { target *-*-darwin[89]* }
}
(see gcc.dg/attr-weakref-1.c).
Untested so far.
It does not work because lto does not support dg-additional-options.
I confirm that adding -w to dg-lto-options fixes the failures. However I have
noticed that there is a lto_prune_warns in lib/lto.exp. It would probably
better to add
warning: alias definitions not supported in Mach-O; ignored to the list.
I'd rather skip the test for darwin then. The test tests sth with
weak which results in alias definitions, so if that doesn't work
then what's the point testing it?
Richard.
[Bug tree-optimization/61750] Compiling gfortran.dg/where_operator_assign_2.f90 with -O3 -fwhole-program gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61750 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|ipa |tree-optimization Known to work||4.9.3 Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/61750] Compiling gfortran.dg/where_operator_assign_2.f90 with -O3 -fwhole-program gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61750 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Nov 21 08:27:39 2014 New Revision: 217906 URL: https://gcc.gnu.org/viewcvs?rev=217906root=gccview=rev Log: 2014-11-21 Richard Biener rguent...@suse.de PR tree-optimization/61750 * tree-ssa-forwprop.c (simplify_vce): Verify type sizes match for the resulting VIEW_CONVERT_EXPR. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-forwprop.c
[Bug target/63986] [5 Regression][SH] gcc.target/sh/pr51244-15.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63986 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |target --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Right. Let's put it back to target land then. I think what the tree level does is reasonable.
[Bug lto/63998] gcc.dg/lto/pr60820 fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63998 --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Fri Nov 21 08:38:41 2014 New Revision: 217907 URL: https://gcc.gnu.org/viewcvs?rev=217907root=gccview=rev Log: PR lto/63998 * gcc.dg/lto/pr60820_0.c: Skip on darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lto/pr60820_0.c
[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 --- Comment #2 from Airbak airbak.li at huawei dot com --- lijianhui@key:~$ arm-unknown-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-unknown-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/os/lijianhui/linaro/new-crosstool-ng/install-2-multilib/bin/../libexec/gcc/arm-unknown-linux-gnueabi/4.9.2/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: /home/os/lijianhui/linaro/new-crosstool-ng/.build/src/gcc-linaro-4.9-2014.09/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-unknown-linux-gnueabi --prefix=/home/os/lijianhui/linaro/new-crosstool-ng/install --with-sysroot=/home/os/lijianhui/linaro/new-crosstool-ng/install/arm-unknown-linux-gnueabi/libc --enable-languages=c,c++ --with-pkgversion='crosstool-NG 1.20.0 - Linaro GCC 4.9-2014.09' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --disable-libmudflap --enable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --with-gmp=/home/os/lijianhui/linaro/new-crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-mpfr=/home/os/lijianhui/linaro/new-crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-mpc=/home/os/lijianhui/linaro/new-crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-isl=/home/os/lijianhui/linaro/new-crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-cloog=/home/os/lijianhui/linaro/new-crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --with-libelf=/home/os/lijianhui/linaro/new-crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --disable-nls --with-local-prefix=/home/os/lijianhui/linaro/new-crosstool-ng/install/arm-unknown-linux-gnueabi/libc --enable-c99 --enable-long-long --with-multilib-list=aprofile --with-system-zlib Thread model: posix gcc version 4.9.2 20140904 (prerelease) (crosstool-NG 1.20.0 - Linaro GCC 4.9-2014.09)
[Bug lto/63998] gcc.dg/lto/pr60820 fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63998 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #5) I'd rather skip the test for darwin then. The test tests sth with weak which results in alias definitions, so if that doesn't work then what's the point testing it? Confirmed fixed, as indicated. Thanks.
[Bug lto/63998] gcc.dg/lto/pr60820 fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63998 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug sanitizer/64013] New: [5 Regression] libsanitizer fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013
Bug ID: 64013
Summary: [5 Regression] libsanitizer fails to build
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth 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
[35101s] I: Program returns random data in a function
[35101s] E: gcc5 no-return-in-nonvoid-function
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:295
bool FileExists(const char *filename) {
#if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
struct stat st;
if (internal_syscall(SYSCALL(newfstatat), AT_FDCWD, filename, st, 0))
return false;
#else
struct stat st;
if (internal_stat(filename, st))
return false;
// Sanity check: filename is a regular file.
return S_ISREG(st.st_mode);
#endif
}
the SANITIZER_USES_CANONICAL_LINUX_SYSCALLS misses a return.
[Bug sanitizer/64013] [5 Regression] libsanitizer fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug sanitizer/64013] [5 Regression] libsanitizer fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Note the message is from our package build process scanning for severe warnings and failing package build because of that. Thus there is a no return in non-void function warning generated by GCC during the build of libsanitizer, in the particular case on aarch64-linux.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|DUPLICATE |--- Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Ah, ISTR this from another bug where I wanted to investigate but never got along doing that ... Well for DOM the issue here is that it doesn't handle the aggregate init a = *.LC0; followed by a partial read from a. But I wanted to analyze why FRE can't handle this either - sth I'll now do with a modified pass pipeline (though fixing that won't help you here).
[Bug debug/63243] [meta-bug] RH GDB project tracker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243 Bug 63243 depends on bug 63239, which changed state. Bug 63239 Summary: DWARF does not represent C++ deleted methods https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2014-11-21
CC||fxcoudert at gcc dot gnu.org
Resolution|FIXED |---
Ever confirmed|0 |1
--- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
The testcase fails on x86_64-apple-darwin14. With g++ -O -std=c++11 -g -dA
a.c, we have the following optimized tree dump:
;; Function void bar() (_Z3barv, funcdef_no=3, decl_uid=2126, cgraph_uid=3,
symbol_order=3)
void bar() ()
{
bb 2:
# DEBUG this = foo
return;
}
The assembler (see attachment) does not contain DW_AT_GNU_deleted.
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Created attachment 34063 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34063action=edit Assembler generated at -O -std=c++11 -g -dA
[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57519 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-11-21 CC||fxcoudert at gcc dot gnu.org Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) The test g++.dg/debug/dwarf2/imported-decl-2.C introduced in r211151 fails on darwin Still fails with current trunk on x86_64-apple-darwin14. I am attaching the assembler generated by g++ -gdwarf-2 -dA -O0 -fno-merge-debug-strings imported-decl-2.C -S -fverbose-asm.
[Bug debug/57519] DW_TAG_imported_declaration put in wrong class (base class instead of derived class)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57519 --- Comment #7 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Created attachment 34064 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34064action=edit Code generated for the testcase by g++ -gdwarf-2 -dA -O0 -fno-merge-debug-strings imported-decl-2.C -S -fverbose-asm
[Bug target/64014] [5 regression] Failure of gcc.dg/torture/stackalign/regparm-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64014 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||x86_64-apple-darwin14 Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-21 Host||x86_64-apple-darwin14 Ever confirmed|0 |1 Build||x86_64-apple-darwin14
[Bug target/64014] New: [5 regression] Failure of gcc.dg/torture/stackalign/regparm-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64014
Bug ID: 64014
Summary: [5 regression] Failure of
gcc.dg/torture/stackalign/regparm-1.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
On x86_64-apple-darwin14, gcc.dg/torture/stackalign/regparm-1.c is failing (at
-m32). This regression was introduced somewhere between r217694 (passes) and
r217836 (fails).
Reduced reproducer is:
int __attribute__ ((__regparm__(3)))
test_realigned (int j, int k, int l)
{
int y __attribute__((aligned(64)));
return ((__PTRDIFF_TYPE__) y) (__alignof__(y) - 1);
}
which fails with gcc -m32 with an ICE. The backtrace is:
frame #9: 0x000100d2df56 cc1`fancy_abort(file=unavailable,
line=unavailable, function=unavailable) + 38 at diagnostic.c:1249
frame #10: 0x000100ce2047 cc1`ix86_expand_prologue() + 5751 at
i386.c:11347
frame #11: 0x0001002374fb cc1`gen_prologue() + 11 at i386.md:12095
frame #12: 0x00010064d82c cc1`thread_prologue_and_epilogue_insns() +
204 at function.c:5906
frame #13: 0x00010064e207 cc1`execute [inlined]
rest_of_handle_thread_prologue_and_epilogue + 22 at function.c:6476
frame #14: 0x00010064e1f1 cc1`execute(this=unavailable,
(null)=unavailable) + 1
frame #15: 0x0001008b1c6b cc1`execute_one_pass(pass=0x000141e13910)
+ 379 at passes.c:2311
frame #16: 0x0001008b210e
cc1`execute_pass_list_1(pass=0x000141e13910) + 30 at passes.c:2363
frame #17: 0x0001008b2120
cc1`execute_pass_list_1(pass=0x000141e13670) + 48 at passes.c:2364
frame #18: 0x0001008b2120
cc1`execute_pass_list_1(pass=0x000141e12590) + 48 at passes.c:2364
frame #19: 0x0001008b2169 cc1`execute_pass_list(fn=0x000142d1f5e8,
pass=0x000141e0f3b0) + 25 at passes.c:2374
frame #20: 0x0001004cbde5
cc1`cgraph_node::expand(this=0x000142c12498) + 261 at cgraphunit.c:1773
frame #21: 0x0001004ccd0f cc1`output_in_order(no_reorder=unavailable)
+ 559 at cgraphunit.c:2011
frame #22: 0x0001004cd27a
cc1`symbol_table::compile(this=0x000142c05000) + 922 at cgraphunit.c:2257
frame #23: 0x0001004cf3ce
cc1`symbol_table::finalize_compilation_unit(this=0x000142c05000) + 110 at
cgraphunit.c:2340
frame #24: 0x000100020ec9 cc1`c_write_global_declarations() + 601 at
c-decl.c:10777
frame #25: 0x00010098d20f cc1`compile_file + 143 at toplev.c:584
Any optimization (-O1, -O2, -O3 or -Os) makes the testcase pass.
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 --- Comment #10 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Richard Biener from comment #8) But yes, adding -fno-ipa-icf to dg-options is fine with me (and pre-approved). I'm a bit worried that by manually disabling ipa-icf we paper over the bugs on darwin, rather than get them fixed in the first place.
[Bug target/63910] [5 Regression] ICE: simplify_immed_subreg, at simplify-rtx.c:5519 with -mstringop-strategy=vector_loop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63910 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Nov 21 09:23:26 2014 New Revision: 217908 URL: https://gcc.gnu.org/viewcvs?rev=217908root=gccview=rev Log: PR target/63910 * simplify-rtx.c (simplify_immed_subreg): Return NULL for integer modes wider than MAX_BITSIZE_MODE_ANY_INT. If not using CONST_WIDE_INT, make sure r fits into CONST_DOUBLE. * gcc.target/i386/pr63910.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr63910.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63764 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Nov 21 09:25:51 2014 New Revision: 217909 URL: https://gcc.gnu.org/viewcvs?rev=217909root=gccview=rev Log: PR target/63764 c-family/ * c-common.h (convert_vector_to_pointer_for_subscript): Change return type to bool. * c-common.c: Include gimple-expr.c. (convert_vector_to_pointer_for_subscript): Change return type to bool. If *vecp is not lvalue_p and has VECTOR_TYPE, return true and copy it into a TARGET_EXPR and use that instead of *vecp directly. c/ * c-typeck.c (build_array_ref): Adjust convert_vector_to_pointer_for_subscript caller. If it returns true, call non_lvalue_loc on the result. cp/ * typeck.c (cp_build_array_ref): Adjust convert_vector_to_pointer_for_subscript caller. If it returns true, call non_lvalue_loc on the result. testsuite/ * c-c++-common/pr63764-1.c: New test. * c-c++-common/pr63764-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr63764-1.c trunk/gcc/testsuite/c-c++-common/pr63764-2.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/61773] [5 Regression] ICE in tree-ssa-strlen.c:417
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61773 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Nov 21 09:27:19 2014 New Revision: 217910 URL: https://gcc.gnu.org/viewcvs?rev=217910root=gccview=rev Log: PR tree-optimization/61773 * tree-ssa-strlen.c (get_string_length): Don't assert stpcpy has been prototyped if si-stmt is BUILT_IN_MALLOC. * gcc.dg/pr61773.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61773.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug target/63910] [5 Regression] ICE: simplify_immed_subreg, at simplify-rtx.c:5519 with -mstringop-strategy=vector_loop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63910 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63764 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug bootstrap/63787] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63787 Bug 63787 depends on bug 61773, which changed state. Bug 61773 Summary: [5 Regression] ICE in tree-ssa-strlen.c:417 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61773 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/63989] tree-ssa-strlen.c doesn't handle constant pointer plus and array refs if constant offset is smaller than known constant string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63989 Bug 63989 depends on bug 61773, which changed state. Bug 61773 Summary: [5 Regression] ICE in tree-ssa-strlen.c:417 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61773 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/61773] [5 Regression] ICE in tree-ssa-strlen.c:417
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61773 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.4, 4.9.2 Target Milestone|--- |5.0 Known to fail||5.0
[Bug target/64015] New: [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 Bug ID: 64015 Summary: [5.0 Regression] AArch64 ICE due to conditional compare Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: zhenqiang.chen at arm dot com Target: aarch64* Created attachment 34065 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34065action=edit Reduced testcase Attached testcase ICEs with: ice.c: In function 'test': ice.c:4:1: error: unrecognizable insn: } ^ (insn 8 7 9 2 (set (reg:CC_DGTU 66 cc) (compare:CC_DGTU (and:SI (ne:SI (reg:CC_DGTU 66 cc) (const_int 0 [0])) (gtu:SI (reg/v:SI 79 [ b ]) (const_int 252 [0xfc]))) (const_int 0 [0]))) ice.c:3 -1 (nil)) I've tracked it down to the aarch64 conditional compare patches. r217638 works whereas r217646 has the ICE. -O2 should be enough to reproduce. Zhenqiang, can you take a look please?
[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #6 from Konstantinos Margaritis markos at freevec dot org --- Hi Bill, Thanks for the fix in the double * patch. It's listed as a valid option in: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html vector double vec_vsx_ld (int, const double *); Similarly for vec_vsx_st: void vec_vsx_st (vector double, int, double *); Also, thanks for the clarifications for the lxvw4x.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Ok, so I have a patch that works until we get to try constant folding a vector load from an array of elements. There both native_encode_expr and fold_ctor_reference fail (the first because it doesn't handle CONSTRUCTORs yet the latter because it doesn't handle multi-field/index results). The idea was to get CONSTRUCTOR support into native_encode_expr which would then handle the fully-constant cases (but not initializers with constant addresses like global-var). Of course it wouldn't help as FRE isn't run late. Hah.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #11 from Tejas Belagod belagod at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #8) (In reply to Tejas Belagod from comment #7) I tried this, but it still doesn't seem to fold for aarch64. So, here is the DOM trace for aarch64: Optimizing statement a = *.LC0; Why do we get LC0 in the first place? It seems like it is happening because of some cost model issue with MOVECOST. Can the cost model affect something as early as gimple?
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #12 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 21 Nov 2014, belagod at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #11 from Tejas Belagod belagod at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #8) (In reply to Tejas Belagod from comment #7) I tried this, but it still doesn't seem to fold for aarch64. So, here is the DOM trace for aarch64: Optimizing statement a = *.LC0; Why do we get LC0 in the first place? It seems like it is happening because of some cost model issue with MOVECOST. Can the cost model affect something as early as gimple? Through CLEAR_RATIO and can_move_by_pieces (and for complex stuff initializer_constant_valid_p). I think it's mostly can_move_by_pieces here.
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Good. What about the snippet in Comment #4, though? That one seems Ok to me and meaning that cxx_eval_bit_field_ref needs some work.
[Bug middle-end/64006] __builtin_mul_overflow fails to signal overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64006
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-11-21
CC||jakub at gcc dot gnu.org
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
int v;
long __attribute__ ((noinline))
test (long *x, int y)
{
int i;
long s = 1;
for (i = 0; i y; i++)
if (__builtin_mul_overflow (s, x[i], s))
v++;
return s;
}
int
main ()
{
long d[7] = { 975, 975, 975, 975, 975, 975, 975 };
long r = test (d, 7);
if (sizeof (long) * __CHAR_BIT__ == 64 v != 1)
__builtin_abort ();
else if (sizeof (long) * __CHAR_BIT__ == 32 v != 4)
__builtin_abort ();
return 0;
}
The problem is in VRP, the IMAGPART_EXPR of the MUL_OVERFLOW result is
processed with only some edges executable and others not, so the value ranges
of the values are only temporary, not final. In that case, one of the
arguments of
MUL_OVERFLOW is assumed to be [1, 1] and the other argument is VARYING.
A final [1, 1] * VARYING in the same types is never overflowing though, the
result always fits into the type, so we set [0, 0] as the value range for the
IMAGPART_EXPR. And for some reason we are not called again when the
MUL_OVERFLOW arguments are VARYING * VARYING.
So, is there some way how to tell VRP to simulate the IMAGPART_EXPR again? Or
is there a way to see if the value ranges of the *_OVERFLOW arguments are just
temporary simulation or final? Is the fact that IMAGPART_EXPR range might be
narrower initially and change to larger one later on compatible with VRP at
all?
Though, how is that generally different from say simulating s = s + 4 inside a
loop? There we initially assume (if s is 1 before the loop) range [5, 5] and
later turn it into a wider range. Though, for the IMAGPART_EXPR in this case,
the arguments of the MUL_OVERFLOW don't depend on the IMAGPART_EXPR value.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #13 from Tejas Belagod belagod at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #12) On Fri, 21 Nov 2014, belagod at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #11 from Tejas Belagod belagod at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #8) (In reply to Tejas Belagod from comment #7) I tried this, but it still doesn't seem to fold for aarch64. So, here is the DOM trace for aarch64: Optimizing statement a = *.LC0; Why do we get LC0 in the first place? It seems like it is happening because of some cost model issue with MOVECOST. Can the cost model affect something as early as gimple? Through CLEAR_RATIO and can_move_by_pieces (and for complex stuff initializer_constant_valid_p). I think it's mostly can_move_by_pieces here. Ah, jgreenhalgh just did some move_by_pieces restructuring recently.
[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968 --- Comment #5 from Martin Liška mliska at suse dot cz --- On 11/20/2014 11:43 PM, hubicka at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- /* If we wanted to, we could actually do a real increase by redeleting and inserting. However, this would require O (log n) time. So just bail out for now. */ if (fibheap_comp_data (heap, key, data, node) 0) return NULL; It is clearly bug in the old implementation. Increase is quite easy to handle: you just remember the increased value and if your find_min returns one where value has increased, just re-insert it and get another minimum. This requires to store two keys, that is probably not good for generic template. Perhaps bb-reorder can just see if it is increasing and perform delete+insert. Its loop is not perofrmance critical (inliner did so and it was too slow in that case) Hi. My suggested patch adds support for increase operation, where I delete and insert new key. As such usage is quite rare, I hope suggested approach fits? One can choose between: 'replace_key' and 'decrease', where the second one contains assert that new key is really smaller. Thanks, Martin
[Bug target/60451] X86 vectorization improve: pack instead of pshufb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60451 --- Comment #2 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Fri Nov 21 11:13:37 2014 New Revision: 217913 URL: https://gcc.gnu.org/viewcvs?rev=217913root=gccview=rev Log: gcc/testsuite PR target/60451 * gcc.target/i386/pr60451.c: New. gcc/ PR target/60451 * config/i386/i386.c (expand_vec_perm_even_odd_pack): New. (expand_vec_perm_even_odd_1): Add new expand for V8HI mode, replace for V16QI, V16HI and V32QI modes. (ix86_expand_vec_perm_const_1): Add new expand. Added: trunk/gcc/testsuite/gcc.target/i386/pr60451.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/64016] New: ICE with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64016 Bug ID: 64016 Summary: ICE with -O2 -fsanitize=undefined Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net 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 Created attachment 34066 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34066action=edit reduced testcase Under Debian and the attached testcase: $ gcc-snapshot -O2 -fsanitize=undefined -c gcc-ice.c gcc: internal compiler error: Segmentation fault (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. with gcc (Debian 20141118-1) 5.0.0 20141118 (experimental) [trunk revision 217719] This was found when compiling GNU MPFR (tests/tget_f.c).
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #14 from jgreenhalgh at gcc dot gnu.org --- Yes, we turn move_by_pieces off for AArch64 so we can use our own expander for block moves. This has a number of negative side-effects where optimizers decide that if you're not using move_by_pieces, block moves must be expensive - this is bogus! (see Joern's email on the thread hookizing BY_PIECES_P https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00197.html ).
[Bug ipa/63569] [5.0 Regression] Wrong code with volatile and ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63569 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška marxin at gcc dot gnu.org --- Hello. There's suggested patch on mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01723.html. Reason why it hasn't been applied is that Richard prefers kind of refactoring for IPA ICF that will cover this case in purer way. Nevertheless, feel free to apply suggested patch if it fixes your issue? Thanks, Martin
[Bug ipa/63569] [5.0 Regression] Wrong code with volatile and ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63569 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Martin Liška from comment #4) There's suggested patch on mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01723.html. Reason why it hasn't been applied is that Richard prefers kind of refactoring for IPA ICF that will cover this case in purer way. Sorry, I just didn't notice the URL in the headers. Your patch fixes the issue for me. Is there any way to make progress on this issue? Could you address Richi's concerns?
[Bug target/63901] msp430 multilib must distinguish mhwmult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901 --- Comment #4 from Nick Clifton nickc at redhat dot com --- Hi Peter, In mspgcc, TI provided a CSV file that listed every device along with all its characteristics. This is still present in the GCC header bundle TI provides. This in turn was processed to produce a specs fragment that provided rules to default all the -m* flags from a specific -mmcu= value. Could the tool that converted the CSV file into a spec fragment be altered so that it produces the relevent -mhwmult= option based upon an MCU input ? Ie would it be possible to provide the users with a tool that takes an MCU name, reads in the CSV file and outputs the correct -mhwmult option ? Somthing like: msp430-elf-gcc `gen-hwmult-opt -mmcu=foo` If the tool was stand-alone then it would not need to be updated when the CSV file changes, and it could work with any CSV file, old or new. Cheers Nick PS. I have applied the patch to the newlib sources so that at least that part of the problem is resolved for now.
[Bug sanitizer/64016] ICE with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64016 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think this one should be fixed by my r217766.
[Bug libstdc++/43622] no C++ typeinfo for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #26 from John Maddock john at johnmaddock dot co.uk --- (In reply to jos...@codesourcery.com from comment #25) On Thu, 20 Nov 2014, john at johnmaddock dot co.uk wrote: While we're opening cans of worms intmax_t should clearly be __int128... just saying! Existing ABIs where intmax_t in libc is 64-bit are why __int128 is what I call a sui generis extended type, not an integer type. So it's an integer that's not an integer? I'm sorry but that's just nonesense. Of course I realise that ABI issues may trump other concerns, but please call a spade a spade! In any case this is a glibc issue and we're off topic here...
[Bug tree-optimization/64006] __builtin_mul_overflow fails to signal overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64006 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|middle-end |tree-optimization
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 matthew.hambley at metoffice dot gov.uk changed: What|Removed |Added CC||matthew.hambley at metoffice dot g ||ov.uk --- Comment #2 from matthew.hambley at metoffice dot gov.uk --- Created attachment 34067 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34067action=edit Minimal test case for the issue under v4.9.2. I just stumbled across this in v4.9.2. Attached is a minimal test case.
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 --- Comment #3 from matthew.hambley at metoffice dot gov.uk --- (In reply to matthew.hambley from comment #2) Created attachment 34067 [details] Minimal test case for the issue under v4.9.2. I just stumbled across this in v4.9.2. Attached is a minimal test case. And I should have included the compiler output: $ gfortran -Wall -Wextra stringalloc.f90 stringalloc.f90: In function ‘test’: stringalloc.f90:20:0: internal compiler error: in gimplify_expr, at gimplify.c:8538 allocate( character( len=len_trim( thing ) ) :: local%thing ) ^ 0x80569e gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc-4.9.2/gcc/gimplify.c:8538 0x802929 gimplify_modify_expr ../../gcc-4.9.2/gcc/gimplify.c:4510 0x804b67 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc-4.9.2/gcc/gimplify.c:7627 0x806586 gimplify_stmt(tree_node**, gimple_statement_base**) ../../gcc-4.9.2/gcc/gimplify.c:5373 0x805033 gimplify_statement_list ../../gcc-4.9.2/gcc/gimplify.c:1432 0x805033 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc-4.9.2/gcc/gimplify.c:8042 0x806586 gimplify_stmt(tree_node**, gimple_statement_base**) ../../gcc-4.9.2/gcc/gimplify.c:5373 0x806e1b gimplify_bind_expr ../../gcc-4.9.2/gcc/gimplify.c:1099 0x80438e gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc-4.9.2/gcc/gimplify.c:7824 0x806586 gimplify_stmt(tree_node**, gimple_statement_base**) ../../gcc-4.9.2/gcc/gimplify.c:5373 0x805033 gimplify_statement_list ../../gcc-4.9.2/gcc/gimplify.c:1432 0x805033 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc-4.9.2/gcc/gimplify.c:8042 0x806586 gimplify_stmt(tree_node**, gimple_statement_base**) ../../gcc-4.9.2/gcc/gimplify.c:5373 0x80408a gimplify_and_add ../../gcc-4.9.2/gcc/gimplify.c:385 0x80408a gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc-4.9.2/gcc/gimplify.c:7964 0x806586 gimplify_stmt(tree_node**, gimple_statement_base**) ../../gcc-4.9.2/gcc/gimplify.c:5373 0x806e1b gimplify_bind_expr ../../gcc-4.9.2/gcc/gimplify.c:1099 0x80438e gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc-4.9.2/gcc/gimplify.c:7824 0x806586 gimplify_stmt(tree_node**, gimple_statement_base**) ../../gcc-4.9.2/gcc/gimplify.c:5373 0x80743a gimplify_body(tree_node*, bool) ../../gcc-4.9.2/gcc/gimplify.c:8734 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 middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Please report to linaro.
[Bug target/64014] [5 regression] Failure of gcc.dg/torture/stackalign/regparm-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64014 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, that works without any warnings with delayed-folding patch. (I mentioned it in comment #6 as *valid-code* sample)
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 --- Comment #20 from Martin Liška marxin at gcc dot gnu.org --- Hello. I've just bootstrapped on ggc110 after r217307 was applied. Can you please verify if the problem still persists? Thanks, Martin
[Bug ipa/63569] [5.0 Regression] Wrong code with volatile and ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63569 --- Comment #6 from Martin Liška marxin at gcc dot gnu.org --- Problem is that IPA ICF contains compare_operand that is called recursively and handles all tree types. Richard correctly pointed that we should split the method to memory-related operand comparison and the rest (declarations,..). I hope I can send the path on Monday-Tuesday next week. Thanks, Martin
[Bug ipa/63598] [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598 --- Comment #4 from Martin Liška marxin at gcc dot gnu.org --- Can you please check if the issue still persists? I would appreciate further information related to PR, or do we have any GCC fam machine I can debug it? Thanks, Martin
[Bug ipa/63856] [5 Regression] ICE: verify_gimple failed: invalid argument to gimple call with -O2 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856
--- Comment #2 from Martin Liška marxin at gcc dot gnu.org ---
I cannot reproduce the bug:
../configure --prefix=/home/marxin/Programming/bin/gcc3 --disable-multilib
--enable-languages=c,c++ --disable-bootstrap
./xgcc -B ./ -O2 -fPIC ~/Programming/testcases/PR63856/testcase.c
-fdump-ipa-icf-details
uname -a
Linux marxinbox.suse.cz 3.16.6-2-desktop #1 SMP PREEMPT Mon Oct 20 13:47:22 UTC
2014 (feb42ea) x86_64 x86_64 x86_64 GNU/Linux
gcc version 5.0.0 20141121 (experimental) (GCC)
ipa-icf-details log:
Equal symbols: 1
Fraction of visited symbols: 33.33%
debug message: All BBs are equal
(equals_private:487)
Equals called for:g:f (1:0) (g:f) with result: true
Semantic equality hit:g-f
Assembler symbol names:g-f
g (v2si A, int N)
{
vector(4) short int D.1840;
bb 2:
_2 = VIEW_CONVERT_EXPRvector(4) short int(A_1(D));
D.1840 = _2;
_6 = (long unsigned int) N_5(D);
_7 = _6 * 2;
_8 = D.1840 + _7;
_9 = *_8;
_10 = (int) _9;
return _10;
}
f (v2si A, int N)
{
vector(4) short int D.1835;
bb 2:
_2 = VIEW_CONVERT_EXPRvector(4) short int(A_1(D));
D.1835 = _2;
_6 = (long unsigned int) N_5(D);
_7 = _6 * 2;
_8 = D.1835 + _7;
_9 = *_8;
_10 = (int) _9;
return _10;
}
Thanks,
Martin
[Bug tree-optimization/64006] __builtin_mul_overflow fails to signal overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64006 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34068 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34068action=edit gcc5-pr64006.patch Untested fix.
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #6 from Mark Wielaard mark at gcc dot gnu.org --- It looks like for some reason Darwin defaults to some ancient (v2) strict version of DWARF. Please try adding -gno-strict-dwarf -gdwarf-4 to gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C dg-options.
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Mark Wielaard from comment #6) It looks like for some reason Darwin defaults to some ancient (v2) strict version of DWARF. Please try adding -gno-strict-dwarf -gdwarf-4 to gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C dg-options. The reason for that is that Darwin has a set of tools that crash or otherwise break on valid DWARF 3 or DWARF 4 or various extensions. So using -gdwarf-2 and -gstrict-dwarf by default is necessary because of badly written toolchain.
[Bug c++/63942] [5.0 Regression] constexpr conflicts with previous declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63942 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- (In reply to David Edelsohn from comment #6) It still occurred as of [trunk revision 217822] I'm still not seeing it in a cross-compiler. Does the error depend on particular flags?
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #8 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) So using -gdwarf-2 and -gstrict-dwarf by default is necessary because of badly written toolchain. I had tried -gdwarf-4, but didn't know about -gstrict-dwarf. Will commit the obvious patch, then.
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #9 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Fri Nov 21 13:27:57 2014 New Revision: 217918 URL: https://gcc.gnu.org/viewcvs?rev=217918root=gccview=rev Log: PR debug/63239 * g++.dg/debug/dwarf2/deleted-member-function.C: Pass -gno-strict-dwarf on darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C
[Bug testsuite/61137] [5 regression] FAIL: gcc.target/ia64/small-addr-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61137 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Nov 21 13:28:58 2014 New Revision: 217919 URL: https://gcc.gnu.org/viewcvs?rev=217919root=gccview=rev Log: PR target/61137 * config/ia64/ia64.c (ia64_attribute_takes_identifier_p): New function. (TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P): Redefine to it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- You should pass -gno-strict-dwarf unconditionally, I think vxworks has similar defaults as darwin.
[Bug c/50459] alignof doesn't work on plain old constant, works with expressions containing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459 Bug 50459 depends on bug 61137, which changed state. Bug 61137 Summary: [5 regression] FAIL: gcc.target/ia64/small-addr-1.c (test for excess errors) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61137 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug testsuite/61137] [5 regression] FAIL: gcc.target/ia64/small-addr-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61137 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Hopefully fixed.
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Fri Nov 21 13:32:08 2014 New Revision: 217920 URL: https://gcc.gnu.org/viewcvs?rev=217920root=gccview=rev Log: PR debug/63239 * g++.dg/debug/dwarf2/deleted-member-function.C: Pass -gno-strict-dwarf. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) You should pass -gno-strict-dwarf unconditionally, I think vxworks has similar defaults as darwin. OK, it's true it cannot hurt as we're not calling the assembler anyway.
[Bug debug/63243] [meta-bug] RH GDB project tracker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243 Bug 63243 depends on bug 63239, which changed state. Bug 63239 Summary: DWARF does not represent C++ deleted methods https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug target/64014] [5 regression] Failure of gcc.dg/torture/stackalign/regparm-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64014 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Dup of PR63977 ?
[Bug middle-end/64017] New: Support ISL 0.14.0 (to fix ICE with gfortran.dg/graphite/pr42393.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64017 Bug ID: 64017 Summary: Support ISL 0.14.0 (to fix ICE with gfortran.dg/graphite/pr42393.f90) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: grosser at gcc dot gnu.org, romangareev at gcc dot gnu.org Depends on: 62289 GCC 5 should (optionally) support ISL 0.14.0; currently, only 0.12.2 is supported. For compatibility with GCC 4.8/4.9, supporting ISL 0.12.x would be nice. ISL 0.14.0 is required to fix the ICE with gfortran.dg/graphite/pr42393.f90 (see PR62289). Cf. https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00906.html BTW: Currently, there is no version check for ISL in GCC's configure script. BTW2: There are in gcc/graphite* still references to CLooG in the comments, which are obsolete.
[Bug target/63977] [5 Regression] r217769 caused many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63977 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- *** Bug 64014 has been marked as a duplicate of this bug. ***
[Bug target/64014] [5 regression] Failure of gcc.dg/torture/stackalign/regparm-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64014 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) Dup of PR63977 ? Looks like it, indeed. Don't know why I didn't find it, sometimes bugzilla search seems a bit conservative in the results it shows. Next time I run a fresh bootstrap, I'll see if it's still there and reopen it if needed. Thanks! *** This bug has been marked as a duplicate of bug 63977 ***
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Ah, excellent.
[Bug sanitizer/64013] [5 Regression] libsanitizer fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-21 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Kostya/Dmitri, can you please fix this upstream, so that we can cherry-pick it? The fix is obvious...
[Bug target/63901] msp430 multilib must distinguish mhwmult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901 --- Comment #5 from Peter A. Bigot pab at pabigot dot com --- Yes, that could work. msp430mcu in mspgcc days did a lot more than specs fragments; if interested see the relevant material (BSD-3-Clause) is in the msp430mcu repository at: https://sourceforge.net/p/mspgcc/msp430mcu/ci/master/tree/ I still prefer the specs approach because it's nicer for the users. But I'm coming to accept the alternative you suggest. So yes: remove -mmcu interpretation from gcc and require people to provide all the relevant specifications explicitly (defaulting to -mcpu=430 and -mhwmult=none). Implement a proper multilib demux based on both -mcpu and -mhwmult, rather than making all libc users take on the overhead of software multiply routines. (Ick.) Providing a tool that identifies the right -m* options for a specific MCU is TI's responsibility. They already do part of the job by providing the device-specific headers and linker scripts (maybe someday as versioned releases). Adding an msp430-elf-mcu-options script should be less than a day's effort for them.
[Bug target/63975] some of the builtin-arith-overflow* fail on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63975 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- All these tests involve __int128 arithmetics, might be as well a backend bug in handling those.
[Bug sanitizer/64013] [5 Regression] libsanitizer fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #3 from Dmitry Vyukov dvyukov at google dot com --- Fixed upstream: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=222532r2=222531pathrev=222532
[Bug sanitizer/64013] [5 Regression] libsanitizer fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64013 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Nov 21 14:03:37 2014 New Revision: 217921 URL: https://gcc.gnu.org/viewcvs?rev=217921root=gccview=rev Log: PR sanitizer/64013 * sanitizer_common/sanitizer_linux.cc (FileExists): Cherry pick upstream r222532. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc
[Bug middle-end/63633] [avr] internal compiler error: unrecognizable insn with mult insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Nov 21 14:04:25 2014 New Revision: 217922 URL: https://gcc.gnu.org/viewcvs?rev=217922root=gccview=rev Log: gcc/ Forward-port from 2014-10-30 4_9-branch r216934 PR target/63633 * config/avr/avr-protos.h (regmask): New inline function. (avr_fix_inputs, avr_emit3_fix_outputs): New protos. * config/avr/avr.c (avr_fix_operands, avr_move_fixed_operands) (avr_fix_inputs, avr_emit3_fix_outputs): New functions. * config/avr/avr-fixed.md (mulqq3_nomul, muluqq3_nomul) (mulALL2QA3, mulALL4A3, usdivALL1Q3, usdivALL2QA3) (usdivALL4A3, roundALL124QA3): Fix input operands. * config/avr/avr-dimode.md (addALL83, subALL83) (ss_addsubALL8S3, us_addsubALL8U3, cbranchALL84) (di_shiftsALL83, any_extendmulsidi3): Fix input operands. * config/avr/avr.md (mulqi3_call, mulhi3_call, mulsi3, mulpsi3) (muluQIHIsi3, mulsQIHIsi3, mulohisi3, any_extendmulhisi3) (usmulhisi3, any_extendmulhi3_highpart, mulsqipsi3) (fmul, fmuls, fmulsu): Fix operands. Turn insn into expander as needed. gcc/testsuite/ Forward-port from 2014-10-30 4_9-branch r216934 PR target/63633 * gcc.target/avr/torture/pr63633-ice-mult.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/pr63633-ice-mult.c Modified: trunk/gcc/config/avr/avr-dimode.md trunk/gcc/config/avr/avr-fixed.md trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug target/63633] [avr] internal compiler error: unrecognizable insn with mult insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Component|middle-end |target Known to work||4.9.3, 5.0 Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Target Milestone|--- |4.9.3 Known to fail|5.0 | --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed in 4.9.3+
[Bug c++/63942] [5.0 Regression] constexpr conflicts with previous declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63942 --- Comment #8 from David Edelsohn dje at gcc dot gnu.org --- The testsuite invokes compiles overloaded.cc with the following command line on AIX: /tmp/20141120/./gcc/xg++ -shared-libgcc -B/tmp/20141120/./gcc -nostdinc++ -L/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src -L/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs -L/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++/.libs -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/powerpc-ibm-aix7.1.0.0/bin/ -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/powerpc-ibm-aix7.1.0.0/lib/ -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/po werpc-ibm-aix7.1.0.0/include -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/powerpc-ibm-aix7.1.0.0/sys-include -B/tmp/20141120/powerpc-ibm-aix7.1.0.0/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR=. -nostdinc++ -I/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0 -I/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include -I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++ -I/nasfarm/edelsohn/src/src/libstdc++-v3/include/backward -I/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/util /nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/tuple/comparison_operators/overloaded.cc -std=gnu++11 -S -o overloaded.s and tuple_cat.cc command line is: /tmp/20141120/./gcc/xg++ -shared-libgcc -B/tmp/20141120/./gcc -nostdinc++ -L/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src -L/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs -L/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/libsupc++/.libs -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/powerpc-ibm-aix7.1.0.0/bin/ -B/gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/powerpc-ibm-aix7.1.0.0/lib/ -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/powerpc-ibm-aix7.1.0.0/include -isystem /gsa/yktgsa/home/e/d/edelsohn/install/powerpc-ibm-aix7.1.0.0-20141120/powerpc-ibm-aix7.1.0.0/sys-include -B/tmp/20141120/powerpc-ibm-aix7.1.0.0/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR=. -nostdinc++ -I/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0 -I/tmp/20141120/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include -I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++ -I/nasfarm/edelsohn/src/src/libstdc++-v3/include/backward -I/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/util /nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/tuple/creation_functions/tuple_cat.cc -std=gnu++11 ./libtestc++.a /gsa/yktgsa/home/e/d/edelsohn/install/lib/libiconv.a -lm -o ./tuple_cat.exe I see -nostdinc++ -std=gnu++11 -g -O2
[Bug ipa/63598] [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598 --- Comment #5 from dave.anglin at bell dot net --- On 11/21/2014 7:52 AM, marxin at gcc dot gnu.org wrote: Can you please check if the issue still persists? I will check. All my recent builds are with flag_ipa_icf_functions = 0. I would appreciate further information related to PR, or do we have any GCC fam machine I can debug it? There is no farm machine for hppa-hpux. We have a machine for hppa-linux. However, this bug seems hpux specific. Dave
[Bug tree-optimization/63551] [4.9/5 Regression] wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #3) indeed, somewhere we need to view convert the aggregate value... Predicates works on conditions on arguments, so I suppose this ought to happen at ipa-prop side. Martin? I disagree, ipa-prop jump functions describe what values callers pass to callees, it is the conditions of the predicates that need do describe what then happens to these values, including any conversions. Anyway, I am bootstrapping the following fix: Index: src/gcc/ipa-inline-analysis.c === --- src.orig/gcc/ipa-inline-analysis.c +++ src/gcc/ipa-inline-analysis.c @@ -880,6 +880,7 @@ evaluate_conditions_for_known_args (stru } if (c-code == IS_NOT_CONSTANT || c-code == CHANGED) continue; + val = fold_convert (TREE_TYPE (c-val), val); res = fold_binary_to_constant (c-code, boolean_type_node, val, c-val); if (res integer_zerop (res)) continue;
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #17 from boger at us dot ibm.com --- Can you clarify how using -a -tags netgo actually works. I know it requires that the source be available, but it must mean that it rebuilds the package for the current link only, throws it away after using it and next time it has to rebuild it? Couldn't some of your concerns about unexpected failures be resolved by providing better error information when there were failures, or provide other ways to indicate that the go resolver shouldn't be called (like an environment variable)? It just seems that rebuilding the package every time is a heavy hammer to resolve this problem. I think if someone wants to have their GO program use libnss if it is present and then the go resolver if not, that should be an option and currently it is not.
[Bug rtl-optimization/63952] [5 Regression] bootstrap failure (ICE in prepare_cmp_insn) on s390x in libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63952 --- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org --- Author: uweigand Date: Fri Nov 21 15:33:27 2014 New Revision: 217929 URL: https://gcc.gnu.org/viewcvs?rev=217929root=gccview=rev Log: PR rtl-optimization/63952 * optabs.c (prepare_cmp_insn): Do not call can_compare_p for CCmode. * config/s390/s390.md (cbranchcc4): Accept any s390_comparison. Remove incorrect TARGET_HARD_FLOAT check and no-op expander code. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.md trunk/gcc/optabs.c
[Bug rtl-optimization/63952] [5 Regression] bootstrap failure (ICE in prepare_cmp_insn) on s390x in libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63952 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Ulrich Weigand uweigand at gcc dot gnu.org --- Fixed.
[Bug c++/63942] [5.0 Regression] constexpr conflicts with previous declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63942 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org --- (In reply to David Edelsohn from comment #8) I see -nostdinc++ -std=gnu++11 -g -O2 Ah, it seems to be triggered by -g.
[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Fri Nov 21 15:38:15 2014 New Revision: 217930 URL: https://gcc.gnu.org/viewcvs?rev=217930root=gccview=rev Log: 2014-11-21 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63673 * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Allow the base pointer of vec_vsx_ld and vec_vsx_st to take a pointer to double. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-c.c
[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #8 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Fri Nov 21 15:39:20 2014 New Revision: 217931 URL: https://gcc.gnu.org/viewcvs?rev=217931root=gccview=rev Log: 2014-11-21 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/63673 * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Allow the base pointer of vec_vsx_ld and vec_vsx_st to take a pointer to double. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/rs6000-c.c
[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Bill Schmidt wschmidt at gcc dot gnu.org --- This has also been fixed in trunk. A typo in my log message prevented the automatic post to this bugzilla. All work complete.
[Bug jit/64018] New: JIT tutorial does not describe error-handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64018 Bug ID: 64018 Summary: JIT tutorial does not describe error-handling Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Right now, the tutorials don't describe error-handling, just the topic reference. Error-handling should be discussed in the first tutorial that walks through the code in detail, which is docs/intro/tutorial02.rst.
[Bug debug/38757] gcc does not emit DW_LANG_C99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38757
--- Comment #7 from Mark Wielaard mark at gcc dot gnu.org ---
Author: mark
Date: Fri Nov 21 16:00:06 2014
New Revision: 217934
URL: https://gcc.gnu.org/viewcvs?rev=217934root=gccview=rev
Log:
PR debug/38757 gcc does not emit DW_LANG_C99.
For C and C++ add the language standard version in use to lang_hooks.name.
Change users of lang_hook.name to check with new functions lang_GNU_C or
lang_GNU_CXX. In dwarf2out.c output the DW_LANG_C version from the
lang_hooks.name and merge any LTO TRANSLATION_UNIT_LANGUAGE found. Adds
two testcases to dwarf2.exp to check the right DWARF DW_AT_language is set
on the compile_unit depending on the -std=c89 or -std=c99 setting.
gcc/c-family/ChangeLog
PR debug/38757
* c-opts.c (set_std_c89): Set lang_hooks.name.
(set_std_c99): Likewise.
(set_std_c11): Likewise.
(set_std_cxx98): Likewise.
(set_std_cxx11): Likewise.
(set_std_cxx14): Likewise.
(set_std_cxx1z): Likewise.
gcc/ChangeLog
PR debug/38757
* config/avr/avr-c.c (avr_cpu_cpp_builtins): Use lang_GNU_C.
* config/darwin.c (darwin_file_end): Use lang_GNU_CXX.
(darwin_override_options): Likewise.
* config/ia64/ia64.c (ia64_struct_retval_addr_is_first_parm_p):
Likewise.
* config/rs6000/rs6000.c (rs6000_output_function_epilogue):
Likewise.
* dbxout.c (get_lang_number): Likewise.
(dbxout_type): Likewise.
(dbxout_symbol_location): Likewise.
* dwarf2out.c (add_prototyped_attribute): Add DW_AT_prototype
also for DW_LANG_{C,C99,ObjC}.
(highest_c_language): New function.
(gen_compile_unit_die): Call highest_c_language to merge LTO
TRANSLATION_UNIT_LANGUAGE. Use strncmp language_string to
determine if DW_LANG_C99 or DW_LANG_C89 should be returned.
* fold-const.c (fold_cond_expr_with_comparison): Use lang_GNU_CXX.
* langhooks.h (struct lang_hooks): Add version comment to name.
(lang_GNU_C): New function declaration.
(lang_GNU_CXX): Likewise.
* langhooks.c (lang_GNU_C): New function.
(lang_GNU_CXX): Likewise.
* vmsdbgout.c (vmsdbgout_init): Use lang_GNU_C and lang_GNU_CXX.
gcc/testsuite/ChangeLog
PR debug/38757
* gcc.dg/debug/dwarf2/lang-c89.c: New test.
* gcc.dg/debug/dwarf2/lang-c99.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/lang-c89.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/lang-c99.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/config/avr/avr-c.c
trunk/gcc/config/darwin.c
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/dbxout.c
trunk/gcc/dwarf2out.c
trunk/gcc/fold-const.c
trunk/gcc/langhooks.c
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vmsdbgout.c
[Bug jit/63969] gccjit segfaults when it can't locate the correct gcc driver program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63969 --- Comment #6 from dmalcolm at gcc dot gnu.org --- (In reply to dmalcolm from comment #4) Patch posted for review as https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02617.html TMM confirmed on IRC that the proposed patch fixes the issue for them.
[Bug c++/63942] [5.0 Regression] constexpr conflicts with previous declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63942
--- Comment #10 from Jason Merrill jason at gcc dot gnu.org ---
Reduced:
template class T
struct A
{
A(const T) {}
A(const A) {}
};
template class Adecltype(nullptr);
[Bug bootstrap/63784] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63784 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
