[Bug libstdc++/64147] New: vector resize() fails for non-copyable type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64147
Bug ID: 64147
Summary: vector resize() fails for non-copyable type
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ebf at users dot sourceforge.net
Compiling the below program with -std=c++11 fails, error: call to deleted
constructor of 'Foo'.
This seems incorrect since C++11 explicitly added a new single argument vector
resize method that is supposed to default-construct elements rather than copy
them.
---
#include vector
class Foo {
public:
Foo() {}
Foo(const Foo) = delete;
};
int main() {
std::vectorFoo vec;
vec.resize(42); // error: call to deleted constructor of 'Foo'
}
---
By contrast, the following program using the vector size constructor works ok:
---
#include vector
class Foo {
public:
Foo() {}
Foo(const Foo) = delete;
};
int main() {
std::vectorFoo vec(42); // compiles fine
}
[Bug fortran/64137] Fortran FE builds invalid GENERIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64137 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Dec 2 08:50:57 2014 New Revision: 218259 URL: https://gcc.gnu.org/viewcvs?rev=218259root=gccview=rev Log: 2014-12-02 Richard Biener rguent...@suse.de PR fortran/64137 * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Check proper expressions type, use proper type for computing -Huge - 1. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c
[Bug fortran/64137] Fortran FE builds invalid GENERIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64137 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/64126] [5.0 Regression] FAIL: gcc.dg/pr37289.c scan-tree-dump original -\\(long unsigned int\\) x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64126 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/64111] [5.0 regression] ICE: conversion of register to a different size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org --- Fixed everywhere.
[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042
--- Comment #5 from vries at gcc dot gnu.org ---
An easy way to reproduce, is to add this patch:
...
diff -u
/home/vries/gcc_versions/data/ref-master-14-12-02/src/boehm-gc/testsuite/boehm-gc.c/c.exp
./c.exp
---
/home/vries/gcc_versions/data/ref-master-14-12-02/src/boehm-gc/testsuite/boehm-gc.c/c.exp
2014-12-02 02:51:25.0 +0100
+++ ./c.exp2014-11-26 14:39:41.964962842 +0100
@@ -19,4 +19,8 @@
boehm-gc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] -O2
+for {set i 0} {$i 1000} {incr i} {
+boehm-gc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/gctest.c]]
-O2
+}
+
dg-finish
...
This way (1000 * compile/run) it triggered twice for me.
[Bug middle-end/64122] ICE: tree check: expected tree that contains 'decl common' structure, have 'ssa_name' in prepare_gimple_addressable, at gimplify.c:3228 with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64122 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-02 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 hongxu jia hongxu.jia at windriver dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from hongxu jia hongxu.jia at windriver dot com --- I have done the test, the defect has fixed //Hongxu
[Bug ipa/64146] [5 Regression] ipa-icf breaks gold dynamic_test_2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64146 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-02 CC||marxin at gcc dot gnu.org, ||trippels at gcc dot gnu.org Component|tree-optimization |ipa Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug target/63321] [SH] Unused T bit result of shll / shlr insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-12-02
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
Combine recently received some updates which improve handling of multiple-set
parallel insns. Applying the following:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md(revision 218250)
+++ gcc/config/sh/sh.md(working copy)
@@ -5156,6 +5156,12 @@
DONE;
}
+ if (operands[2] == const1_rtx)
+{
+ emit_insn (gen_shlr (operands[0], operands[1]));
+ DONE;
+}
+
/* If the lshrsi3_* insn is going to clobber the T_REG it must be
expanded here. */
if (CONST_INT_P (operands[2])
will always expand the multiple-set shlr insn and combine will be able to
utilize this. The test case
void test2_1 (unsigned int x, unsigned int* y)
{
y[0] = x 1;
y[1] = x 1;
}
will compile to the desired sequence:
shlrr4
movtr1
mov.l r4,@r5
rts
mov.l r1,@(4,r5)
However, in the context of e.g. pointer tagging use cases, the tag bits are
usually used with conditional branches:
void test2_2 (unsigned int x, unsigned int* y)
{
unsigned int xx = x 1;
unsigned int p = x 1;
if (p != 0)
foo (xx);
}
Combine can't handle this, because the shift and test insns end up in different
basic blocks. Moreover, in order to utilize the shlr insn, the branch
condition needs to be inverted. This could be done by emitting a movt-tst
sequence and let the sh_treg_combine pass optimize it away by inverting the
branch condition.
[Bug target/63321] [SH] Unused T bit result of shll / shlr insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #1)
void test2_1 (unsigned int x, unsigned int* y)
{
y[0] = x 1;
y[1] = x 1;
}
will compile to the desired sequence:
shlrr4
movtr1
mov.l r4,@r5
rts
mov.l r1,@(4,r5)
Changing the order of the operations to:
void test2_1 (unsigned int x, unsigned int* y)
{
y[0] = x 1;
y[1] = x 1;
}
will make it fail to combine the insns though.
[Bug target/63321] [SH] Unused T bit result of shll / shlr insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
A more advanced example:
void test4 (unsigned int x, unsigned int* y)
{
y[0] = (x 0) 1;
y[1] = (x 1) 1;
y[2] = x 2;
}
currently compiles to:
mov r4,r0
and #1,r0
mov.l r0,@r5
mov r4,r0
shlrr0
and #1,r0
shlr2 r4
mov.l r0,@(4,r5)
rts
mov.l r4,@(8,r5)
better:
shlr r4
movt r0
shlr r4
mov.lr0,@r5
movt r1
mov.lr4,@(8,r5)
rts
mov.lr1,@(4,r5)
[Bug target/63321] [SH] Unused T bit result of shll / shlr insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #1)
Combine recently received some updates which improve handling of
multiple-set parallel insns. Applying the following:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 218250)
+++ gcc/config/sh/sh.md (working copy)
@@ -5156,6 +5156,12 @@
DONE;
}
+ if (operands[2] == const1_rtx)
+{
+ emit_insn (gen_shlr (operands[0], operands[1]));
+ DONE;
+}
+
/* If the lshrsi3_* insn is going to clobber the T_REG it must be
expanded here. */
if (CONST_INT_P (operands[2])
will always expand the multiple-set shlr insn and combine will be able to
utilize this.
Doing that for the shlr insn is OK, since there is no other alternative to do a
1 bit right shift without touching the T bit. However, since there is a
non-T-bit-clobbering shll alternative (add x,x), doing the same for shll might
have negative side effects on other sequences.
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-02 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- -fno-ipa-icf fixes the issue.
[Bug target/63321] [SH] Unused T bit result of shll / shlr insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #3)
A more advanced example:
void test4 (unsigned int x, unsigned int* y)
{
y[0] = (x 0) 1;
y[1] = (x 1) 1;
y[2] = x 2;
}
Which is just another example of re-using intermediate results of stitched
shifts, only a bit more complex due to the multiple-set insns.
void test5 (unsigned int x, unsigned int* y)
{
y[0] = x (2);
y[1] = x (2 + 2);
y[2] = x (2 + 2 + 8);
}
currently compiles to:
mov r4,r1
shll2 r1
mov.l r1,@r5
mov r4,r1
shll2 r1
shll2 r1
mov.l r1,@(4,r5)
mov #12,r1
shldr1,r4
rts
mov.l r4,@(8,r5)
better:
shll2 r4
mov.l r4,@r5
shll2 r4
mov.l r4,@(4,r5)
shll8 r4
rts
mov.l r4,@(8,r5)
See also some examples in PR 54089.
[Bug target/64113] Gcc on Alpha: Error: No lda !gpdisp!282 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64113 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Tue Dec 2 10:04:14 2014 New Revision: 218264 URL: https://gcc.gnu.org/viewcvs?rev=218264root=gccview=rev Log: PR target/64113 * config/alpha/alpha.md (call_value_osf_tlsgd): Do not split insn using post-reload splitter. Use peephole2 pass instead. (call_value_osf_tlsldm): Ditto. (TLS_CALL): New int iterator. (tls): New int attribute. (call_value_osf_tls): Merge insn pattern from call_value_osf_tlsgd and call_value_tlsldm using TLS_CALL int iterator. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.md
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #28 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Dec 2 10:12:27 2014 New Revision: 218265 URL: https://gcc.gnu.org/viewcvs?rev=218265root=gccview=rev Log: 2014-12-02 Martin Jambor mjam...@suse.cz PR ipa/63814 * ipa-cp.c (same_node_or_its_all_contexts_clone_p): New function. (cgraph_edge_brings_value_p): New parameter dest, use same_node_or_its_all_contexts_clone_p and check availability. (cgraph_edge_brings_value_p): Likewise. (get_info_about_necessary_edges): New parameter dest, pass it to cgraph_edge_brings_value_p. Update caller. (gather_edges_for_value): Likewise. (perhaps_add_new_callers): Use cgraph_edge_brings_value_p to check both the destination and availability. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Martin Jambor jamborm at gcc dot gnu.org --- Fixed (and as I wrote in comment #25, feel free to add testcases if you know how and have environment in which you can verify they would fail without the fix when run by the testsuite).
[Bug ipa/64146] [5 Regression] ipa-icf breaks gold dynamic_test_2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64146 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #30 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Martin Jambor from comment #29) Fixed (and as I wrote in comment #25, feel free to add testcases if you know how and have environment in which you can verify they would fail without the fix when run by the testsuite). On darwin, it's already covered by g++.dg/ipa/pr61160-1.C For linux, I cannot don't know and cannot test.
[Bug ipa/64139] [5 Regression] ice in possible_polymorphic_call_targets, at ipa-devirt.c:2410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64139 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug libstdc++/64147] vector resize() fails for non-copyable type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64147 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Eric Friedman from comment #0) This seems incorrect since C++11 explicitly added a new single argument vector resize method that is supposed to default-construct elements rather than copy them. It default constructs the new elements but when the vector reallocates its storage the existing elements need to be moved or copied to the new storage. Your type is neither movable nor copyable. [vector.capacity] Requires: T shall be MoveInsertable and DefaultInsertable into *this.
[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- I have a patch for fold_builtin_logarithm. But as I understand this PR basically asks for everything. A few more cases are already implemented on the branch.
[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 --- Comment #5 from Igor Zamyatin izamyatin at gmail dot com --- But at the same time difference in good and bad .optimized dumps seems to me insignificant (only some postfix numbers of variables).
[Bug fortran/53379] [4.8/4.9/5 Regression] No backtrace generated for array bounds violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2013-12-29 00:00:00 |2014-12-2 CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- still fails with trunk, while this really was a useful feature. cat test.f90 MODULE m1 CONTAINS SUBROUTINE foo(b) INTEGER, POINTER :: b(:) b(-1)=0 END SUBROUTINE foo END MODULE USE m1 INTEGER, POINTER :: a(:) ALLOCATE(a(0:1)) CALL foo(a) END gfortran -g -fbacktrace -fbounds-check test.f90 ./a.out At line 5 of file test.f90 Fortran runtime error: Index '-1' of dimension 1 of array 'b' below lower bound of 0 While if we use -fsanitize=address (at greatly increased cost), we actually get a Christmas tree with losts of colourful lights: gfortran -g -fsanitize=address test.f90 ./a.out = ==32762==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020ef8c at pc 0x00400c17 bp 0x7fff7f4bd220 sp 0x7fff7f4bd218 WRITE of size 4 at 0x6020ef8c thread T0 #0 0x400c16 in __m1_MOD_foo /data/vjoost/gnu/bugs/test.f90:5 #1 0x400d1a in MAIN__ /data/vjoost/gnu/bugs/test.f90:12 #2 0x400da2 in main /data/vjoost/gnu/bugs/test.f90:9 #3 0x3094e1ed5c in __libc_start_main (/lib64/libc.so.6+0x3094e1ed5c) #4 0x400a48 (/data/vjoost/gnu/bugs/a.out+0x400a48) 0x6020ef8c is located 4 bytes to the left of 8-byte region [0x6020ef90,0x6020ef98) allocated by thread T0 here: #0 0x7fb401b2ab1a in __interceptor_malloc ../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:38 #1 0x400cc2 in MAIN__ /data/vjoost/gnu/bugs/test.f90:11 #2 0x400da2 in main /data/vjoost/gnu/bugs/test.f90:9 #3 0x3094e1ed5c in __libc_start_main (/lib64/libc.so.6+0x3094e1ed5c) SUMMARY: AddressSanitizer: heap-buffer-overflow /data/vjoost/gnu/bugs/test.f90:5 __m1_MOD_foo Shadow bytes around the buggy address: 0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =0x0c047fff9df0: fa[fa]00 fa fa fa 07 fa fa fa 07 fa fa fa 06 fa 0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==32762==ABORTING
[Bug tree-optimization/64148] New: [5.0 Regression][ARM][Aarch64] internal compiler error: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64148 Bug ID: 64148 Summary: [5.0 Regression][ARM][Aarch64] internal compiler error: in verify_ssa, at tree-ssa.c:939 Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target: arm-none-eabi, aarch64-none-elf Created attachment 34160 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34160action=edit Reduced testcase The attached testcase (reduced from Linux kernel source) ICEs with: besttry.c: In function 'register_netdevice': besttry.c:47:20: warning: implicit declaration of function 'dev_net' [-Wimplicit-function-declaration] struct net *net = dev_net(dev); ^ besttry.c:47:20: warning: initialization makes pointer from integer without a cast [-Wint-conversion] besttry.c:49:1: internal compiler error: in verify_ssa, at tree-ssa.c:939 } ^ 0xc47785 verify_ssa(bool, bool) $SRC/gcc/tree-ssa.c:939 0x98f2fb execute_function_todo $SRC/gcc/passes.c:1947 0x98f75d do_per_function $SRC/gcc/passes.c:1639 0x98fc43 execute_todo $SRC/gcc/passes.c:1997 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. This appears on arm-none-eabi and aarch64-none-elf (didn't try x86) I'm using r218259. 4.9 works fine. In any case it seems like a mid-end issue. -O2 is enough to reproduce. -O1 works fine.
[Bug tree-optimization/64148] [5.0 Regression][ARM][Aarch64] internal compiler error: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64148 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.2 Target Milestone|--- |5.0 Known to fail||5.0
[Bug c++/64129] [5.0 regression] ICE on invalid: in grokfndecl, at cp/decl.c:7658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64129 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-02 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- 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 tree-optimization/64148] [5.0 Regression][ARM][Aarch64] internal compiler error: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64148 ktkachov at gcc dot gnu.org changed: What|Removed |Added Attachment #34160|0 |1 is obsolete|| --- Comment #1 from ktkachov at gcc dot gnu.org --- Created attachment 34161 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34161action=edit Newer reduced testcase Here is a more readable reduced case, thanks to jgreenhalgh
[Bug target/64149] New: -mno-lra bitrots, suggest to remove for GCC 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64149 Bug ID: 64149 Summary: -mno-lra bitrots, suggest to remove for GCC 5 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: rguenth at gcc dot gnu.org Target: aarch64 I suggest to remove -mno-lra support from AARCH64 for GCC 5. When trying to reproduce a 4.8/4.9 ICE on trunk I now run into an earlier ICE /abuild/rguenther/obj-aarch64-g/gcc/cc1plus -quiet wxe_funcs.i -O2 -fPIC -w -I /abuild/rguenther/obj-aarch64-g/gcc/include -g -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing -fomit-frame-pointer -mno-lra In file included from /usr/include/wx-3.0/wx/grid.h:14:0, from gen/../wxe_return.h:37, from gen/wxe_funcs.cpp:25: /usr/include/wx-3.0/wx/generic/grid.h: In constructor ‘wxGrid::wxGrid()’: /usr/include/wx-3.0/wx/generic/grid.h:935:24: internal compiler error: in insert_save, at caller-save.c:1338 0x8826fd insert_save /space/rguenther/src/svn/trunk/gcc/caller-save.c:1337 0x8826fd save_call_clobbered_regs() /space/rguenther/src/svn/trunk/gcc/caller-save.c:875 0xc0bb41 reload(rtx_insn*, int) /space/rguenther/src/svn/trunk/gcc/reload1.c:1008 0xaf457d do_reload /space/rguenther/src/svn/trunk/gcc/ira.c:5403 0xaf457d execute /space/rguenther/src/svn/trunk/gcc/ira.c:5561 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. where I suppose the ports reload support simply bitrotted.
[Bug c++/64150] New: Missed optimisation opportunity with moved-from pimpl classes and a nullptr d-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64150 Bug ID: 64150 Summary: Missed optimisation opportunity with moved-from pimpl classes and a nullptr d-pointer Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marc at kdab dot com Created attachment 34162 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34162action=edit Sample program When compiling attached sample program to assembler source, the compiler emits two calls to destroy(), one for p1 and one for p2. However, it should be statically clear that p1.d == nullptr, always, so dead code elimination should remove the check for nullptr, the branch and the call to destroy(). $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/opt/gcc/trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/opt/gcc/trunk --program-suffix=-trunk --enable-checking=release --enable-languages=c,c++,go,fortran,objc,obj-c++ : (reconfigured) ../gcc/configure --prefix=/opt/gcc/trunk --enable-checking=release --enable-languages=c,c++,go,fortran,objc,obj-c++ Thread model: posix gcc version 5.0.0 20141015 (experimental) (GCC)
[Bug c++/64150] Missed optimisation opportunity with moved-from pimpl classes and a nullptr d-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64150
--- Comment #1 from marc at kdab dot com ---
(compiled with g++ -fverbose-asm -std=c++14 -g -O3 -S -o
test-moved-from-dtor.{s,cpp})
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #31 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Martin Jambor from comment #29) Fixed (and as I wrote in comment #25, feel free to add testcases if you know how and have environment in which you can verify they would fail without the fix when run by the testsuite). It isn't fixed on Linux.
[Bug c++/64150] Missed optimisation opportunity with moved-from pimpl classes and a nullptr d-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64150
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
bb 2:
p1 = makePimpled (); [return slot optimization]
_7 = p1.d;
p2.d = _7;
p1.d = 0B;
if (_7 != 0B)
goto bb 3;
else
goto bb 4;
bb 3:
Pimpled::destroy (p2);
bb 4:
p2 ={v} {CLOBBER};
_3 = p1.d;
if (_3 != 0B)
there is nothing that prevents makePimpled from storing a reference to p1
somewhere where Pimpled::destroy could modify it.
Thus it is not valid to assume that p1.d is still null at the if.
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #32 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Dec 2 12:47:29 2014 New Revision: 218268 URL: https://gcc.gnu.org/viewcvs?rev=218268root=gccview=rev Log: Add a test for PR ipa/63814 PR ipa/63814 * g++.dg/ipa/pr63814.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr63814.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #33 from H.J. Lu hjl.tools at gmail dot com --- Without r218265, the new testcase fails on Linux.
[Bug ipa/64146] [5 Regression] ipa-icf breaks gold dynamic_test_2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64146 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Missing targetm.binds_local_p check?
[Bug testsuite/64145] [5 Regression] gcc.dg/graphite/isl-codegen-loop-dumping.c UNRESOLVED after r217315.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64145 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||romangareev at gcc dot gnu.org Component|other |testsuite Summary|gcc.dg/graphite/isl-codegen |[5 Regression] |-loop-dumping.c UNRESOLVED |gcc.dg/graphite/isl-codegen |with isl 0.14 |-loop-dumping.c UNRESOLVED ||after r217315. --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT this has nothing to do with isl 0.14, but is due to a typo in r217315 where -fgraphite-identity -fgraphite-code-generator=isl has been deleted instead of only -fgraphite-code-generator=isl.
[Bug tree-optimization/64148] [5.0 Regression][ARM][Aarch64] internal compiler error: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64148 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of 63569. *** This bug has been marked as a duplicate of bug 63569 ***
[Bug ipa/63569] [5.0 Regression] Wrong code with volatile and ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63569 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 64148 has been marked as a duplicate of this bug. ***
[Bug target/64149] -mno-lra bitrots, suggest to remove for GCC 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64149 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Richard Biener from comment #0) where I suppose the ports reload support simply bitrotted. Just out of curiosity, what remains to be done so that reload can be retired and rest in peace?
[Bug c++/64129] [5.0 regression] ICE on invalid: in grokfndecl, at cp/decl.c:7658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64129
--- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
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.
Hmmm... testcase is in the beginning of the description...
$ cat x.ii
template 0 int __copy_streambufs_eof;
class {
friend __copy_streambufs_eof (
[Bug libstdc++/64096] std::list, set and map violate a rule about allocator::construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64096
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
For completeness, the error for std::list now shows:
a.cc: In instantiation of ‘void my_allocatorT::construct(U*, Args ...)
[with U = int; Args = {int}; T = std::_Rb_tree_nodeint]’:
which is consistent with maps and sets now.
I actually consider it a bug that you don't get the assertion for other
containers too! The unordered containers and forward_list should not bother
constructing a rebound allocator to call construct/destroy.
[Bug rtl-optimization/63718] [5 Regression] ARM Thumb1 bootstrap fail after fuse-caller-save info in cprop-hardreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63718 --- Comment #16 from vries at gcc dot gnu.org --- Author: vries Date: Tue Dec 2 13:35:10 2014 New Revision: 218271 URL: https://gcc.gnu.org/viewcvs?rev=218271root=gccview=rev Log: 2014-12-02 Tom de Vries t...@codesourcery.com PR rtl-optimization/63718 * config/arm/arm.c (arm_option_override): Disable fuse-caller-save for Thumb1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug rtl-optimization/64151] New: [5 Regression] r2182676caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64151 Bug ID: 64151 Summary: [5 Regression] r2182676caused many regressions Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: wdijkstr at arm dot com Target: i686-linux On Linux/i686, r218266 caused: FAIL: gcc.dg/hoist-register-pressure-3.c scan-rtl-dump hoist PRE/HOIST: end of bb .* copying expression FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O1 -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O1 -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O2 -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O2 -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -fomit-frame-pointer -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -fomit-frame-pointer -funroll-loops -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -fomit-frame-pointer -funroll-loops -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -fomit-frame-pointer -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -g -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -O3 -g -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -Os -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-1.c -Os -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O2 -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O2 -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -fomit-frame-pointer -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -fomit-frame-pointer -funroll-loops -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -fomit-frame-pointer -funroll-loops -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -fomit-frame-pointer -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -g -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O3 -g -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -Os -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -Os -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O1 -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O1 -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O2 -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O2 -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O3 -fomit-frame-pointer -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O3 -fomit-frame-pointer -funroll-loops -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O3 -fomit-frame-pointer -funroll-loops -mforce-drap -fpic execution test FAIL: gcc.dg/torture/stackalign/setjmp-4.c -O3 -fomit-frame-pointer -mforce-drap -fpic execution test
[Bug c++/64129] [5.0 regression] ICE on invalid: in grokfndecl, at cp/decl.c:7658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64129 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|WAITING |NEW Known to work||4.9.2 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Ah sorry I didn't realise that was the whole thing.
[Bug target/64108] ICE: SIGSEGV in decide_alg() with -mmemset-strategy=libcall:-1:align -minline-all-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64108 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Dec 2 14:10:23 2014 New Revision: 218272 URL: https://gcc.gnu.org/viewcvs?rev=218272root=gccview=rev Log: Stop only if there aren't any usable algorithms When searching for an usable algorithm with -minline-all-stringops, decide_alg stops when it sees libcall even if there is a usable algorithm. It goes into an infinite loop. This patch changes decide_alg to stop searching only if there aren't any usable algorithms. Testd on Linux/x86-64. gcc/ PR target/64108 * config/i386/i386.c (decide_alg): Stop only if there aren't any usable algorithms. gcc/testsuite/ PR target/64108 * gcc.target/i386/memset-strategy-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/memset-strategy-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/64152] New: internal compiler error: in gen_add2_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64152 Bug ID: 64152 Summary: internal compiler error: in gen_add2_insn Product: gcc Version: 4.9.3 Status: UNCONFIRMED Keywords: ra Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target: aarch64 Created attachment 34163 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34163action=edit preprocessed testcase When compiling the attached testcase with -O -fPIC -fstack-protector -fomit-frame-pointer -mno-lra I get gen/wxe_funcs.cpp:31754:2: internal compiler error: in gen_add2_insn, at optabs.c:4719 0xac23bb gen_add2_insn(rtx_def*, rtx_def*) /space/rguenther/src/svn/gcc-4_9-branch/gcc/optabs.c:4719 0xb1dbd8 gen_reload /space/rguenther/src/svn/gcc-4_9-branch/gcc/reload1.c:8713 0xb23327 emit_input_reload_insns /space/rguenther/src/svn/gcc-4_9-branch/gcc/reload1.c:7669 0xb23327 do_input_reload /space/rguenther/src/svn/gcc-4_9-branch/gcc/reload1.c:7955 0xb23327 emit_reload_insns /space/rguenther/src/svn/gcc-4_9-branch/gcc/reload1.c:8147 0xb23327 reload_as_needed /space/rguenther/src/svn/gcc-4_9-branch/gcc/reload1.c:4665 0xb27800 reload(rtx_def*, int) /space/rguenther/src/svn/gcc-4_9-branch/gcc/reload1.c:1037 0xa2b588 do_reload /space/rguenther/src/svn/gcc-4_9-branch/gcc/ira.c:5469 0xa2b588 rest_of_handle_reload /space/rguenther/src/svn/gcc-4_9-branch/gcc/ira.c:5598 0xa2b588 execute /space/rguenther/src/svn/gcc-4_9-branch/gcc/ira.c:5627 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. this also happens on the 4.8 branch if you backport stack-protector support and without -mno-lra (reload is still the default there). On trunk things have rotted faster and I run into PR64149.
[Bug rtl-optimization/63718] [5 Regression] ARM Thumb1 bootstrap fail after fuse-caller-save info in cprop-hardreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63718 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #17 from Joey Ye joey.ye at arm dot com --- Resolved in 218271, which is a work around. A new PR is expected to open for a complete solution.
[Bug rtl-optimization/64151] [5 Regression] r218266 caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64151 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Target Milestone|--- |5.0
[Bug target/64152] internal compiler error: in gen_add2_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64152 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Compile with cc1plus, it's a C++ testcase.
[Bug target/64115] [4.9/5 Regression] ICE: : in rs6000_delegitimize_address, at config/rs6000/rs6000.c:7051
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115 --- Comment #6 from Ulrich Weigand uweigand at gcc dot gnu.org --- Author: uweigand Date: Tue Dec 2 14:27:46 2014 New Revision: 218273 URL: https://gcc.gnu.org/viewcvs?rev=218273root=gccview=rev Log: PR target/64115 * config/rs6000/rs6000.c (rs6000_delegitimize_address): Remove invalid UNSPEC_TOCREL sanity check under ENABLE_CHECKING. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/64115] [4.9/5 Regression] ICE: : in rs6000_delegitimize_address, at config/rs6000/rs6000.c:7051
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115 --- Comment #7 from Ulrich Weigand uweigand at gcc dot gnu.org --- Author: uweigand Date: Tue Dec 2 14:30:47 2014 New Revision: 218274 URL: https://gcc.gnu.org/viewcvs?rev=218274root=gccview=rev Log: PR target/64115 * config/rs6000/rs6000.c (rs6000_delegitimize_address): Remove invalid UNSPEC_TOCREL sanity check under ENABLE_CHECKING. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
[Bug target/64115] [4.9/5 Regression] ICE: : in rs6000_delegitimize_address, at config/rs6000/rs6000.c:7051
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115 --- Comment #8 from Ulrich Weigand uweigand at gcc dot gnu.org --- Author: uweigand Date: Tue Dec 2 14:33:00 2014 New Revision: 218275 URL: https://gcc.gnu.org/viewcvs?rev=218275root=gccview=rev Log: PR target/64115 * config/rs6000/rs6000.c (rs6000_delegitimize_address): Remove invalid UNSPEC_TOCREL sanity check under ENABLE_CHECKING. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c
[Bug target/64115] [4.9/5 Regression] ICE: : in rs6000_delegitimize_address, at config/rs6000/rs6000.c:7051
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Ulrich Weigand uweigand at gcc dot gnu.org --- Fixed everywhere.
[Bug rtl-optimization/64151] [5 Regression] r218266 caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64151
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-12-02
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
Revert the reg_class change:
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index 72c00cc..16fd6e8 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira-costs.c
@@ -1466,7 +1466,7 @@ scan_one_insn (rtx_insn *insn)
REG_N_SETS (REGNO (SET_DEST (set))) == 1))
general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
{
- enum reg_class cl = ALL_REGS;
+ enum reg_class cl = GENERAL_REGS;
rtx reg = SET_DEST (set);
int num = COST_INDEX (REGNO (reg));
fixes those regressions.
[Bug ipa/64153] [5.0 regression] r218205 miscompiles libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64153 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug ipa/64153] New: [5.0 regression] r218205 miscompiles libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64153 Bug ID: 64153 Summary: [5.0 regression] r218205 miscompiles libgomp Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: mjambor at suse dot cz Blocks: 63551 Target: m68k-*-* Created attachment 34164 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34164action=edit reduced testcase The attached testcase it reduced from libgomp/env.c. When compiled with -O2 it misoptimizes if (task) to 1, losing the call to gomp_new_icv. --- env.s.good +++ env.s.bad2014-12-02 15:29:50.135924092 +0100 @@ -12,26 +12,18 @@ omp_set_num_threads: jsr __m68k_read_tp add.l gomp_tls_data@TLSIE(%a5),%a0 move.l (%a0),%a0 -tst.l %a0 -jeq .L7 move.l 8(%fp),%d0 -jle .L8 -.L4: +jle .L5 move.l %d0,(%a0) move.l -4(%fp),%a5 unlk %fp rts -.L8: +.L5: moveq #1,%d0 move.l %d0,(%a0) move.l -4(%fp),%a5 unlk %fp rts -.L7: -jsr gomp_new_icv -move.l 8(%fp),%d0 -jgt .L4 -jra .L8 .sizeomp_set_num_threads, .-omp_set_num_threads .align2 .globlomp_set_dynamic @@ -43,17 +35,6 @@ omp_set_dynamic: jsr __m68k_read_tp add.l gomp_tls_data@TLSIE(%a5),%a0 move.l (%a0),%a0 -tst.l %a0 -jeq .L14 -tst.l 8(%fp) -sne %d0 -neg.b %d0 -move.b %d0,4(%a0) -move.l -4(%fp),%a5 -unlk %fp -rts -.L14: -jsr gomp_new_icv tst.l 8(%fp) sne %d0 neg.b %d0
[Bug ipa/64153] [5.0 regression] r218205 miscompiles libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64153 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/64152] internal compiler error: in gen_add2_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64152 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/64152] internal compiler error: in gen_add2_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64152 ktkachov at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2014-12-2 CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed FWIW.
[Bug fortran/64138] gfortran interface issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138 --- Comment #5 from david wong.david-c at epa dot gov --- Hi, What is your fix? In the original code, c_sub_cr and c_sub_rc are distinct because the sequence of argument type are different. Other compilers have no problem to distinguish them. Please advise. Cheers, David
[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003 --- Comment #8 from dmalcolm at gcc dot gnu.org --- Created attachment 34165 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34165action=edit Patch to add instrumentation to final.c to track the reads/writes of insn_lengths The attached patch adds instrumentation of all reads/writes of the insn_lengths array.
[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003 --- Comment #9 from dmalcolm at gcc dot gnu.org --- Created attachment 34166 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34166action=edit Dump of RTL from the reproducer
[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003 --- Comment #10 from dmalcolm at gcc dot gnu.org --- Created attachment 34167 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34167action=edit Log from gdb session, with a conditional breakpoint to trap uninitialized reads This is a log of a gdb session debugging cc1 compiling the reproducer from comment #7, using the instrumentation patch from comment #8. I put a breakpoint on: fancy_element::operator int () const with condition that result == 0xabababab to handle reads of uninitialized elements from insn_lengths[]. I took a backtrace both times that the conditional breakpoint occurred.
[Bug fortran/64138] gfortran interface issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Dec 02, 2014 at 03:37:19PM +, wong.david-c at epa dot gov wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138 What is your fix? I meant I fixed the code you posted. It was missing a CONTAINS statement before c_sub_cc, and there is an extra 'j' on the end of one of the 'end function c_sub_??' lines. In the original code, c_sub_cr and c_sub_rc are distinct because the sequence of argument type are different. Other compilers have no problem to distinguish them. Please advise. You can get the code to compile if you change the dummy argument names in c_sub_cr and c_sub_rc to unique entities. For example, (and yes I changed the function and variable names while debugging) type(complex_number) function f2(z1, num) type (complex_number), intent(in) :: z1 real(kind=dp), intent(in) :: num f2%re = z1%re - num f2%im = z1%im end function f2 type(complex_number) function f3(num, z2) type (complex_number), intent(in) :: z2 real(kind=dp), intent(in) :: num f3%re = num - z2%re f3%im = - z2%im end function f3 The only problem with this workaround is that you cannot use keyword argument association. For example, type(complex_number) :: z=complex_number(1.,2.) real x = 3. z = c_sub(num=x, z) The above is ambiguous because the reduced argument list for f2 and f3 are identical, so the generic c_sub can be mapped to either. Fortunately, gfortran tries to help in this situation % gfortran -o z -fmax-errors=1 a.f90 a.f90:53.18: b = c_sub(num=x, a);print '(A,2F5.1)', '(x-a)? = ', b%re, b%im 1 Error: Missing keyword name in actual argument list at (1) Fatal Error: Error count reached limit of 1. Note, however, AFAIK, a keyword is not necessary and is not required. IHMO, issuing this error message could in fact be considered a bug. In fact, if you change the order of arguments to b = c_sub(a, num=x);print '(A,2F5.1)', '(x-a)? = ', b%re, b%im This will compile without error. If the former line producing an error about a missing keyword shouldn't the latter?
[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #11 from dmalcolm at gcc dot gnu.org ---
Investigating the backtrace at the point of the uninit read shows that
the issue occurs in shorten_branches here:
#5 0x006f3263 in shorten_branches (first=0x71687700) at
../../src/gcc/final.c:1286
1284 else if (GET_CODE (body) != USE GET_CODE (body) != CLOBBER)
1285{
1286 insn_lengths[uid] = length_fun (insn);
1287 varying_length[uid] = insn_variable_length_p (insn);
1288}
(gdb) p uid
$7 = 10
(gdb) p length_fun
$8 = (int (*)(rtx_insn *)) 0xbeb5d1 insn_min_length(rtx_insn*)
(gdb) call debug(insn)
(jump_insn:TI 10 4 16 2 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 52)
(pc)))
/home/david/coding-3/gcc-git-jit-valgrind/get-attr-length-i386.c:3 610 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 3300 (nil)))
- 52)
I put insn-attrtab.c through GNU indent to make the conditional easier to read:
(gdb) down
#4 0x00beb7b7 in insn_min_length (insn=0x71685b40) at
insn-attrtab.c:276
276(ix86_bnd_prefixed_insn_p (insn)) + get_attr_length_nobnd (insn);
(gdb) list
271case 611:/* *jcc_2 */
272case 610:/* *jcc_1 */
273 extract_constrain_insn_cached (insn);
274 return
275/*line 516 ../../src/gcc/config/i386/i386.md*/
276(ix86_bnd_prefixed_insn_p (insn)) + get_attr_length_nobnd (insn);
277
278case 163:/* *truncxfdf2_mixed */
279case 162:/* *truncxfsf2_mixed */
280case 160:/* *truncdfsf_i387 */
(gdb) down
#3 0x00bf73b4 in get_attr_length_nobnd (insn=0x71685b40) at
insn-attrtab.c:19152
19152(insn_current_reference_address (insn))) = (-126))
(gdb) list
19147 if INSN_ADDRESSES_SET_P ()?
19148 INSN_ADDRESSES (INSN_UID
19149 (GET_CODE (operands[0]) ==
19150 LABEL_REF ? XEXP (operands[0],
191510) : operands[0])) : 0) -
19152(insn_current_reference_address (insn))) = (-126))
19153
19154 (((INSN_ADDRESSES_SET_P ()?
19155 INSN_ADDRESSES (INSN_UID
19156 (GET_CODE (operands[0]) ==
(gdb) down
#2 0x006f1e23 in insn_current_reference_address
(branch=0x71685b40) at ../../src/gcc/final.c:754
754 - align_fuzz (seq, dest, length_unit_log, ~0));
(gdb) list
749 BRANCH also has no INSN_SHUID. */
750 if (INSN_SHUID (seq) INSN_SHUID (dest))
751{
752 /* Forward branch. */
753 return (insn_last_address + insn_lengths[seq_uid]
754 - align_fuzz (seq, dest, length_unit_log, ~0));
755}
756 else
757{
758 /* Backward branch. */
(gdb) down
#1 0x006f1c4e in align_fuzz (start=0x71685b40, end=0x717b8900,
known_align_log=0, growth=4294967295)
at ../../src/gcc/final.c:703
703 align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];
(gdb) list
698 for (align_label = uid_align[uid]; align_label; align_label =
uid_align[uid])
699{
700 int align_addr, new_align;
701
702 uid = INSN_UID (align_label);
703 align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];
704 if (uid_shuid[uid] end_shuid)
705break;
706 known_align_log = LABEL_TO_ALIGNMENT (align_label);
707 new_align = 1 known_align_log;
i.e. the uninitialized read occurs within align_fuzz in insn_lengths[uid] in
this expressions:
703 align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];
(gdb) p uid
$10 = 52
handling a forward branch within a *jcc_2 insn.
Running valgrind with vgdb to get the precise location of its
warnings indicates they are here within get_attr_length_nobnd in
insn-attrtab.c:19152:
19147 if INSN_ADDRESSES_SET_P ()?
19148 INSN_ADDRESSES (INSN_UID
19149 (GET_CODE (operands[0]) ==
19150 LABEL_REF ? XEXP (operands[0],
191510) : operands[0])) : 0) -
19152(insn_current_reference_address (insn))) = (-126))
19153
19154 (((INSN_ADDRESSES_SET_P ()?
19155 INSN_ADDRESSES (INSN_UID
19156 (GET_CODE (operands[0]) ==
i.e. at the logical-AND at line 19153.
Valgrind presumably is noticing the uninitialized trait of this
read, then propagating it through to the result of align_fuzz,
and thence to insn_current_reference_address, and hence to the whole
of the first argument of the logical-AND.
Hence the decision about whether to process the second argument of
the logical-AND is a jump that relies on an uninitialized value, and
hence valgrind complains.
[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 Nick Clifton nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton nickc at redhat dot com --- Created attachment 34168 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34168action=edit Patch for reload to avoid using argument regiesters when reloading a call insn
[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003 --- Comment #12 from dmalcolm at gcc dot gnu.org --- (In reply to dmalcolm from comment #11) Running valgrind with vgdb to get the precise location of its warnings indicates they are here within get_attr_length_nobnd in insn-attrtab.c:19152: 19147 if INSN_ADDRESSES_SET_P ()? 19148 INSN_ADDRESSES (INSN_UID 19149 (GET_CODE (operands[0]) == 19150 LABEL_REF ? XEXP (operands[0], 19151 0) : operands[0])) : 0) - 19152 (insn_current_reference_address (insn))) = (-126)) 19153 19154 (((INSN_ADDRESSES_SET_P ()? 19155 INSN_ADDRESSES (INSN_UID 19156 (GET_CODE (operands[0]) == i.e. at the logical-AND at line 19153. Valgrind presumably is noticing the uninitialized trait of this read, then propagating it through to the result of align_fuzz, and thence to insn_current_reference_address, and hence to the whole of the first argument of the logical-AND. Hence the decision about whether to process the second argument of the logical-AND is a jump that relies on an uninitialized value, and hence valgrind complains. i.e. the issue is that evaluating both sides of the (and) expression at line 10931 in: 10920 (define_insn *jcc_1 10921[(set (pc) 10922 (if_then_else (match_operator 1 ix86_comparison_operator 10923[(reg FLAGS_REG) (const_int 0)]) 10924(label_ref (match_operand 0)) 10925(pc)))] 10926 10927%!%+j%C1\t%l0 10928[(set_attr type ibr) 10929 (set_attr modrm 0) 10930 (set (attr length_nobnd) 10931 (if_then_else (and (ge (minus (match_dup 0) (pc)) 10932(const_int -126)) 10933(lt (minus (match_dup 0) (pc)) 10934(const_int 128))) 10935 (const_int 2) 10936 (const_int 6)))]) 10937 for a forward jump, leads to reads of uninitialized items from insn_lengths in align_fuzz for the uid for the jump target. Hence we have an (and (UNINITIALIZED_1) (WILL_BE_UNINITIALIZED_2)) and hence the decision about whether to short-circuit the read of WILL_BE_UNINITIALIZED_2 is a conditional jump that depends on UNINITIALIZED_1.
[Bug libstdc++/64103] conflicting definitions in parallel/algo.h and algorithmfwd.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64103 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- Author: doko Date: Tue Dec 2 16:32:24 2014 New Revision: 218278 URL: https://gcc.gnu.org/viewcvs?rev=218278root=gccview=rev Log: 2014-12-02 Matthias Klose d...@ubuntu.com PR libstdc++/64103 Backport from mainline 2014-11-03 Paolo Carlini paolo.carl...@oracle.com * include/parallel/algo.h: Do not use default arguments in function template redeclarations (definitions). 2014-11-04 Jonathan Wakely jwak...@redhat.com * include/parallel/numeric.h: Do not use default arguments in function template redeclarations (definitions). Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/parallel/algo.h branches/gcc-4_9-branch/libstdc++-v3/include/parallel/numeric
[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 --- Comment #3 from Nick Clifton nickc at redhat dot com --- Hi Alex, This appears to be a reload bug. Before reload we have: (call_insn 12 (call:HI (mem:HI (mem:HI (plus:HI (reg:HI R14) (const_int 2 (const_int 0)) After reload this becomes: (insn 17 (set (reg:HI R14) (mem:HI (plus:HI (reg:HI R14) (const_int 2) (call_insn 12 (call:HI (mem:HI (reg:HI R14)) (const_int 0))) The uploaded patch fixes this but, not being a reload expert, I am not sure if this is the correct way to solve the problem. It also seems suspicious that if this is a generic reload problem, then why has it not been reported and fixed before now ?
[Bug libstdc++/64103] conflicting definitions in parallel/algo.h and algorithmfwd.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64103 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Matthias Klose doko at gcc dot gnu.org --- backported
[Bug libstdc++/64103] conflicting definitions in parallel/algo.h and algorithmfwd.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64103 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug fortran/64138] gfortran interface issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- I was sure to have seen discussions about such issues: pr33997 and https://groups.google.com/forum/#!msg/comp.lang.fortran/GIcxE7GM1ek/aP7eJpQ-T7QJ AFAIU the discussions, the relevant point for this PR is (b) A nonoptional non-passed-object dummy argument whose name is such that either the other procedure has no dummy argument with that name or the dummy argument with that name is distinguishable with it. Along this line I have renamed num to num1 and z1 to z2 in c_sub_rc module complex_number_module implicit none integer, parameter :: loc_real_precision = 8 type complex_number real(kind=loc_real_precision) :: real_part, imag_part end type complex_number interface c_sub module procedure c_sub_cc, ! z1 - z2 c_sub_cr, ! z1 - num, where num is a real number c_sub_rc! num - z1, where num is a real number end interface contains ! -- type (complex_number) function c_sub_cc (z1, z2) type (complex_number), intent(in) :: z1, z2 c_sub_cc%real_part = z1%real_part - z2%real_part c_sub_cc%imag_part = z1%imag_part - z2%imag_part end function c_sub_cc ! -- type (complex_number) function c_sub_cr (z1, num) type (complex_number), intent(in) :: z1 real(kind=loc_real_precision), intent(in) :: num c_sub_cr%real_part = z1%real_part - num c_sub_cr%imag_part = z1%imag_part end function c_sub_cr ! -- type (complex_number) function c_sub_rc (num1, z2) type (complex_number), intent(in) :: z2 real(kind=loc_real_precision), intent(in) :: num1 c_sub_rc%real_part = num1 - z2%real_part c_sub_rc%imag_part = - z2%imag_part end function c_sub_rc end module complex_number_module program foo use complex_number_module type(complex_number) a, b real(loc_real_precision) x a%real_part = 1 a%imag_part = 2 x = 3 b = c_sub(a, x); print '(A,2F5.1)', 'a-x = ', b%real_part, b%imag_part b = c_sub(x, a); print '(A,2F5.1)', 'x-a = ', b%real_part, b%imag_part b = c_sub(z1=a, num=x); print '(A,2F5.1)', 'a-x = ', b%real_part, b%imag_part b = c_sub(num=x,z1=a); print '(A,2F5.1)', 'a-x = ', b%real_part, b%imag_part b = c_sub(num1=x,z2=a); print '(A,2F5.1)', 'x-a = ', b%real_part, b%imag_part end program foo This made the code to compile and if I am not mistaken to produce the correct result a-x = -2.0 2.0 x-a = 2.0 -2.0 a-x = -2.0 2.0 a-x = -2.0 2.0 x-a = 2.0 -2.0 Out of curiosity why do want to handle complex numbers through types while they are perfectly handled in Fortran by kinds? To conclude I think this PR should be closed as INVALID.
[Bug target/64154] New: enable fuse-caller-save for Thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64154 Bug ID: 64154 Summary: enable fuse-caller-save for Thumb1 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org For PR 63718, we disabled -fuse-caller-save for Thumb1 in arm.c: ... /* In Thumb1 mode, we emit the epilogue in RTL, but the last insn - epilogue_insns - does not accurately model the corresponding insns emitted in the asm file. In particular, see the comment in thumb_exit 'Find out how many of the (return) argument registers we can corrupt'. As a consequence, the epilogue may clobber registers without fuse-caller-save finding out about it. Therefore, disable fuse-caller-save in Thumb1 mode. TODO: Accurately model clobbers for epilogue_insns and reenable fuse-caller-save. */ if (TARGET_THUMB1) flag_use_caller_save = 0; ... We want to fix the target to properly model the clobbers in the rtl insn epilogue_insns, such that we can re-enable -fuse-caller-save.
[Bug rtl-optimization/63718] [5 Regression] ARM Thumb1 bootstrap fail after fuse-caller-save info in cprop-hardreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63718 --- Comment #18 from vries at gcc dot gnu.org --- (In reply to Joey Ye from comment #17) A new PR is expected to open for a complete solution. PR 64154 - enable fuse-caller-save for Thumb1
[Bug fortran/64138] gfortran interface issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138 --- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Dec 02, 2014 at 05:13:09PM +, dominiq at lps dot ens.fr wrote: To conclude I think this PR should be closed as INVALID. That's the conclusion that I'm leaning towards. Reading section 16 of the standard always makes my head hurt, so I'm being caution while looking for some subtle point that I may have missed.
[Bug fortran/64138] gfortran interface issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- That's the conclusion that I'm leaning towards. Reading section 16 of the standard always makes my head hurt, so I'm being caution while looking for some subtle point that I may have missed. And the threads I have pointed to are also convoluted. Now I find quite clear that using the same names for the dummy arguments in c_sub_cr and c_sub_rc does not permit to distinguish between c_sub_cr(num=x,z1=a) and c_sub_rc(num=x,z1=a), while using different names does.
[Bug middle-end/64155] New: [5 Regression] ICE in remove_unreachable_nodes, at ipa.c:546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64155 Bug ID: 64155 Summary: [5 Regression] ICE in remove_unreachable_nodes, at ipa.c:546 Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Created attachment 34169 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34169action=edit Test case (test.ii); use: g++ -O2 -w test.ii Appears with today's r218273; I think it worked yesterday but it might also have been Friday. # g++ -O2 -w test.ii fails with test_new_18.ii:104:1: internal compiler error: in remove_unreachable_nodes, at ipa.c:546 } ^ 0xb379e3 symbol_table::remove_unreachable_nodes(bool, _IO_FILE*) ../../gcc/ipa.c:546 0x12df8ec ipa_inline ../../gcc/ipa-inline.c:2193 0x12df8ec execute ../../gcc/ipa-inline.c:2558
[Bug middle-end/64155] [5 Regression] ICE in remove_unreachable_nodes, at ipa.c:546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64155 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Hmm, seems to be a duplicate of PR 64068 *** This bug has been marked as a duplicate of bug 64068 ***
[Bug ipa/64068] [5 Regression] ICE: in remove_unreachable_nodes, at ipa.c:546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64068 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- *** Bug 64155 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org --- Yes, this seems a generic reload bug. The comment ahead of the lines you're adding say: If [...] the operand contains a register that dies in this insn *and is used nowhere else* [...] which is supposed to be implemented by this check: ! refers_to_regno_for_reload_p (regno, end_hard_regno (rel_mode, regno), PATTERN (this_insn), inloc) But this doesn't look into registers used as function arguments. I'm not sure why this hasn't occured elsewhere ... however, in your particular case, it is triggered by a call insn pattern using memory-indirect addressing, which is probably not available on many targets. Your patch is a little too conservative, however: it rejects any register that could potentially be used as function argument, even if it isn't actually used in this particular call. Can you check whether this alternative patch (using find_reg_fusage) also fixes the problem for you?
[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010 --- Comment #5 from Ulrich Weigand uweigand at gcc dot gnu.org --- Created attachment 34170 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34170action=edit Do not clobber function argument registers
[Bug ipa/64153] [5.0 regression] r218205 miscompiles libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64153 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-02 CC||jamborm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org --- Mine.
[Bug ipa/64153] [5.0 regression] r218205 miscompiles libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64153 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 34171 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34171action=edit Untested fix I'm testing this fix - but on a x86_64-linux, together with other stuff, just to be sure, I have debugged this only using a cross compiler, so any testing on real affected hw is welcome.
[Bug rtl-optimization/64156] New: Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156
Bug ID: 64156
Summary: Subversion id 218266 breaks the big-endian 64-bit
PowerPC build (wilco.dijkstra at arm dot com's mod to
ira-costs.c)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
Build: powerpc64-unknown-linux-gnu
Subversion id 218266 breaks the big-endian 64-bit PowerPC build. Please either
revert the patch or fix it so that the PowerPC now builds once again. You can
see the failure by building a cross compiler. It fails when building the
32-bit libgcc on the _powisf module. If I remove the -fPIC option, it will
compile the module.
Here is the failure message:
make[4]: Entering directory
`/data/meissner/fsf-build-x86_64/trunk-powerpc64-linux/powerpc64-linux/32/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/home/meissner/fsf-build-x86_64/trunk-powerpc64-linux/./gcc/xgcc
-B/home/meissner/fsf-build-x86_64/trunk-powerpc64-linux/./gcc/
-B/home/meissner/fsf-install-x86_64/trunk-powerpc64-linux/powerpc64-linux/bin/
-B/home/meissner/fsf-install-x86_64/trunk-powerpc64-linux/powerpc64-linux/lib/
-isystem
/home/meissner/fsf-install-x86_64/trunk-powerpc64-linux/powerpc64-linux/include
-isystem
/home/meissner/fsf-install-x86_64/trunk-powerpc64-linux/powerpc64-linux/sys-include
-g -O2 -m32 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC
-mlong-double-128 -mno-minimal-toc -I. -I. -I../../.././gcc
-I/home/meissner/fsf-src/trunk/libgcc -I/home/meissner/fsf-src/trunk/libgcc/.
-I/home/meissner/fsf-src/trunk/libgcc/../gcc
-I/home/meissner/fsf-src/trunk/libgcc/../include
-I/home/meissner/fsf-src/trunk/libgcc/../libdecnumber/dpd
-I/home/meissner/fsf-src/trunk/libgcc/../libdecnumber -DHAVE_CC_TLS -o
_powisf2.o -MT _powisf2.o -MD -MP -MF _powisf2.dep -DL_powisf2 -c
/home/meissner/fsf-src/trunk/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
/tmp/ccN1BGVd.s: Assembler messages:
/tmp/ccN1BGVd.s:87: Error: can't resolve `.LC0' {.rodata.cst4 section} -
`.LCTOC1' {.got2 section}
/tmp/ccN1BGVd.s:87: Error: expression too complex
make[4]: *** [_powisf2.o] Error 1
make[4]: Leaving directory
`/data/meissner/fsf-build-x86_64/trunk-powerpc64-linux/powerpc64-linux/32/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/data/meissner/fsf-build-x86_64/trunk-powerpc64-linux/powerpc64-linux/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory
`/data/meissner/fsf-build-x86_64/trunk-powerpc64-linux/powerpc64-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory
`/data/meissner/fsf-build-x86_64/trunk-powerpc64-linux'
make: *** [all] Error 2
[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Dup of PR64151?
[Bug target/64113] Gcc on Alpha: Error: No lda !gpdisp!282 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64113 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Tue Dec 2 19:29:28 2014 New Revision: 218282 URL: https://gcc.gnu.org/viewcvs?rev=218282root=gccview=rev Log: PR target/64113 * config/alpha/alpha.md (call_value_osf_tlsgd): Do not split insn using post-reload splitter. Use peephole2 pass instead. (call_value_osf_tlsldm): Ditto. (TLS_CALL): New int iterator. (tls): New int attribute. (call_value_osf_tls): Merge insn pattern from call_value_osf_tlsgd and call_value_tlsldm using TLS_CALL int iterator. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/alpha/alpha.md
[Bug target/64113] Gcc on Alpha: Error: No lda !gpdisp!282 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64113 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for 4.9.3+.
[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Note, the fix proposed in PR64151 DOES NOT work on the PowerPC, so it may be a dup in terms of what change broke the build, but the potential fix needs more analysis.
[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug ipa/64153] [5.0 regression] r218205 miscompiles libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64153 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- I've posted the patch to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00205.html
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK, the problem is that the unit is compiled without -O2 and -fdevirtualize is
not properly marked as Optimization (have separate patch for this).
However it seems that for units that are not optimized with -fdevirtualize we
can just drop OBJ_TYPE_REF and save some of IL memory?
Jason, does this have chance to interfere with devirtualization required by C++
language that happens at -fno-devirtualize too?
Honza
Index: cp/class.c
===
--- cp/class.c (revision 218249)
+++ cp/class.c (working copy)
@@ -736,7 +736,8 @@ build_vfn_ref (tree instance_ptr, tree i
cp_build_addr_expr (aref, tf_warning_or_error));
/* Remember this as a method reference, for later devirtualization. */
- aref = build3 (OBJ_TYPE_REF, TREE_TYPE (aref), aref, instance_ptr, idx);
+ if (flag_devirtualize)
+aref = build3 (OBJ_TYPE_REF, TREE_TYPE (aref), aref, instance_ptr, idx);
return aref;
}
Index: testsuite/g++.dg/lto/pr64043_0.C
===
--- testsuite/g++.dg/lto/pr64043_0.C(revision 0)
+++ testsuite/g++.dg/lto/pr64043_0.C(revision 0)
@@ -0,0 +1,14 @@
+// { dg-lto-do link }
+// { dg-lto-options { { -flto -std=c++11 } } }
+// { dg-extra-ld-options -r -nostdlib -O2 }
+class Validator
+{
+public:
+ virtual ~Validator ();
+};
+class FooWriter
+{
+ Validator *validator;
+ ~FooWriter ();
+};
+FooWriter::~FooWriter () { delete validator; }
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Actually my tree has flag_devirtualize marked as Optimization, as a separate problem I need to figure out how it happens to be true.
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #3) Jason, does this have chance to interfere with devirtualization required by C++ language that happens at -fno-devirtualize too? No, non-virtual calls to virtual functions never make it to build_vfn_ref.
[Bug rtl-optimization/64151] [5 Regression] r218266 caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64151
--- Comment #2 from Wilco wdijkstr at arm dot com ---
(In reply to H.J. Lu from comment #1)
Revert the reg_class change:
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index 72c00cc..16fd6e8 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira-costs.c
@@ -1466,7 +1466,7 @@ scan_one_insn (rtx_insn *insn)
REG_N_SETS (REGNO (SET_DEST (set))) == 1))
general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
{
- enum reg_class cl = ALL_REGS;
+ enum reg_class cl = GENERAL_REGS;
rtx reg = SET_DEST (set);
int num = COST_INDEX (REGNO (reg));
fixes those regressions.
Confirmed. The intention of this code is to account for reduced memory cost of
constant loads - when they spill they do not need a store, but can be trivially
rematerialized. What happens is that memory_move_cost returns 100 for certain
cases on x86. With ALL_REGS the mem_cost then becomes very negative as it is
not clamped to zero and this forces the register allocator to spill. This is
bad as __builtin_longjmp on x86 loads EBP/ESP directly via 2 separate
instructions which means reload *may* insert spill code inbetween. So if the
base register is spilled and reloaded via EBP, it corrupts ESP:
movl-4(%ebp), %edx
movl(%edx), %ebp * restore EBP
movl-4(%ebp), %ecx * oops, this uses a different EBP
movl8(%ecx), %esp
jmp *%eax
I think there are cases where reload just gives up and inserts dumb spill code
(ie. one reload per use), which means this issue can happen under other
circumstances as well.
It appears ALL_REGS works for x86 and avoids the regression, however this is
not correct either for FP or SIMD registers which would get 100 and then get
spilled.
[Bug rtl-optimization/64151] [5 Regression] r218266 caused many regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64151 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- See also PR64156 for the same issue on ppc64.
[Bug c++/60978] -Wenum-compare warns too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot com --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #5) I think it should not warn for anonymous enums. The point of the warning is that using different enum types in a conditional expression is often some programming mistake. But in the case of anonymous enums, they are probably just used as named constants, so there is no much point in warning. I don't think I agree. Even with anonymous enums there is the risk that, as in the reduced testcase here, you end up returning the same value by different names. You shouldn't get the warning about IPPROTO_ICMP vs IPPROTO_ICMPV66, as they are members of the same anonymous enum. If 4.9 started complaining, that's the bug.
[Bug c++/60978] -Wenum-compare warns too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #9 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Jason Merrill from comment #8)
You shouldn't get the warning about IPPROTO_ICMP vs IPPROTO_ICMPV66, as they
are members of the same anonymous enum.
They are?
In glibc-2.19, include/netinet/in.h:
/* Standard well-defined IP protocols. */
enum
{
IPPROTO_IP = 0, /* Dummy protocol for TCP. */
#define IPPROTO_IPIPPROTO_IP
IPPROTO_ICMP = 1, /* Internet Control Message Protocol. */
#define IPPROTO_ICMPIPPROTO_ICMP
...
};
/* If __USE_KERNEL_IPV6_DEFS is defined then the user has included the kernel
network headers first and we should use those ABI-identical definitions
instead of our own. */
#ifndef __USE_KERNEL_IPV6_DEFS
enum
{
IPPROTO_HOPOPTS = 0, /* IPv6 Hop-by-Hop options. */
...
IPPROTO_ICMPV6 = 58, /* ICMPv6. */
...
};
Looks like different anonymous enums to me.
