[Bug target/64154] enable fipa-ra for Thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64154
--- Comment #2 from Terry Guo ---
Hi Tom,
I enabled this optimization to thumb1 target cortex-m0 and found this IPA-RA
optimization doesn't consider the register clobber information attached to call
rtx and thus generated bad code. Here are the bad rtxs I extracted from the
dump of cprop_hardreg pass:
(insn 292 291 141 13 (set (reg:SI 4 r4 [orig:163 ivtmp.108 ] [163])
(reg:SI 12 ip [orig:163 ivtmp.108 ] [163])) 742 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:SI 12 ip [orig:163 ivtmp.108 ] [163])
(nil)))
(call_insn 141 292 142 13 (parallel [
(call (mem:SI (symbol_ref:SI ("f2") [flags 0x3] ) [0 f2 S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
/myssd/terguo01/toolchain-build/GCC32RM-424/src/gcc/gcc/testsuite/gcc.dg/vshift-3.c:119
770 {*call_insn}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("f2") [flags 0x3] )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list (clobber (reg:SI 12 ip))
(nil)))
(insn 11 10 12 13 (set (reg:SI 0 r0 [orig:170 ivtmp.130 ] [170])
(reg:SI 12 ip [orig:163 ivtmp.108 ] [163]))
/myssd/terguo01/toolchain-build/GCC32RM-424/src/gcc/gcc/testsuite/gcc.dg/vshift-3.c:121
742 {*thumb1_movsi_insn}
(expr_list:REG_EQUAL (symbol_ref:SI ("j") [flags 0x80] )
(nil)))
I checked the code in 'if (CALL_P (insn))' part in file regcprop.c and found
the algorithm doesn't consider the '(expr_list (clobber (reg:SI 12 ip))' in
insn 141 which makes current algorithm think it is safe to propagate ip from
insn 292 to insn 11.
The case is from gcc regression test and compiled with option "-mthumb
-mcpu=cortex-m0 -O3".
[Bug other/64534] New: invalid -march value incosistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64534 Bug ID: 64534 Summary: invalid -march value incosistency Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jlec at gentoo dot org Overwriting invalid -march later in the command line has an inconsistency Following works gcc -march=no-automagic -march=core2 gcc -march=no-automagic -march=pentium-m Following breaks gcc -march=no-automagic -march=native I would prefer that the build always breaks with error: bad value (no-automagic) for -march= switch but we should at least have the same behavior for both cases.
[Bug tree-optimization/64530] [4.9/5 Regression] Incorrect calculation when assigning to array with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64530 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.3 --- Comment #4 from Jakub Jelinek --- Started with r204062.
[Bug target/64533] [5 Regression] [SH] alloca generates unsafe code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64533 --- Comment #1 from Kazumoto Kojima --- Author: kkojima Date: Thu Jan 8 09:05:06 2015 New Revision: 219338 URL: https://gcc.gnu.org/viewcvs?rev=219338&root=gcc&view=rev Log: PR target/64533 * config/sh/sh.md (*addsi3_compact): Use u constraint instead of r for the second alternative of the destination operand. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Mine.
[Bug tree-optimization/64530] [4.9/5 Regression] Incorrect calculation when assigning to array with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64530 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Mine.
[Bug tree-optimization/64404] [5 Regression] ICE: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1464 with --param=sccvn-max-alias-queries-per-access=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64404 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Richard Biener --- Mine.
[Bug sanitizer/64336] Template functions are not instrumented at -O0 and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jan 8 09:20:24 2015 New Revision: 219339 URL: https://gcc.gnu.org/viewcvs?rev=219339&root=gcc&view=rev Log: PR sanitizer/64336 * tree.c (build2_stat): Fix up initialization of TREE_READONLY and TREE_THIS_VOLATILE for MEM_REFs. (build5_stat): Fix up initialization of TREE_READONLY and TREE_THIS_VOLATILE for TARGET_MEM_REFs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c
[Bug libstdc++/64535] New: Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 Bug ID: 64535 Summary: Emergency buffer for exception allocation too small Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org It was reported to us that in a heavily threaded environment the number of emergency EH objects in libsubc++ eh_alloc.cc is too small (64). To mitigate this it looks like we could use a TLS variable for the buffer instead (libstdc++ already contains TLS variables for __once_call at least), which also would get rid of the scoped lock (which hopefully will never allocate memory...?). If you use exceptions to catch and recover from low-memory situations __cxa_allocate_exception calling std::terminate () becomes a correctness issue (not sure what the C++ standard says about throwing exceptions in low-memory situations).
[Bug sanitizer/64336] Template functions are not instrumented at -O0 and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Should be fixed now.
[Bug target/64533] [5 Regression] [SH] alloca generates unsafe code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64533 Kazumoto Kojima changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Kazumoto Kojima --- Fixed.
[Bug rtl-optimization/64536] New: [4.9/5 Regression] Undefined .L* symbol starting with jump2 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64536
Bug ID: 64536
Summary: [4.9/5 Regression] Undefined .L* symbol starting with
jump2 on s390x
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org, vmakarov at gcc dot gnu.org
Target: s390x-linux
struct S { long q; } *h;
long a, b, g, j, k, *c, *d, *e, *f, *i;
long *baz (void)
{
asm volatile ("" : : : "memory");
return e;
}
void
bar (int x)
{
int y;
for (y = 0; y < x; y++)
{
switch (b)
{
case 0:
case 2:
a++;
break;
case 3:
a++;
break;
case 1:
a++;
}
if (d)
{
f = baz ();
g = k++;
if (&h->q)
{
j = *f;
h->q = *f;
}
else
i = (long *) (h->q = *f);
*c++ = (long) f;
e += 6;
}
else
{
f = baz ();
g = k++;
if (&h->q)
{
j = *f;
h->q = *f;
}
else
i = (long *) (h->q = *f);
*c++ = (long) f;
e += 6;
}
}
}
int
main ()
{
return 0;
}
fails to link on s390x-linux with -O2 -m64 -fPIC, starting with r199754.
For a tablejump, we load of the jump_table_data label is hoisted before the
loop, then RA decides to spill it to stack (seems both with reload and lra),
and then jump2 goes wild and deletes the casesi_jump instruction (and lots of
other instructions it supposedly should not delete), but keeps the load of
jump_table_data label (but the jump_table_data is gone).
[Bug rtl-optimization/64536] [4.9/5 Regression] Undefined .L* symbol starting with jump2 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64536 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-08 Target Milestone|--- |4.9.3 Ever confirmed|0 |1
[Bug c++/64462] ICE while compiling lambda using local constexpr reference variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64462 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-08 CC||ville.voutilainen at gmail dot com Known to work||5.0 Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.1 --- Comment #1 from Ville Voutilainen --- I don't see an ICE with the current trunk.
[Bug rtl-optimization/64537] New: Aarch64 redundant sxth instruction gets generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64537
Bug ID: 64537
Summary: Aarch64 redundant sxth instruction gets generated
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vekumar at gcc dot gnu.org
For the below test case redundant sxth instruction gets generate.
int
adds_shift_ext ( long long a, short b, int c)
{
long long d = (a - ((long long)b << 3));
if (d == 0)
return a + c;
else
return b + d + c;
}
adds_shift_ext:
sxthw1, w1 // 3*extendhisi2_aarch64/1 [length = 4] <==1
subsx3, x0, x1, sxth 3 // 11 *subs_extvdi_multp2 [length
= 4] <==2
beq .L5 // 12 *condjump [length = 4]
add w0, w1, w2 // 19 *addsi3_aarch64/2 [length = 4]
add w0, w0, w3 // 20 *addsi3_aarch64/2 [length = 4]
ret // 57 simple_return [length = 4]
.p2align 2
.L5:
add w0, w2, w0 // 14 *addsi3_aarch64/2 [length = 4]
ret // 55 simple_return [length = 4]
<== 1 is not needed.
[Bug tree-optimization/59354] Element swizzling produces invalid result with -O3 (tree-cunrolli pass problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354
Uroš Bizjak changed:
What|Removed |Added
Component|middle-end |tree-optimization
Summary|Unexpected result in g++|Element swizzling produces
|when casting int to char|invalid result with -O3
|from an stl vector to an|(tree-cunrolli pass
|array |problem?)
--- Comment #3 from Uroš Bizjak ---
It looks to me that cunrolli pass is messing up element swizzling code.
bisection-friendly C testcase:
--cut here--
void abort (void);
unsigned int a[256];
unsigned char b[256];
int main()
{
int i, z, x, y;
for(i = 0; i < 256; i++)
a[i] = i % 5;
for (z = 0; z < 16; z++)
for (y = 0; y < 4; y++)
for (x = 0; x < 4; x++)
b[y*64 + z*4 + x] = a[z*16 + y*4 + x];
if (b[4] != 1)
abort ();
return 0;
}
--cut here--
gcc-5 on x86_64-linux-gnu with the above testcase:
~/gcc-build/gcc/cc1 -O3 pr59354.c
Aborted
~/gcc-build/gcc/cc1 -O3 -fdisable-tree-cunrolli pr59354.c
OK
"Working" code produces following array:
Breakpoint 1, main () at pr59354.c:18
18if (b[4] != 1)
(gdb) p b
$1 =
"\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\002\003\004\000\003\004\000\001"...
(gdb)
while "non-working" produces:
(gdb) p b
$1 =
"\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\003\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001\004\000\001\002\000\001\002\003\001\002\003\004\002\003\004\000\003\004\000\001",
'\000'
(gdb)
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #93 from Oleg Endo --- Author: olegendo Date: Thu Jan 8 11:07:45 2015 New Revision: 219341 URL: https://gcc.gnu.org/viewcvs?rev=219341&root=gcc&view=rev Log: gcc/ PR target/55212 * config/sh/sh.md (*addsi3_compact): Emit reg-reg copy instead of constant load if constant operand fits into I08. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #1 from Richard Biener --- It was pointed out that the pool is very large (even if reduced to 4 entries) and thus undesirable for TLS (would be 4k then). An alternative is to use a free list with variable size objects, initialized to just a single one of the emergency buffer size. You'd split the entry you pop off and only use a small portion of it (freeing would need to support merging and keeping the list sorted). Fragmentation might be an issue then, but for the case in question which is throwing std::bad_alloc (much smaller than 1024 bytes) it might increase the effective number of available objects enough.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #2 from Richard Biener --- Also exceptions larger than std::bad_alloc should not eat from the emergency buffer but instead cause std::bad_alloc to be thrown? Thus EMERGENCY_OBJ_SIZE could be very much smaller.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #3 from Richard Biener --- Seeing that we have EH reference counted makes me think we should simply have a single global std::bad_alloc EH to re-use?
[Bug c++/29455] Issues with -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455 Preston L Bannister changed: What|Removed |Added CC||preston at bannister dot us --- Comment #9 from Preston L Bannister --- (In reply to Hallvard B Furuseth from comment #7) > > The warning in C++ is arguably bogus because the value of the > > character '%' is known at compile-time, consequently the warning > > is unwarranted (unless it really is negative). > > unwarranted unless it _could_ be negative on some host. Are there any hosts of this sort left? And for which GCC compiles? The job of the compiler is to generate code for a specific machine. For a character literal the compiler knows the exact value. If the value were negative, a warning is justified. Generating a warning on code that is correct for the target is not useful. Likely the code will never be compiled on a platform where the warning is correct. Given almost no possibility the warning will ever be correctly identify a problem, this is at least a very poor choice, and infinitely close to a bug. :)
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #4 from Richard Biener ---
Is the following required to work?
#include
#include
#include
struct large
{
char s[1024*1024*1024];
};
int main()
{
rlimit lim;
lim.rlim_cur = 1024*1024*1024;
lim.rlim_max = 1024*1024*1024;
setrlimit (RLIMIT_AS, &lim);
try {
throw large ();
} catch (large&) {
} catch (std::bad_alloc) {
}
}
I get
> ./a.out
terminate called without an active exception
Aborted
[Bug ipa/64538] New: [4.9/5 Regression] Devirt ICE in possible_polymorphic_call_targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64538
Bug ID: 64538
Summary: [4.9/5 Regression] Devirt ICE in
possible_polymorphic_call_targets
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
struct A {};
template struct I;
struct P { virtual ~P(); };
template struct B;
struct J : P { friend I>; virtual B &foo(int); };
struct L : virtual J, virtual P {};
struct C { P &c; C(P &p1) : c(p1) {} };
template struct I : C {
typedef typename B::template F<0>::t R;
J &c;
I(J &p1) : C(p1), c(p1) {}
R &bar(int) { c.foo(0); }
};
template struct K : A {
typedef typename T::S S;
bool baz(const int &, I &p2, I &p3);
};
struct D { virtual void foo(); };
template struct B { template struct F { typedef int t; }; };
struct M : P, virtual public J {};
struct N : public M, virtual L {};
struct O : public N, D { O(int); };
struct G { typedef B S; template struct H { typedef O t; }; };
template
bool K::baz(const int &, I &p2, I &p3) {
typedef typename T::template H<0>::t W;
typedef typename S::template F<0>::t R;
W a(0);
I b(a);
R &c = b.bar(0);
}
template struct K<0, G>;
with -std=c++0x -O2 started to ICE with r201836 and while the exact spot where
it ICEd changed several times, it continues to ICE with current 4.9 branch and
latest trunk.
[Bug ipa/64538] [4.9/5 Regression] Devirt ICE in possible_polymorphic_call_targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64538 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-08 CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.3 Ever confirmed|0 |1
[Bug target/63949] Aarch64 instruction combiner does not optimize subsi_sxth function as expected (gcc.target/aarch64/extend.c fails)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #9 from Segher Boessenkool --- A MULT by a constant power of 2 is not canonical RTL (well, not what simplify_rtx would give you); combine shouldn't generate this.
[Bug rtl-optimization/64537] Aarch64 redundant sxth instruction gets generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64537 kugan at gcc dot gnu.org changed: What|Removed |Added CC||kugan at gcc dot gnu.org --- Comment #1 from kugan at gcc dot gnu.org --- According to AAPCS64 (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf), the unused parm register bits have "unspecified value".So I think it is needede.
[Bug rtl-optimization/64537] Aarch64 redundant sxth instruction gets generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64537 --- Comment #2 from Andrew Pinski --- (In reply to kugan from comment #1) > According to AAPCS64 > (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/ > IHI0055C_beta_aapcs64.pdf), the unused parm register bits have "unspecified > value".So I think it is Needed It is not needed because the next instruction has a sign extend and the other uses of the result of the sign extend only use the lower 32bits of the register.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #5 from Richard Biener --- Created attachment 34399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34399&action=edit patch fixing comment #4 This fixes the issue in comment #4 (it also decreases the emergency EH object size).
[Bug rtl-optimization/64537] Aarch64 redundant sxth instruction gets generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64537 --- Comment #3 from kugan at gcc dot gnu.org --- But isn't w1 is passed with 16bit value (short b) here. Am I missing something here?
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- (In reply to Marc Glisse from comment #1) > There are a number of things that make it complicated. > 1) gcc doesn't like to vectorize when the number of iterations is not known > at compile time. Not an issue, we know it here (it's symbolic) > 2) gcc doesn't vectorize anything already involving complex or vector > operations. Indeed - here the issue is that we have C++ 'complex' aggregate load / store operations: _67 = MEM[(const struct complex &)_75]; __r$_M_value = _67; ... _51 = REALPART_EXPR <__r$_M_value>; REALPART_EXPR <__r$_M_value> = _104; ... IMAGPART_EXPR <__r$_M_value> = _107; _108 = __r$_M_value; MEM[(struct cx_double *)_72] = _108; which SRA for some reason didn't decompose as they are not aggregate (well, they are COMPLEX_TYPE). They are not in SSA form either because they are partly written to. In this case it would have been profitable to SRA __r$_M_value. Eventually this should have been complex lowerings job (but it doesn't try to decompose complex assignments). > 3) the ABI for complex uses 2 separate double instead of a vector of 2 > double. I think that's unrelated. > I believe there are dups at least for 2).
[Bug fortran/63733] [4.8/4.9/5 Regression] [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > likely r187226 (pr53255), back ported to 4.7 as r187232. I just tried reverting that one (r187226 on trunk), but it does not change the behavior of the test case in comment 0.
[Bug fortran/63733] [4.8/4.9/5 Regression] [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > likely r195729 (pr54195). Reverting this commit on trunk yields: test_ov.f90:7:32: generic :: operator(+) => sum 1 Error: Entity »sum_parent« at (1) is already present in the interface So it's not the cause of this regression either.
[Bug fortran/63733] [4.8/4.9/5 Regression] [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> likely r189022 (pr49591).
I think this one is the culprit. Reverting the relevant part restores the
expected behavior. Patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(Revision 219342)
+++ gcc/fortran/resolve.c(Arbeitskopie)
@@ -11894,21 +11894,6 @@ resolve_typebound_intrinsic_op (gfc_symbol* derive
if (!gfc_check_operator_interface (target_proc, op, p->where))
goto error;
-
- /* Add target to non-typebound operator list. */
- if (!target->specific->deferred && !derived->attr.use_assoc
- && p->access != ACCESS_PRIVATE && derived->ns == gfc_current_ns)
-{
- gfc_interface *head, *intr;
- if (!gfc_check_new_interface (derived->ns->op[op], target_proc,
p->where))
-return false;
- head = derived->ns->op[op];
- intr = gfc_get_interface ();
- intr->sym = target_proc;
- intr->where = p->where;
- intr->next = head;
- derived->ns->op[op] = intr;
-}
}
return true;
[Bug target/64154] enable fipa-ra for Thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64154
--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Terry Guo from comment #2)
> Hi Tom,
>
> I enabled this optimization to thumb1 target cortex-m0
Does that mean you just reverted the patch for PR63718?
> and found this IPA-RA
> optimization doesn't consider the register clobber information attached to
> call rtx
The IPA-RA analysis does consider that clobber. It's using
find_all_hard_reg_sets, and that function contains a loop over
CALL_INSN_FUNCTION_USAGE.
> and thus generated bad code. Here are the bad rtxs I extracted from
> the dump of cprop_hardreg pass:
>
> (insn 292 291 141 13 (set (reg:SI 4 r4 [orig:163 ivtmp.108 ] [163])
> (reg:SI 12 ip [orig:163 ivtmp.108 ] [163])) 742 {*thumb1_movsi_insn}
> (expr_list:REG_DEAD (reg:SI 12 ip [orig:163 ivtmp.108 ] [163])
> (nil)))
>
> (call_insn 141 292 142 13 (parallel [
> (call (mem:SI (symbol_ref:SI ("f2") [flags 0x3] 0x7f8182689100 f2>) [0 f2 S4 A32])
> (const_int 0 [0]))
> (use (const_int 0 [0]))
> (clobber (reg:SI 14 lr))
> ])
> /myssd/terguo01/toolchain-build/GCC32RM-424/src/gcc/gcc/testsuite/gcc.dg/
> vshift-3.c:119 770 {*call_insn}
> (expr_list:REG_CALL_DECL (symbol_ref:SI ("f2") [flags 0x3]
> )
> (expr_list:REG_EH_REGION (const_int 0 [0])
> (nil)))
> (expr_list (clobber (reg:SI 12 ip))
> (nil)))
>
> (insn 11 10 12 13 (set (reg:SI 0 r0 [orig:170 ivtmp.130 ] [170])
> (reg:SI 12 ip [orig:163 ivtmp.108 ] [163]))
> /myssd/terguo01/toolchain-build/GCC32RM-424/src/gcc/gcc/testsuite/gcc.dg/
> vshift-3.c:121 742 {*thumb1_movsi_insn}
> (expr_list:REG_EQUAL (symbol_ref:SI ("j") [flags 0x80] 0x7f81827d0750 j>)
> (nil)))
>
That is wrong indeed: ip is explicitly clobbered by the call in
CALL_INSN_FUNCTION_USAGE, but used as if not clobbered by the call.
> I checked the code in 'if (CALL_P (insn))' part in file regcprop.c and found
> the algorithm doesn't consider the '(expr_list (clobber (reg:SI 12 ip))' in
> insn 141 which makes current algorithm think it is safe to propagate ip from
> insn 292 to insn 11.
>
I cannot reproduce the wrong code as listed above. But I can reproduce the
clobber being skipped by copyprop_hardreg_forward_1. So I agree, cprop_hardreg
does not respect the clobber on the call in CALL_INSN_FUNCTION_USAGE.
I'll file a PR.
[Bug fortran/63733] [4.8/4.9/5 Regression] [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) > (In reply to Dominique d'Humieres from comment #1) > > likely r189022 (pr49591). > > I think this one is the culprit. Reverting the relevant part restores the > expected behavior. Patch: As expected, this fails on typebound_operator_16.f03, but nothing else.
[Bug fortran/64522] [4.8/4.9/5 Regression] Free-form source code: -Wline-truncation is no longer enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64522
--- Comment #1 from Tobias Burnus ---
Seems to be a side effect of PR39229 (r151258, 2009-08-31 = during 4.5
development) as the patch removed the following from parse.c:
- if ((gfc_option.warn_line_truncation || gfc_current_form ==
FORM_FREE)
- && gfc_current_locus.lb
- && gfc_current_locus.lb->truncated)
- gfc_warning_now ("Line truncated at %C");
Note the condition on FORM_FREE.
Possible patch (if one wants to stay with a warning and no an error):
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -252,3 +252,3 @@ Warn about called procedures not explicitly declared
Wline-truncation
-Fortran Warning Var(warn_line_truncation) LangEnabledBy(Fortran,Wall)
+Fortran Warning Var(warn_line_truncation) LangEnabledBy(Fortran,Wall) Init(-1)
Warn about truncated source lines
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -307,3 +307,8 @@ gfc_post_options (const char **pfilename)
gfc_warning_now ("%<-fd-lines-as-code%> has no effect in free form");
+
+ if (warn_line_truncation == -1)
+warn_line_truncation = 1;
}
+ else if (warn_line_truncation == -1)
+warn_line_truncation = 0;
Or, alternative, for options.c if one wants to have an error; this variant
falls back to a warning if one explicitly uses -Wline-truncation (or
-Wno-error).
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -307,0 +308,12 @@ gfc_post_options (const char **pfilename)
+
+ if (warn_line_truncation == -1)
+{
+ warn_line_truncation = 1;
+ /* Enable -Werror=line-truncation when -Werror and -Wno-error have
+ not been set. */
+ if (!global_options_set.x_warnings_are_errors
+ && (global_dc->classify_diagnostic[OPT_Wline_truncation] ==
+ DK_UNSPECIFIED))
+diagnostic_classify_diagnostic (global_dc, OPT_Wline_truncation,
+DK_ERROR, UNKNOWN_LOCATION);
+}
@@ -308,0 +321,2 @@ gfc_post_options (const char **pfilename)
+ else if (warn_line_truncation == -1)
+warn_line_truncation = 0;
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|NEW |ASSIGNED Blocks||53947 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- (In reply to Richard Biener from comment #5) > (In reply to Marc Glisse from comment #1) > > There are a number of things that make it complicated. > > 1) gcc doesn't like to vectorize when the number of iterations is not known > > at compile time. > > Not an issue, we know it here (it's symbolic) > > > 2) gcc doesn't vectorize anything already involving complex or vector > > operations. > > Indeed - here the issue is that we have C++ 'complex' aggregate > load / store operations: > > _67 = MEM[(const struct complex &)_75]; > __r$_M_value = _67; > ... > _51 = REALPART_EXPR <__r$_M_value>; > REALPART_EXPR <__r$_M_value> = _104; > ... > IMAGPART_EXPR <__r$_M_value> = _107; > _108 = __r$_M_value; > MEM[(struct cx_double *)_72] = _108; > > which SRA for some reason didn't decompose as they are not aggregate > (well, they are COMPLEX_TYPE). They are not in SSA form either because > they are partly written to. And this forces it to be TREE_ADDRESSABLE. Which means update-address-taken might be a better candidate to fix this. Note that it will still run into the issue that the vectorizer does not like complex types (in loads), nor does it like building complex registers via COMPLEX_EXPR. After fixing update-address-taken we have __r$_M_value_70 = MEM[(const struct complex &)_78]; _66 = MEM[(const double &)_77]; _54 = REALPART_EXPR <__r$_M_value_70>; _105 = _54 + _66; _135 = IMAGPART_EXPR <__r$_M_value_70>; _106 = MEM[(const double &)_77 + 8]; _107 = _106 + _135; __r$_M_value_180 = COMPLEX_EXPR <_105, _107>; MEM[(struct cx_double *)_76] = __r$_M_value_180; which we ideally would have converted to piecewise loading / storing, but the vectorizer may also be able to recover here with some twists. > In this case it would have been profitable > to SRA __r$_M_value. Eventually this should have been complex lowerings > job (but it doesn't try to decompose complex assignments). > > > 3) the ABI for complex uses 2 separate double instead of a vector of 2 > > double. > > I think that's unrelated. > > > I believe there are dups at least for 2).
[Bug rtl-optimization/64537] Aarch64 redundant sxth instruction gets generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64537 --- Comment #4 from Richard Earnshaw --- b is used twice, once shifted left by 3 and once directly. We could write this as subsx3, x0, x1, sxth 3 beq .L5 add w0, w2, w1, sxth <= Now extended add w0, w0, w3 ret .p2align 2 .L5: add w0, w2, w0 ret which in this specific case would perhaps be more efficient, but in practice it's quite hard to get this sort of multiple-use right. I think this is a special case, however, of the more common 'un-cse' type of problem, where multiple uses of an extended (or shifted) value are always commoned up. Note that modern CPUs may take an extra cycle to perform an ALU-with-shift type operation, eliminating the benefit of sinking multiple uses down into the ALU operations themselves.
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #7 from Richard Biener --- Created attachment 34400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34400&action=edit update-address-taken fix
[Bug rtl-optimization/64539] New: [5 regression] cprop_hardreg does not respect clobbers in C_I_F_U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64539
Bug ID: 64539
Summary: [5 regression] cprop_hardreg does not respect clobbers
in C_I_F_U
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
As discussed in PR64154 comment 2 and 3, the clobbers in
CALL_INSN_FUNCTION_USAGE are in general not registered by
copyprop_hardreg_forward_1.
F.i. in this thumb1 call insn there's a clobber of the ip reg, that is ignored
by cprop_hardreg:
...
(call_insn 141 292 142 13 (parallel [
(call (mem:SI (symbol_ref:SI ("f2") [flags 0x3] ) [0 f2 S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
/myssd/terguo01/toolchain-build/GCC32RM-424/src/gcc/gcc/testsuite/gcc.dg/vshift-3.c:119
770 {*call_insn}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("f2") [flags 0x3] )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list (clobber (reg:SI 12 ip))
(nil)))
...
I can't rule out that this is a generic bug, so marking tentatively as 5.0
regression.
[Bug target/64154] enable fipa-ra for Thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64154 --- Comment #4 from vries at gcc dot gnu.org --- > I'll file a PR. PR 64539: '[5 regression] cprop_hardreg does not respect clobbers in C_I_F_U'
[Bug rtl-optimization/64539] [5 regression] cprop_hardreg does not respect clobbers in C_I_F_U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64539 --- Comment #1 from vries at gcc dot gnu.org --- In order to fix this, I'll probably first have to understand the PR57003 issue and fix.
[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638
Scott Lipcon changed:
What|Removed |Added
CC||slipcon at gmail dot com
--- Comment #9 from Scott Lipcon ---
We saw the same issue with gcc 4.9.2 on x86_64 Linux - we build the compiler
with --disable-shared in order to be able to deliver our software on systems
without libstdc++.so. Without the patches in this issue, we were unable to
link our .sos to libstdc++.a because of the missing -fPIC. The patch I ended
up using was a bit different than those in the comments below, but seems to be
working for our installation:
--- libstdc++-v3/configure.ac.orig2015-01-08 08:40:40.480754159 -0500
+++ libstdc++-v3/configure.ac2015-01-08 08:43:27.633844665 -0500
@@ -120,6 +120,11 @@
glibcxx_compiler_pic_flag="$lt_prog_compiler_pic_CXX"
glibcxx_compiler_shared_flag="-D_GLIBCXX_SHARED"
+elif test "${with_pic+set}" = set; then
+ glibcxx_lt_pic_flag="-prefer-pic"
+ glibcxx_compiler_pic_flag="$lt_prog_compiler_pic_CXX"
+ glibcxx_compiler_shared_flag=
+
else
glibcxx_lt_pic_flag=
glibcxx_compiler_pic_flag=
I hope this gets applied to an official release at some point.
[Bug driver/64540] New: [4.9 regression] Casting to/from long double emits ambiguous fild/fisttp instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64540
Bug ID: 64540
Summary: [4.9 regression] Casting to/from long double emits
ambiguous fild/fisttp instruction
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: zanpeeters at gmail dot com
Created attachment 34401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34401&action=edit
Minimal code example
GCC 4.9.2 emits a fild instruction for a cast of signed char, unsigned char, or
signed short (but not unsigned short) to long double. For the reverse cast a
fisttp instruction is emitted.
Minimal code example:
int main()
{
unsigned char a = 0;
long double d = 0.0;
d = (long double)a;
return 0;
}
On a Mac, compiling this minimal code with -Wa,-q (send -q to the assembler,
which then uses the clang built in assembler rather than as) generates the
following error:
> gcc -Wa,-q minexmpl.c
/var/folders/Dc/DcfDPTBiHROi8AvxZY9-HE+++TI/-Tmp-//cc7UuOqP.s:16:2: error:
ambiguous instructions require an explicit suffix (could be 'filds', or
'fildl')
fild-34(%rbp)
GCC 4.8.3 emits filds/fisttps instructions for the same code and does not
generate an error when send to the clang assembler. Since GCC 4.8.3 emitted the
correct instructions this seems a regression to me. Any particular reason this
change was made?
Attached is a complete minimal code example with all casting combinations that
lead to errors. On any OS (also non-Mac):
> gcc-4.9 -S -o out49.s fild_fisttp.c
> gcc-4.8 -S -o out48.s fild_fisttp.c
> diff -u out48.s out49.s
--- out48.s
+++ out49.s
@@ -14,25 +14,25 @@
fstpt -32(%rbp)
- filds -4(%rbp)
+ fild-4(%rbp)
fstpt -32(%rbp)
fldt-32(%rbp)
- fisttps -34(%rbp)
+ fisttp -34(%rbp)
movzwl -34(%rbp), %eax
(truncated for brevity, full diff below)
Note 1:
Not accepting fild, fisttp, and others is a design choice by LLVM, see
http://clang.llvm.org/compatibility.html#inline-asm I have tested the above
minimal code example with Apple clang 3.0/XCode 4.2, Macports clang 3.3, and
Macports clang 3.5 and all give the same result.
Note 2:
The reason for using the clang assembler is that the as assembler on Mac is
very old and does not accept AVX or newer instructions, as explained here:
https://stackoverflow.com/questions/9840207/how-to-use-avx-pclmulqdq-on-mac-os-x-lion
=
Other information:
System: Mac OS X 10.6.8
gcc version 4.9.2 (MacPorts gcc49 4.9.2_1)
Using built-in specs.
COLLECT_GCC=gcc-mp-4.9
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.9.2/lto-wrapper
Target: x86_64-apple-darwin10
Configured with:
/opt/local/var/macports/build/_Users_zan_Library_Macports_lang_gcc49/gcc49/work/gcc-4.9.2/configure
--prefix=/opt/local --disable-silent-rules --build=x86_64-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc49 --includedir=/opt/local/include/gcc49
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.9 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.9
--with-gxx-include-dir=/opt/local/include/gcc49/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--disable-isl-version-check --with-cloog=/opt/local
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc49 4.9.2_1'
Thread model: posix
gcc version 4.8.3 (MacPorts gcc48 4.8.3_2)
COLLECT_GCC=gcc-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.8.3/lto-wrapper
Target: x86_64-apple-darwin10
Configured with:
/opt/local/var/macports/build/_Users_zan_Library_Macports_lang_gcc48/gcc48/work/gcc-4.8.3/configure
--prefix=/opt/local --disable-silent-rules --build=x86_64-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.8
--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-cloog=/opt/local
--enable-cloog-backend=isl --disable-cloog-version-check
--disable-isl-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gc
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #8 from Marc Glisse --- (In reply to Richard Biener from comment #5) > (In reply to Marc Glisse from comment #1) > > There are a number of things that make it complicated. > > 1) gcc doesn't like to vectorize when the number of iterations is not known > > at compile time. > > Not an issue, we know it here (it's symbolic) IIRC I tried modifying the original code by replacing all complex operations by explicit scalar operations and it failed to vectorize, but worked when replacing the number of iterations by a constant. > > 3) the ABI for complex uses 2 separate double instead of a vector of 2 > > double. > > I think that's unrelated. Indeed, it's just that with a different ABI we could have been lucky and stumbled upon the optimal code, almost by accident.
[Bug driver/64540] [4.9 regression] Casting to/from long double emits ambiguous fild/fisttp instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64540 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Sounds like user error to me. This is nothing that changed in between 4.8 and 4.9, but depends on against which assembler you configure gcc. If you configure it against old assembler that doesn't accept filds/fists instructions, then it will emit fild, otherwise it emits filds. Similarly, if assembler doesn't accept fildq/fistpq instruction, it will emit fildll. This is checked during gcc configure.
[Bug tree-optimization/59354] [4.8/4.9/5/Regression] Element swizzling produces invalid result with -O3 (tree-cunrolli pass problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354 H.J. Lu changed: What|Removed |Added Summary|Element swizzling produces |[4.8/4.9/5/Regression] |invalid result with -O3 |Element swizzling produces |(tree-cunrolli pass |invalid result with -O3 |problem?) |(tree-cunrolli pass ||problem?) --- Comment #4 from H.J. Lu --- It is caused by r147829 (the new SLP pass).
[Bug tree-optimization/59354] [4.8/4.9/5/Regression] Element swizzling produces invalid result with -O3 (tree-cunrolli pass problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.5
[Bug tree-optimization/59354] [4.8/4.9/5/Regression] Element swizzling produces invalid result with -O3 (tree-cunrolli pass problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354 --- Comment #5 from H.J. Lu --- (In reply to H.J. Lu from comment #4) > It is caused by r147829 (the new SLP pass). It may just expose the latent bug.
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #9 from Richard Biener --- Created attachment 34402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34402&action=edit patch to pattern-detect the load/store This pattern matches real/imagpart uses and single-use complex stores and transforms them to component-wise accesses in forwprop. Together we vectorize the loop now and produce: .L28: movupd (%rbx,%rax), %xmm1 movupd (%r15,%rax), %xmm0 addpd %xmm1, %xmm0 movups %xmm0, 0(%r13,%rax) addq$16, %rax cmpq%rax, %rdx jne .L28 note that we need a runtime alias check to disambiguate things (because std::vector memory cannot be disambiguated statically) and similarly we cannot prove sufficent alignment to use aligned loads/stores.
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #10 from Richard Biener --- Improves runtime from 8.3s to 6.5s (~25%).
[Bug rtl-optimization/64536] [4.9/5 Regression] Undefined .L* symbol starting with jump2 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64536
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
So, we have bb 6:
(note 180 23 24 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 24 180 25 6 (set (reg:DI 1 %r1 [orig:88 b ] [88])
(zero_extend:DI (reg:SI 1 %r1 [orig:85 b+4 ] [85]))) method-to-ir3.i:15
184 {*zero_extendsidi2}
(nil))
(insn 25 24 289 6 (set (reg:DI 1 %r1 [orig:88 b ] [88])
(ashift:DI (reg:DI 1 %r1 [orig:88 b ] [88])
(const_int 3 [0x3]))) method-to-ir3.i:15 570 {*ashldi3}
(nil))
(insn 289 25 27 6 (set (reg/f:DI 2 %r2 [158])
(mem/c:DI (plus:DI (reg/f:DI 15 %r15)
(const_int 184 [0xb8])) [5 %sfp+-8 S8 A64])) method-to-ir3.i:15
63 {*movdi_64}
(nil))
(insn 27 289 28 6 (set (reg:DI 1 %r1 [87])
(mem/u/c:DI (plus:DI (reg/f:DI 2 %r2 [158])
(reg:DI 1 %r1 [orig:88 b ] [88])) [0 S8 A8]))
method-to-ir3.i:15 63 {*movdi_64}
(expr_list:REG_EQUAL (mem/u/c:DI (plus:DI (reg:DI 1 %r1 [orig:88 b ] [88])
(label_ref:DI 29)) [0 S8 A8])
(nil)))
(jump_insn 28 27 29 6 (parallel [
(set (pc)
(plus:DI (reg/f:DI 2 %r2 [158])
(reg:DI 1 %r1 [87])))
(use (label_ref 29))
]) method-to-ir3.i:15 626 {casesi_jump}
(expr_list:REG_DEAD (reg/f:DI 2 %r2 [158])
(expr_list:REG_DEAD (reg:DI 1 %r1 [87])
(nil)))
-> 29)
with:
(code_label 29 28 30 7 "" [2 uses])
(jump_table_data 30 29 31 (addr_diff_vec:DI (label_ref:DI 29)
[
(label_ref:DI 50)
(label_ref:DI 50)
(label_ref:DI 50)
(label_ref:DI 50)
]
(const_int 0 [0])
(const_int 0 [0])))
after it (outside of bb) (as all the case labels do the same thing, they have
been jump threaded, but unfortunately not at GIMPLE, but only at RTL level) and
post_order_compute calls tidy_fallthru_edges which calls tidy_fallthru_edge
on the only successor edge from bb 6 (6 -> 9, bb 9 is the bb starting with
code_label 50). When all the jump_table_data labels point to the same
destination, it is reasonable to optimize that to direct jump, but I guess we
need to take care about making sure that the code_label before the
jump_table_data is only removed when it has zero LABEL_NUSES.
[Bug rtl-optimization/64536] [4.9/5 Regression] Undefined .L* symbol starting with jump2 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64536 --- Comment #2 from Eric Botcazou --- > When all the jump_table_data labels point to the same destination, it is > reasonable to optimize that to direct jump, but I guess we need to take care > about making sure that the code_label before the jump_table_data is only > removed when it has zero LABEL_NUSES. Very likely indeed (delete_related_insns does something like that).
[Bug c++/60753] Deleted definition of an explicit function template specialization, following a declaration, incorrectly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60753 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jan 8 15:48:36 2015 New Revision: 219347 URL: https://gcc.gnu.org/viewcvs?rev=219347&root=gcc&view=rev Log: /cp 2015-01-08 Paolo Carlini PR c++/60753 * decl.c (grokfndecl): Add bool parameter. (grokdeclarator): Adjust calls. (start_decl): Don't set DECL_DELETED_FN here. /testsuite 2015-01-08 Paolo Carlini PR c++/60753 * g++.dg/cpp0x/deleted10.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #19 from iverbin at gcc dot gnu.org --- (In reply to iverbin from comment #18) > It seems that the problem with offload is that -fPIC option is passed to the > offload compiler, but not passed to the host compiler. If I add -fPIC to the > host compiler as well, everything is ok. > > I don't know how -fPIC option affects IR before streaming out, > -fdump-tree-optimized are identical for pic/nonpic cases, but > .gnu.offload_lto_.decls sections are different. However debug_tree > (vnode->decl) for "G" in ipa_write_summaries are identical for pic/nonpic > cases. > > So, the question is, how to figure out what is different in G's declaration > in IR, and how it can affect further expansion? The regression is caused by LTO streaming of TARGET_OPTIMIZE_NODE: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00376.html
[Bug tree-optimization/64541] New: .fre1 pass optimization failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541 Bug ID: 64541 Summary: .fre1 pass optimization failure Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: skvadrik at gmail dot com Created attachment 34403 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34403&action=edit 1.c 2.c 1.c.028t.esra 2.c.028t.esra 1.c.030t.fre1 2.c.030t.fre1 1.s 2.s compile_gcc.sh Files 1.c and 2.c in attach are equivalent from C/C++ standpoint: $ diff 1.c 2.c 3c3,5 < return *(*q = ++*p); --- > ++*p; > *q = *p; > return **p; Compiled with gcc-5.0.0, disassembled with objdump (GNU Binutils) 2.24 (see full script compile_gcc.sh in attach). For 1.c gcc generates better code than for 2.c (compare 1.s vs 2.s in attach). I looked at GIMPLE optimization dumps (-fdump-tree-all) and found that up to *.029t.ealias pass dumps differ insignificantly (attached *.028t.esra dumps as they are shorter), but .030t.fre1 pass fails to reduce intermediate variable '_9' in the second case (attached *.030t.fre dumps). Looks like a bug in full redundancy elimination.
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #20 from Jakub Jelinek --- http://gcc.gnu.org/ml/gcc-patches/2014-11/msg02654.html seems to fix all these.
[Bug c++/60753] Deleted definition of an explicit function template specialization, following a declaration, incorrectly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60753 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini --- Fixed for 5.0.
[Bug c/64526] No warning on function call with excessive arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64526 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Henderson --- Still invalid.
[Bug libstdc++/60132] C++11: lack of is_trivially_copy_constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Thu Jan 8 16:24:55 2015 New Revision: 219350 URL: https://gcc.gnu.org/viewcvs?rev=219350&root=gcc&view=rev Log: PR libstdc++/60132 * include/std/type_traits (has_trivial_default_constructor, has_trivial_copy_constructor, has_trivial_copy_assign): Add deprecated attribute. * testsuite/20_util/has_trivial_copy_assign/requirements/ explicit_instantiation.cc: Use -Wno-deprecated. * testsuite/20_util/has_trivial_copy_assign/requirements/typedefs.cc: Likewise. * testsuite/20_util/has_trivial_copy_assign/value.cc: Likewise. * testsuite/20_util/has_trivial_copy_constructor/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/has_trivial_copy_constructor/requirements/ typedefs.cc: Likewise. * testsuite/20_util/has_trivial_copy_constructor/value.cc: Likewise. * testsuite/20_util/has_trivial_default_constructor/requirements/ explicit_instantiation.c: Likewise. * testsuite/20_util/has_trivial_default_constructor/requirements/ typedefs.cc: Likewise. * testsuite/20_util/has_trivial_default_constructor/value.cc: Likewise. * testsuite/20_util/pair/requirements/dr801.cc: Replace deprecated trait. * testsuite/20_util/tuple/requirements/dr801.cc: Likewise. * testsuite/util/testsuite_common_types.h: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/value.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/value.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_default_constructor/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_default_constructor/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/has_trivial_default_constructor/value.cc trunk/libstdc++-v3/testsuite/20_util/pair/requirements/dr801.cc trunk/libstdc++-v3/testsuite/20_util/tuple/requirements/dr801.cc trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h
[Bug target/64027] inefficient handling of msp430 byte operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Peter, I have applied a patch to the linker: https://sourceware.org/ml/binutils/2015-01/msg00090.html This will transform the 4-byte BR instructions into 2-byte JMP instructions, which the code size issue you raised as point 2. Cheers Nick
[Bug rtl-optimization/64536] [4.9/5 Regression] Undefined .L* symbol starting with jump2 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64536
--- Comment #3 from Jakub Jelinek ---
Created attachment 34404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34404&action=edit
gcc5-pr64536.patch
Given that tidy_fallthru_edge seems to be called only rarely, I think adding
too much code to handle tablejumps with single successor is not a good idea.
So I think we should just give up on tablejumps there. And perhaps make sure
we optimize single successor tablejumps somewhere else, where it is run often
enough that it will be actually beneficial.
E.g.
int a;
#define A(n) case n: a++; break;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) \
A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) \
B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
void
foo (int x)
{
switch (x)
{
C(1)
}
}
on x86_64 with -O2 or -O2 -fpic isn't optimized, because tidy_fallthru_edges
isn't called and so we do not even attempt to do anything about it.
On the s390x testcase it is called just because some other cleanup in another
part of the function created unreachable blocks that need cleanup.
And, wonder why tree-ssa-tail-merge.c doesn't want to optimize this. Perhaps
it gives up because of the load and store?
[Bug target/64542] New: ARM use of ARM instruction on Thumb-only target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542
Bug ID: 64542
Summary: ARM use of ARM instruction on Thumb-only target
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
$ arm-rtems4.11-gcc --version
arm-rtems4.11-gcc (GCC) 4.9.3 20150104 (prerelease)
arm-rtems4.11-gcc --pipe -mthumb -march=armv6-m --pipe -DHAVE_CONFIG_H
-I../../.. -I../../../../../../lib/include -g -O2 -Wall
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
libscorecpu_a-cpu.o -MD -MP -MF .deps/libscorecpu_a-cpu.Tpo -c -o
libscorecpu_a-cpu.o `test -f 'cpu.c' || echo
'/users/joel/test-gcc/rtems/cpukit/score/cpu/arm/'`cpu.c
{standard input}: Assembler messages:
{standard input}:187: Error: selected processor does not support ARM opcodes
{standard input}:188: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `mrs r3,cpsr'
{standard input}:189: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `bic r3,#(1<<7)'
{standard input}:190: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `orr r3,r0'
{standard input}:191: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `msr cpsr,r3'
{standard input}:192: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `add r3,pc,#1'
{standard input}:193: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `bx r3'
{standard input}:218: Error: selected processor does not support ARM opcodes
{standard input}:219: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `mrs r0,cpsr'
{standard input}:220: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `and r0,#(1<<7)'
{standard input}:221: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `add r3,pc,#1'
{standard input}:222: Error: attempt to use an ARM instruction on a Thumb-only
processor -- `bx r3'
[Bug target/64542] ARM use of ARM instruction on Thumb-only target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542 --- Comment #1 from Joel Sherrill --- Created attachment 34405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34405&action=edit Processed output from RTEMS cpu.c which produces the error Looking at the error message, I am not sure if this is invalid code generated by GCC or conditionally selected by RTEMS. Filing this as a GCC PR and adding RTEMS folks to get a ruling.
[Bug target/64542] ARM use of ARM instruction on Thumb-only target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542 Joel Sherrill changed: What|Removed |Added Target||arm-rtems CC||sebastian.huber@embedded-br ||ains.de --- Comment #2 from Joel Sherrill --- The attachment produces the error with this command line: arm-rtems4.11-gcc -mthumb -march=armv6-m -c -O0 /tmp/arm-thumb-pr64542.c
[Bug target/64542] ARM use of ARM instruction on Thumb-only target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Earnshaw --- The testcase contains inline ARM assembly statements. The errors are hardly surprising.
[Bug lto/64543] New: gcc fails to build due to undefined references to functions in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64543 Bug ID: 64543 Summary: gcc fails to build due to undefined references to functions in libiberty Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: mikulas at artax dot karlin.mff.cuni.cz Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu The current gcc 5.0 (r219330) fails to build on Debian Wheezy x86-64. It reports many symbols in libiberty as undefined. The bug may have been caused by switching to slim lto objects. MAKEFLAGS=-j12 export MAKEFLAGS ../gcc-svn/configure\ --prefix=/usr/local/gcc-svn/\ --enable-lto\ --with-system-zlib \ --enable-languages=c\ --enable-multilib \ --with-multilib-list=m32,m64\ --with-build-config=bootstrap-lto \ --disable-werror\ --enable-checking=release \ && nice -n 20 make profiledbootstrap
[Bug target/64542] ARM use of ARM instruction on Thumb-only target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64542 --- Comment #4 from Richard Earnshaw --- Note that armv6-m doesn't support ARM instructions at all, so the .arm directive is meaningless.
[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #11 from Eric Gallager --- If changing the code generation or adding a new flag to control this is too difficult, how about just adding this to the list of things that "-Wstack-protector" warns about in the meantime?
[Bug c/64526] No warning on function call with excessive arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64526 --- Comment #5 from Chengnian Sun --- (In reply to jos...@codesourcery.com from comment #3) > "has no parameters" does not mean "has a type that includes a prototype > with no parameters". See DR#317. > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_317.htm Thanks for your pointer. But from the perspective of diagnostics, I believe it is worthy to emit a warning on this case, as the execution of the function call is undefined according to the standard.
[Bug middle-end/39218] a surprising instance of -fstack-protector not protecting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39218 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > > Maybe it should say character buffers rather than just buffers here. Yeah, that would help clarify stuff a lot... the term "buffer" is kind of ambiguous as it currently stands, which makes it hard to know how exactly how to deal with warnings from "-Wstack-protector"... I had been trying messing with other sorts of buffers besides character buffers before reading this...
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 58761, which changed state. Bug 58761 Summary: ICE with a lambda capturing this in a NSDMI https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58761 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58761] ICE with a lambda capturing this in a NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58761 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Paolo Carlini --- I think we can close this.
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 58761, which changed state. Bug 58761 Summary: ICE with a lambda capturing this in a NSDMI https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58761 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/64539] [5 regression] cprop_hardreg does not respect clobbers in C_I_F_U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64539
--- Comment #2 from vries at gcc dot gnu.org ---
At first glance, this seems appropriate:
...
diff --git a/gcc/regcprop.c b/gcc/regcprop.c
index 8c4f564..b42a4b7 100644
--- a/gcc/regcprop.c
+++ b/gcc/regcprop.c
@@ -801,6 +801,18 @@ copyprop_hardreg_forward_1 (basic_block bb, struct
value_data *vd)
I wouldn't think this were true for regular insns, but
scan_rtx treats them like that... */
note_stores (PATTERN (insn), kill_clobbered_value, vd);
+ if (CALL_P (insn))
+ {
+ rtx exp;
+ for (exp = CALL_INSN_FUNCTION_USAGE (insn);
+ exp;
+ exp = XEXP (exp, 1))
+ {
+ rtx x = XEXP (exp, 0);
+ if (GET_CODE (x) == CLOBBER)
+ kill_value (SET_DEST (x), vd);
+ }
+ }
/* Kill all auto-incremented values. */
/* ??? REG_INC is useless, since stack pushes aren't done that way. */
...
[Bug lto/64543] gcc fails to build due to undefined references to functions in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64543 --- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz --- Created attachment 34406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34406&action=edit failed build log
[Bug c++/64462] ICE while compiling lambda using local constexpr reference variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64462 --- Comment #2 from Paolo Carlini --- Thanks Ville. Let's add the testcase and close this.
[Bug c++/64462] ICE while compiling lambda using local constexpr reference variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64462 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jan 8 17:48:38 2015 New Revision: 219352 URL: https://gcc.gnu.org/viewcvs?rev=219352&root=gcc&view=rev Log: 2015-01-08 Paolo Carlini PR c++/64462 * g++.dg/cpp0x/constexpr-64462.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-64462.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/64462] ICE while compiling lambda using local constexpr reference variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64462 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini --- Done.
[Bug c++/59004] [4.8 Regression] ICE generated by __func__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59004 --- Comment #5 from Paolo Carlini --- At this point I think we can add the testcase to be safe and close the bug.
[Bug c++/59004] [4.8 Regression] ICE generated by __func__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59004 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jan 8 18:04:03 2015 New Revision: 219353 URL: https://gcc.gnu.org/viewcvs?rev=219353&root=gcc&view=rev Log: 2015-01-08 Paolo Carlini PR c++/59004 * g++.dg/ext/fnname4.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/fnname4.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/59004] [4.8 Regression] ICE generated by __func__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59004 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.8.5 |4.9.0 --- Comment #7 from Paolo Carlini --- Done.
[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681 --- Comment #7 from Joel Sherrill --- (In reply to Yaakov Selkowitz from comment #6) > (In reply to Mikael Pettersson from comment #5) > > The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with > > r210683. Backporting r210683 to current 4.9 branch is easy and fixes the > > ICE there too. I haven't checked c6x. > > r210683 fixes this particular issue in 4.9.2 for both bfin-elf and > tic6x-elf. (There is another, seemingly unrelated issue with the latter, > see bug 64451.) Any chance this could get into 4.9.3? r210683 was by Bernd Schmidt. I added him to this PR. Bernd... how about applying that fix to the 4.9 branch please so we can close this PR? Thanks.
[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681 --- Comment #8 from Joel Sherrill --- (In reply to Richard Biener from comment #1) > Did it work with 4.9.1? No. Based on "git checkout gcc-4_9_1-release" Ditto for 4.9.0. Hopefully the recommended patch can be applied to the 4.9 branch.
[Bug target/64338] [5 Regression] ICE in swap_condition, at jump.c:628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64338 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jan 8 19:15:53 2015 New Revision: 219356 URL: https://gcc.gnu.org/viewcvs?rev=219356&root=gcc&view=rev Log: PR target/64338 * config/i386/i386.c (ix86_expand_int_movcc): Don't reverse compare_code when it is unconditionally overwritten afterwards. Use ix86_reverse_condition instead of reverse_condition. Don't change code if *reverse_condition* returned UNKNOWN and don't swap ct/cf and negate diff in that case. * g++.dg/opt/pr64338.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr64338.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/64338] [5 Regression] ICE in swap_condition, at jump.c:628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64338 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug middle-end/64544] New: ../../gcc-svn/gcc/cgraphunit.c:2183:1: internal compiler error: in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64544 Bug ID: 64544 Summary: ../../gcc-svn/gcc/cgraphunit.c:2183:1: internal compiler error: in check_probability, at basic-block.h:581 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: mikulas at artax dot karlin.mff.cuni.cz Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu I got internal compiler error when building gcc 5 revision r219330. The distribution is Debian Wheezy x86-64. Build script: CFLAGS="-O3 -march=barcelona" export CFLAGS CXXFLAGS="$CFLAGS" export CXXFLAGS MAKEFLAGS=-j12 export MAKEFLAGS ../gcc-svn/configure\ --prefix=/usr/local/gcc-svn/\ --enable-lto\ --with-system-zlib \ --enable-languages=c\ --enable-multilib \ --with-multilib-list=m32,m64\ --disable-werror\ --enable-checking=yes \ && nice -n 20 make BOOT_CFLAGS="$CFLAGS" profiledbootstrap
[Bug middle-end/64544] ../../gcc-svn/gcc/cgraphunit.c:2183:1: internal compiler error: in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64544 mikulas at artax dot karlin.mff.cuni.cz changed: What|Removed |Added Severity|normal |major
[Bug middle-end/64544] ../../gcc-svn/gcc/cgraphunit.c:2183:1: internal compiler error: in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64544 --- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz --- Created attachment 34407 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34407&action=edit The failed build log
[Bug middle-end/64544] ../../gcc-svn/gcc/cgraphunit.c:2183:1: internal compiler error: in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64544 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Could be a dup of PR64326.
[Bug fortran/63733] [4.8/4.9/5 Regression] [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733 --- Comment #7 from janus at gcc dot gnu.org --- I think the proper fix should be to look for type-bound operators *before* non-type-bound operators in gfc_extend_expr (interface.c). In gfc_extend_assign this is already done in the right order (i.e. type-bound first).
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #11 from Michael Bruck --- (In reply to Olaf van der Spek from comment #10) > > I quoted it to illustrate that returning NULL is the intuitive option here, > > while abort() is a completely new approach. Returning NULL is what I would > > expect to be the case when -fno-exceptions is active and it is what happens > > in > > the libc++ implementation AFAIK. > > -fno-exceptions transforms throws into aborts in the STL. > Unfortunately it doesn't do that for other code but I've filed a > feature request for to fix that. > > Given this transformation aborting would be the natural consequence. > What does the GCC STL do? throwing is undefined behavior with -fno-exceptions. Allocation failure is a simple error and should not kill your program. > BTW, what's your use case? Do you really want to check NULL on every > call to new? With -fno-exceptions you have to check all functions for errors, including allocation.
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #12 from Olaf van der Spek --- On Thu, Jan 8, 2015 at 10:20 PM, bruck.michael at googlemail dot com wrote: > throwing is undefined behavior with -fno-exceptions. Says who? > Allocation failure is a > simple error and should not kill your program. It's far from simple to handle properly and to do better then abort. >> BTW, what's your use case? Do you really want to check NULL on every >> call to new? > > With -fno-exceptions you have to check all functions for errors, including > allocation. What's your use case?
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Thu Jan 8 21:29:44 2015 New Revision: 219361 URL: https://gcc.gnu.org/viewcvs?rev=219361&root=gcc&view=rev Log: PR target/55023 PR middle-end/64388 * dse.c (struct insn_info): Mention frame_read set also before reload for tail calls on some targets. (scan_insn): Revert 2014-12-22 change. Set frame_read also before reload for tail calls if HARD_FRAME_POINTER_IS_ARG_POINTER. Call add_wild_read instead of add_non_frame_wild_read for non-const/memset tail calls after reload. Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Jan 8 21:29:44 2015 New Revision: 219361 URL: https://gcc.gnu.org/viewcvs?rev=219361&root=gcc&view=rev Log: PR target/55023 PR middle-end/64388 * dse.c (struct insn_info): Mention frame_read set also before reload for tail calls on some targets. (scan_insn): Revert 2014-12-22 change. Set frame_read also before reload for tail calls if HARD_FRAME_POINTER_IS_ARG_POINTER. Call add_wild_read instead of add_non_frame_wild_read for non-const/memset tail calls after reload. Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c
[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 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jan 8 21:30:56 2015 New Revision: 219362 URL: https://gcc.gnu.org/viewcvs?rev=219362&root=gcc&view=rev Log: PR tree-optimization/63989 * params.def (PARAM_MAX_TRACKED_STRLENS): Increment default from 1000 to 1. * tree-ssa-strlen.c (get_strinfo): Moved earlier. (get_stridx): If we don't have a record for certain SSA_NAME, but it is POINTER_PLUS_EXPR of some SSA_NAME we do with constant offset, call get_stridx_plus_constant. (get_stridx_plus_constant): New function. (zero_length_string): Don't use get_stridx here. * gcc.dg/strlenopt-27.c: New test. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-27.c Modified: trunk/gcc/ChangeLog trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Should be fixed now.
[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 --- Comment #10 from Hans-Peter Nilsson --- Author: hp Date: Thu Jan 8 21:57:49 2015 New Revision: 219364 URL: https://gcc.gnu.org/viewcvs?rev=219364&root=gcc&view=rev Log: PR testsuite/62250 * lib/target-supports.exp (check_effective_target_libatomic_available): New. * gfortran.dg/coarray/caf.exp: Only add -latomic for targets that match effective-target libatomic_available. * gfortran.dg/coarray_lib_comm_1.f90: Similar. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray/caf.exp trunk/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 --- Comment #11 from Hans-Peter Nilsson --- Author: hp Date: Thu Jan 8 21:59:26 2015 New Revision: 219365 URL: https://gcc.gnu.org/viewcvs?rev=219365&root=gcc&view=rev Log: PR testsuite/62250 * lib/target-supports.exp (check_effective_target_libatomic_available): New. * gfortran.dg/coarray/caf.exp: Only add -latomic for targets that match effective-target libatomic_available. * gfortran.dg/coarray_lib_comm_1.f90: Similar. Modified: trunk/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
[Bug middle-end/64545] New: failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545 Bug ID: 64545 Summary: failed gcc build: internal compiler error: in inline_small_functions, at ipa-inline.c:1693 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: mikulas at artax dot karlin.mff.cuni.cz Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Created attachment 34408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34408&action=edit failed build log ICE when building gcc revision r219330 on Debian Wheezy. Build script: CFLAGS="-O2 -march=barcelona -fomit-frame-pointer" export CFLAGS CXXFLAGS="$CFLAGS" export CXXFLAGS MAKEFLAGS=-j12 export MAKEFLAGS ../gcc-svn/configure\ --prefix=/usr/local/gcc-svn/\ --enable-lto\ --with-system-zlib \ --enable-languages=c\ --enable-multilib \ --with-multilib-list=m32,m64\ --disable-werror\ --enable-checking=yes \ && nice -n 20 make BOOT_CFLAGS="$CFLAGS" profiledbootstrap
