[Bug tree-optimization/66233] [4.8/4.9 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 --- Comment #11 from Matthias Klose doko at gcc dot gnu.org --- the proposed patch fixes the test case from PR66554 on aarch64-linux-gnu.
[Bug middle-end/65686] [5/6 regression] inconsistent warning maybe-uninitialized: warn about 'unsigned', not warn about 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65686 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||13962 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Note that you are basically relying on optimization to remove the uninitialized load. Where does this obfuscated 'return *(e-pu)' come from? Related to PR13962 (to simplify the compare to false) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 [Bug 13962] [tree-ssa] make fold use alias information to optimize pointer comparisons
[Bug middle-end/66587] New: -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587 Bug ID: 66587 Summary: -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- As the summary states, you will get bitten by bug 41260 if you happen to specify -nodefaultlibs or -nostdlib as -no_compact_unwind is pulled in via %(link_gcc_c_sequence), which in turn is conditional on those first to flags. The comment in the code states that -no_compact_unwind is needed because of problems with libSystem. In that case it would make sense to tie it to where libSystem gets pulled in. However, reading bug 41260 and related links, I interpret things as being a problem in Apple's ld. Hence the flag should always be used as that linker is always assumed. I'm not sure what the best approach is to do that. I'm planning on trying to move it from LINK_GCC_C_SEQUENCE_SPEC to LINK_SPEC. (The same thing might affect the -no_pie magic, but I haven't found the justification for that code)
[Bug middle-end/66588] New: combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
Bug ID: 66588
Summary: combine should try transforming if_then_else of
zero_extends into zero_extend of if_then_else
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
Consider the code:
unsigned long
foo (unsigned int a, unsigned int b, unsigned int c)
{
return a ? b : c;
}
On aarch64 this generates:
foo:
uxtwx1, w1
cmp w0, wzr
uxtwx2, w2
cselx0, x2, x1, eq
ret
where in fact it could generate:
cmp w0, #0
cselw0, w1, w2, ne
ret
A write to the 32-bit w-register implicitly zero-extends the value up to the
full
64 bits of an x-register.
This is reflected in aarch64.md by the cmovsi_insn_uxtw pattern that matches:
(set (dest:DI)
(zero_extend:DI
(if_then_else:SI (cond) (src1:SI) (src2:SI))
)
)
However, this doesn't get matched because combine instead tries to match
(set (dest:DI)
(if_then_else:DI (cond)
(zero_extend:DI (src1:SI))
(zero_extend:DI (src2:SI))
)
)
If I change the pattern to the second form then I get the desired codegen.
However, it seems that combine should really be trying that transformation by
itself.
[Bug c++/66586] Template backtrace is truncated/absent after 'template argument deduction/substitution failed:'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66586 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I've seen this many times but never distilled it down. Thanks for the testcase.
[Bug middle-end/66253] [6 Regression] 459.GemsFDTD in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66253 --- Comment #8 from Michael Matz matz at gcc dot gnu.org --- Author: matz Date: Thu Jun 18 13:31:17 2015 New Revision: 224605 URL: https://gcc.gnu.org/viewcvs?rev=224605root=gccview=rev Log: PR middle-end/66253 * tree-vect-stmts.c (vectorizable_store): Implement non-SLP grouped strided stores. (vectorizable_load): Don't use the DR from first_stmt in the non-SLP grouped strided case. testsuite/ * gcc.dg/vect/pr66253.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr66253.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug middle-end/65686] [5/6 regression] inconsistent warning maybe-uninitialized: warn about 'unsigned', not warn about 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65686
--- Comment #6 from Dmitry G. Dyachenko dimhen at gmail dot com ---
(In reply to Richard Biener from comment #5)
Where does this obfuscated 'return *(e-pu)' come from?
If I remove aggregate then there are no warning.
i.e. this code produce no warning
mytype f(mytype *pu)
{
mytype x;
if(x != pu)
__builtin_memcpy(x, pu, sizeof(unsigned));
return x;
}
[Bug c++/66586] New: Template backtrace is truncated/absent after 'template argument deduction/substitution failed:'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66586
Bug ID: 66586
Summary: Template backtrace is truncated/absent after 'template
argument deduction/substitution failed:'
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Created attachment 35801
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35801action=edit
Minimal testcase
I've noticed that sometimes GCC presents e.g.
main.cpp:8:25: note: template argument deduction/substitution failed:
but then entirely omits the template instantiation backtrace. I've had a hard
time reproducing it so far but I finally found an example. Also happens with
4.9.2. Unrolling the result template alias by hand into the return type of foo
produces the expected behaviour, with a backtrace pointing to the mistake.
$ g++-trunk --version
g++-trunk (GCC) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat main.cpp
templatetypename
struct trivial { using type = int; };
templatetypename... Xs
using result = typename trivialXs...::type;
templatetypename... Xs
constexpr resultXs... foo(Xs...)
{ return 0; }
int main()
{
foo(0, 0);
}
$ g++-trunk -std=c++11 main.cpp
main.cpp: In function 'int main()':
main.cpp:13:13: error: no matching function for call to 'foo(int, int)'
foo(0, 0);
^
main.cpp:8:25: note: candidate: templateclass ... Xs constexpr resultXs ...
foo(Xs ...)
constexpr resultXs... foo(Xs...)
^
main.cpp:8:25: note: template argument deduction/substitution failed:
$ #prompt resumes here!
[Bug middle-end/56917] -ftrapv detects a overflow wrongly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56917
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
This also fixed a rejects-valid
int lValue;
int main()
{
switch (lValue)
{
case -(int)((2U (8 * sizeof(int) - 2)) - 1) - 1:;
}
}
g++-4.8 cMinLongValue.ii
cMinLongValue.ii: In function ‘int main()’:
cMinLongValue.ii:6:54: error: overflow in constant expression [-fpermissive]
case -(int)((2U (8 * sizeof(int) - 2)) - 1) - 1:;
^
cMinLongValue.ii:6:54: error: overflow in constant expression [-fpermissive]
I am going to backport and add this testcase.
[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Alexander Monakov from comment #2)
In that case I'd like to contribute a documentation patch to make that clear
in the pure/const attribute information, but I need more explanation. I see
that
int p(void) __attribute__((const));
void f()
{
p();
p();
}
is optimized to an empty function, even though p may throw. Is that not a
bug?
I would say so. But this has quite some implementation issues, also with...
Also, could you please expand your explanation in the first paragraph, i.e.
this:
What we miss here is the fact that it should only matter
if p throws internally for IL consistency. Of course it
still matters for observing other side-effects if p throws
and after the transform now does so before side-effects
that should be observed otherwise.
I'm probably missing a lot of contextual knowledge to understand that. TIA.
... this, the side-effect ordering of stores and the throwing p() call is
not properly represented.
[Bug tree-optimization/66233] [4.8/4.9 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- BTW: x86_64 is missing any form of zero-extended cmove.
[Bug middle-end/56917] -ftrapv detects a overflow wrongly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56917 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jun 18 14:47:18 2015 New Revision: 224617 URL: https://gcc.gnu.org/viewcvs?rev=224617root=gccview=rev Log: 2015-06-18 Richard Biener rguent...@suse.de Backport from mainline 2014-12-04 Marek Polacek pola...@redhat.com PR middle-end/56917 * fold-const.c (fold_unary_loc): Perform the negation in A's type when transforming ~ (A - 1) or ~ (A + -1) to -A. * g++.dg/other/const4.C: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/other/const4.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/fold-const.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/65966] [5/6 Regression] [C++14] sorry, unimplemented: unexpected AST of kind try_block when initializing a 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed. *** This bug has been marked as a duplicate of bug 66001 ***
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 66001, which changed state. Bug 66001 Summary: [5/6 regression] ICE when NSDMI in a literal class uses a destructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 65966, which changed state. Bug 65966 Summary: [5/6 Regression] [C++14] sorry, unimplemented: unexpected AST of kind try_block when initializing a 2D array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/66001] [5/6 regression] ICE when NSDMI in a literal class uses a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/66001] [5/6 regression] ICE when NSDMI in a literal class uses a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||lhyatt at gmail dot com --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- *** Bug 65966 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/66233] [4.8/4.9 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Jun 18 14:06:04 2015 New Revision: 224611 URL: https://gcc.gnu.org/viewcvs?rev=224611root=gccview=rev Log: PR tree-optimization/66233 * fold-const.c (fold_unary_loc): Don't handle vector types. Simplify. * tree-ssa-forwprop.c (combine_conversions): Likewise. * gcc.c-torture/execute/pr66233.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr66233.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/fold-const.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-forwprop.c
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-18 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- What would you like us to document exactly? How are we supposed to track the evolution of ICC over time? Why not simply ask ICC to change its heuristics?
[Bug middle-end/66587] -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587 --- Comment #2 from Pierre Ossman ossman at cendio dot se --- Note that darwin12.h also exists on trunk that needs to be modified as well.
[Bug middle-end/66587] -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587 --- Comment #1 from Pierre Ossman ossman at cendio dot se --- Created attachment 35802 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35802action=edit possible patch
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- More than that, documenting gcc's branch heuristics is just in the code. And you can see it what gcc figures out via debug dumps. It is also harder to document this due to different things. For an example if your case 2 contained a call to call function, it would change gcc's choices too.
[Bug c++/66001] [5/6 regression] ICE when NSDMI in a literal class uses a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Jun 18 14:55:23 2015 New Revision: 224620 URL: https://gcc.gnu.org/viewcvs?rev=224620root=gccview=rev Log: PR c++/66001 * constexpr.c (cxx_eval_constant_expression): Handle TRY_BLOCK and TRY_FINALLY_EXPR. (potential_constant_expression_1): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/66001] [5/6 regression] ICE when NSDMI in a literal class uses a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Jun 18 14:55:45 2015 New Revision: 224621 URL: https://gcc.gnu.org/viewcvs?rev=224621root=gccview=rev Log: PR c++/66001 * constexpr.c (cxx_eval_constant_expression): Handle TRY_BLOCK and TRY_FINALLY_EXPR. (potential_constant_expression_1): Likewise. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/nsdmi12.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 Jason McG jmcguiness at liquidcapital dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #5 from Jason McG jmcguiness at liquidcapital dot com --- (In reply to Andrew Pinski from comment #3) More than that, documenting gcc's branch heuristics is just in the code. And ... I am sorry, but I do not agree. As per my other reply, in comment 4, I think it is entirely reasonable to request that an additional statement along the lines of code generation for switch statements may not follow a top-down approach nor prefer the default case (if it exists) in terms of static branch-prediction. The __builtin_expected() intrinsic has no effect is included in the web-based documentation in a suitable sub-section. If some algorithm were used, then adding a link to the web site to the appropriate paper might be a quick remedy? This would ensure that developers are not mislead by the argument that __builtin_expected() takes thinking they could use that, nor would they be mislead by lore assuming that the default or a lexographic top-down approach to static branch-prediction were used.
[Bug middle-end/66565] Problems and limitation GCC cost metrics and ways to improve the situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66565 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-18 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The proliferation and misunderstanding of cost units is a side effect of this. So we really have to move to something like: target_should_inline_call (interesting call information from the pass) target_should_ifconvert (gimple sequences for before/after transformation) target_combine_is_profitable_p (before, after rtx) target_should_reconstruct_value_p (candidate RTX to either build and keep in registers or reconstruct in loop) target_choose_preferred_addressing_mode (list of candidate addressing modes for a MEM) So basically one hook per transformation? And each back-end will have to factorize the common processing? Where we ask specific and meaningful questions of the target, rather than asking for a guess at costs and using that. The difficult argument to make will be that we have to be radical about this and prepared to regress many targets (in the short term) for the sake of ending up with a maintainable and understandable design for making these decisions. We simply cannot do that, there are ~50 architectures in the compilers and this will break them all except for a handful of them. Generally speaking, you cannot reimplement things from scratch in a 25 years old production compiler, you will break far more things than you will ever be able to fix or improve. Either you implement the new scheme in addition to the old one or you fix the old one incrementally, that's pretty much the only practical alternative.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #4 from vehre at gcc dot gnu.org ---
Further analysis showed that while the offset of source's temporary descriptor
parm.3 is not as expected:
// allocate(c, source=a(:))
// lb, ub,, offset, data
parm.3 = {1, ub(a)+1, 0, a[0]} // offset should be -1, when lb is set to
1.
c is initialized like this:
c = { parm.3.lb, parm.3.ub, -parm.3.lb, malloc( ((parm.3.ub - parm.3.lb) + 1) *
sizeof(int)) }
the loop to copy the data from a, aka parm.3.data, is this (simplified to
show the mistake more clearly):
for (i= 0; i = c.ub; ++i)
c.data[i + c.lb + c.offset] = parm.3.data[i + parm.3.offset]
The issue is that the loop is iterating over c.ub + 1 elements. It should
either be starting at 1 or stop at i c.ub. Unfortunately is this computed by
the scalarizer, which I just don't understand. I assume, that having the offset
of parm.3 set correctly and the from setting of the loop to be 1 should resolve
the issue reliably.
Any thoughts?
[Bug tree-optimization/66233] [4.8/4.9 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Jun 18 14:03:50 2015 New Revision: 224609 URL: https://gcc.gnu.org/viewcvs?rev=224609root=gccview=rev Log: PR tree-optimization/66233 * fold-const.c (fold_unary_loc): Don't handle vector types. Simplify. * tree-ssa-forwprop.c (combine_conversions): Likewise. * gcc.c-torture/execute/pr66233.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr66233.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-forwprop.c
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jun 18 14:04:05 2015 New Revision: 224610 URL: https://gcc.gnu.org/viewcvs?rev=224610root=gccview=rev Log: 2015-06-18 Richard Biener rguent...@suse.de Backport from mainline 2015-06-03 Richard Biener rguent...@suse.de PR tree-optimization/66375 * tree-scalar-evolution.c (follow_ssa_edge_binary): First add to the evolution before following SSA edges. * gcc.dg/torture/pr66375.c: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr66375.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-scalar-evolution.c
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 --- Comment #4 from Jason McG jmcguiness at liquidcapital dot com --- (In reply to Eric Botcazou from comment #2) What would you like us to document exactly? How are we supposed to track ... Perhaps I was unclear. I am asking that you point out to me in the gcc documentation where it comments regarding code generation for switch-statements, and that it might make clear that the lexographic top-down approach nor the default label are preferred but other, more complex heuristics are used that defeat static branch-prediction analysis. I do not think this is unreasonable. So I disagree entirely that this is invalid.
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- If someone cares so much about the static branch predictor, they would be a compiler developer. This is the first time I have seen a non-compiler developer care about documenting gcc heuristics. Note there is no one paper. Also if branches are 50/50, the decision can change based on adding another statement and is hard to document otherwise.
[Bug c++/66583] incorrect implicitly-defined move constructor for class with anonymous union and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66583 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The problem seems to exists for the current head gcc HEAD 6.0.0 20150617 (experimental) as well.
[Bug target/65914] [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 --- Comment #4 from Bill Schmidt wschmidt at gcc dot gnu.org --- With the smaller test, at least, this did not reproduce for me with r223868. Patching up to latest and will try again.
[Bug target/65914] [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914
--- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org ---
The tree-optimized dump shows:
void foo() ()
{
vector(2) long unsigned int vect_cst_.60;
vector(2) long unsigned int vect_cst_.59;
vector(2) long unsigned int vect_cst_.58;
struct A p1;
const struct A D.3509;
int p1;
int p1;
const struct A D.3508;
struct A p1;
struct expression D.3507;
long unsigned int _5;
long unsigned int _6;
long unsigned int _8;
long unsigned int _11;
long unsigned int _18;
long unsigned int _19;
bb 2:
_18 = (long unsigned int) p1;
_19 = (long unsigned int) p1;
vect_cst_.60_20 = {_19, _18};
_6 = (long unsigned int) D.3509;
_5 = (long unsigned int) p1;
vect_cst_.59_17 = {_5, _6};
_11 = (long unsigned int) D.3508;
_8 = (long unsigned int) p1;
vect_cst_.58_7 = {_8, _11};
D.3509 ={v} {CLOBBER};
D.3508 ={v} {CLOBBER};
MEM[(struct )D.3507] ={v} {CLOBBER};
MEM[(const struct A *)D.3507] = vect_cst_.60_20;
MEM[(const struct A *)D.3507 + 16B] = vect_cst_.59_17;
MEM[(const struct A *)D.3507 + 32B] = vect_cst_.58_7;
operator/int, Aint, expressionint, expressionint, int, expressionint,
A\
int, Aint, void, void, void, void, expressionint, int, Aint, void,
voi\
d, void, void, void, void, double (D.3507,
1.555111512312578\
27021181583404541015625e-1);
return;
}
The problem is that the POWER port doesn't appear to have a pattern to match
the vector constructors like:
vect_cst_.60_20 = {_19, _18};
The translation into rtl is a (vec_concat:V2DI (reg:DI) (reg:DI)). The closest
thing we have to matching this is vsx_concat_mode in vsx.md, but IIUC this
will only match (vec_concat:V2DF (reg:DF) (reg:DF)) because of the
vsx_register_operand restriction. Mike Meissner, can you please confirm?
[Bug c++/66585] [5/6 Regression] Internal compiler error when initialize field with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66585 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/61856] Ternary operator in an NSDMI causes double evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61856 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- It seems that this bug was fixed in r224533 (PR58063).
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org --- What I currently do not understand is why allocate(c,source=a(:)) fails and c = a(:) works. And yes, the scalarizer is pretty incomprehensible.
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 --- Comment #8 from Jason McG jmcguiness at liquidcapital dot com --- (In reply to Andrew Pinski from comment #6) ... compiler developer. This is the first time I have seen a non-compiler developer care about documenting gcc heuristics. Note there is no one paper. ... See comment 5. The documentation I am proposing is pretty trivial, I repeat: code generation for switch statements may not follow a top-down approach nor prefer the default case (if it exists) in terms of static branch-prediction. The __builtin_expected() intrinsic has no effect. I find it had to understand how that documentation could be considered contentious.
[Bug c++/66061] [5/6 Regression] Internal Compiler Error when specializing a variable template when the specialization is variadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Yes, this was fixed by r223304 on trunk, r223311 on the branch. I'll add the testcase.
[Bug target/65914] [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 --- Comment #5 from Bill Schmidt wschmidt at gcc dot gnu.org --- Confirmed with r224625, however.
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 --- Comment #7 from Jason McG jmcguiness at liquidcapital dot com --- (In reply to Andrew Pinski from comment #6) If someone cares so much about the static branch predictor, they would be a ... I am not a compiler developer and I do care about this in the code I work upon. I occasionally have switch statements that I statically know have a more commonly used case label (e.g. could be made the default) that static branch-prediction would reduce the cost of calling. It would have saved me some time if the documentation I was requesting were present in a more accessible form that writing test code reviewing the assembler that gcc generates. Aside: I have read https://ols.fedoraproject.org/GCC/Reprints-2008/sayle-reprint.pdf and no-where does this article describe, apart from in passing, the effect of mis-predicted branches that using static branch-prediction could avoid by clearly implementing a preferred branch e.g. the default upon their cost models. If I had time I'd research this, unfortunately I do not.
[Bug c++/66515] [5/6 Regression] g++ segfaults when creating an std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66515 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/66590] switch statement: incorrect warning reaches end of non-void function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Related to bug 20681. Most likely block_may_fallthru is returning true for the
{} block.
[Bug tree-optimization/66592] [Regression] ICE in vect_get_def_for_operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592 --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 35805 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35805action=edit Fortran code that exhibits the problem
[Bug tree-optimization/66592] [Regression] ICE in vect_get_def_for_operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592 --- Comment #1 from kargl at gcc dot gnu.org --- This bug appears to be regression and it requires the -O2 and -ftree-vectorize options. gfortran -c -O2 -ftree-vectorize z.f z.f:1:0: subroutine calsvp(nkr,nkz) ^ internal compiler error: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1478 0xd6a2a9 vect_get_vec_def_for_operand(tree_node*, gimple_statement_base*, tree_node**) ../../gcc6/gcc/tree-vect-stmts.c:1478 0xd72a0d vectorizable_store ../../gcc6/gcc/tree-vect-stmts.c:5330 0xd7d6a6 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) ../../gcc6/gcc/tree-vect-stmts.c:7496 0xd9a541 vect_schedule_slp_instance ../../gcc6/gcc/tree-vect-slp.c:3481 0xd9ab16 vect_schedule_slp(_loop_vec_info*, _bb_vec_info*) ../../gcc6/gcc/tree-vect-slp.c:3551 0xd82c17 vect_transform_loop(_loop_vec_info*) ../../gcc6/gcc/tree-vect-loop.c:6218 0xda0792 vectorize_loops() ../../gcc6/gcc/tree-vectorizer.c:495 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 driver/66593] New: driver-i386.c: -mtune=native unavailable with non-bootstrapped build of libgccjit with gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66593 Bug ID: 66593 Summary: driver-i386.c: -mtune=native unavailable with non-bootstrapped build of libgccjit with gcc 5 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org CC: uros at gcc dot gnu.org Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Currently libgccjit uses -mtune=generic; I'm working on enabling -mtune=native for libgccjit. However, on i386/x86_64 with a non-bootstrap build using gcc 5, host_detect_local_cpu does nothing. This is due to: commit b587c12551143c14f023860a1dbdf7316ae71f27 Author: uros uros@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Oct 17 06:00:58 2014 + * config/i386/cpuid.h (__cpuid): Remove definitions that handle %ebx register in a special way. (__cpuid_count): Ditto. * config/i386/driver-i386.h: Protect with #if defined(__GNUC__) (__GNUC__ = 5 || !defined(__PIC__)). (host_detect_local_cpu): Mention that GCC with non-fixed %ebx is required to compile the function. Uros said (in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01516.html): The only drawback would be that non-bootstrapped build with gcc 5.0 will ignore -march=native, but I think this should be acceptable. Jakub said (in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01520.html): At least on Linux, driver-i386.c should not be built with PIC normally, so at least changing #if __GNUC__ = 5 to #if defined(__GNUC__) (__GNUC__ = 5 || !defined(__PIC__)) would limit the -march=native change for non-bootstrapped compilers to Darwin only (or what other targets use PIC by default?). The jit builds with PIC, and -mtune=native would be highly appropriate for jitted-code; so this is a somewhat bigger deal. Currently the instructions for building libgccjit recommend --disable-bootstrap, so everyone following those on i386/x86_64 with gcc 5 as the system compiler is going to get a hobbled -mtune=native. That said, the above code runs inside the driver, and libgccjit doesn't yet run that part of the driver, so some extra work will be needed by me on top of this before we can get it to do better than -mtune=generic.
[Bug target/66593] driver-i386.c: -mtune=native unavailable with non-bootstrapped build of libgccjit with gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66593 --- Comment #1 from David Malcolm dmalcolm at gcc dot gnu.org --- (In reply to David Malcolm from comment #0) [...] That said, the above code runs inside the driver, and libgccjit doesn't yet run that part of the driver, so some extra work will be needed by me on top of this before we can get it to do better than -mtune=generic. I filed bug 66594 against the jit component to track that.
[Bug c++/66595] New: [C++14] ICE in partial specialization template variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66595
Bug ID: 66595
Summary: [C++14] ICE in partial specialization template
variables
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
The code below
templatetypename T int typeID{42};
templatetypename T double typeIDdouble{10.10};
int main() {}
produces an internal compiler error
internal compiler error: in type_dependent_expression_p, at cp/pt.c:21431
in both g++5.1 and in HEAD
It should not compile, as the partial specialization doesn't use any of the
template arguments.
[Bug tree-optimization/66592] New: [Regression] ICE in vect_get_def_for_operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592 Bug ID: 66592 Summary: [Regression] ICE in vect_get_def_for_operand Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: ---
[Bug tree-optimization/66592] [Regression] ICE in vect_get_def_for_operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592 --- Comment #3 from kargl at gcc dot gnu.org --- I forgot to mention in comment 1 that the COMMON statement in the Fortran is also required.
[Bug jit/66594] New: jitted code should use -mtune=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
Bug ID: 66594
Summary: jitted code should use -mtune=native
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
We should probably default to -mtune=native when building code in-memory (but
probably to -mtune=generic when compiling to disk?). Perhaps an option, or
maybe expose these options directly?
Note to self:
* I see in gcc.c:
/* As special support for cross compilers we read -mtune=native
as -mtune=generic. With native compilers we won't see the
-mtune=native, as it was changed by the driver. */
if (!strcmp (opts-x_ix86_tune_string, native))
{
opts-x_ix86_tune_string = generic;
}
hence we need to somehow run the *driver* logic for -mtune=native.
Note that that logic can be a no-op under non-bootstrapped builds; see bug
66593.
[Bug jit/66594] jitted code should use -mtune=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This should be true on all targets which have -mcpu=native (or -march=native). Note x86 options are not always the same on x86 vs arm vs aarch64 vs ppc.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to vehre from comment #4) Any thoughts? Don't care about the scalarizer; generate a correct descriptor to begin with, and the scalarizer will follow (hopefully).
[Bug target/62308] A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
--- Comment #13 from Christophe Lyon clyon at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #12)
However, I am probably missing something since with an updated 4.9-branch
and without this patch, I couldn't make the compiler crash:
$ aarch64-unknown-linux-gnu-gcc -S test.c -mbig-endian
test.c:2:15: error: expected specifier-qualifier-list before ‘v4si’
struct S2823 {v4si a;int b[0];};
Not sure what was wrong with my previous build
I now managed to reproduce it on the 4.9-branch (r224544).
With the patch applied, the ICE disappears as expected.
Bootstrapped on x86_64 and aarch64, make check shows no regression.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 --- Comment #6 from vehre at gcc dot gnu.org --- c= a(:) works because there is no additional array descriptor inbetween. The (new) allocate gets its own temporary array descriptor for the source= expression, which in turn has incorrect bounds in it. The arrayspec is an AS_DEFERRED which is then used to generate the temporary array descriptor and defaults to a lower bound of zero, where all the miserable things begin with.
[Bug c/66589] New: AVX instruction set extension is not enabled by default for bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66589 Bug ID: 66589 Summary: AVX instruction set extension is not enabled by default for bdver2 Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: joseph.kogut at gmail dot com Target Milestone: --- gcc -march=bdver2 -Q --help=target reports: -mavx [disabled] When the extension is supported by the microarchitecture.
[Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Perhaps I was unclear. I am asking that you point out to me in the gcc documentation where it comments regarding code generation for switch-statements, and that it might make clear that the lexographic top-down approach nor the default label are preferred but other, more complex heuristics are used that defeat static branch-prediction analysis. I do not think this is unreasonable. I see, but documenting the code generation strategy in the user documentation is not really appropriate, it is subject to change without notice and the doc could be quickly out of sync. Moreover, it would be a slippery slope: if we start to document this case and not the dozens of others, users would either ask for the others or draw false conclusions from their absence. So WONTFIX seems to be the best resolution here.
[Bug target/66589] AVX instruction set extension is not enabled by default for bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66589
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
It is enabled:
{bdver2, PROCESSOR_BDVER2, CPU_BDVER2,
PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
| PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
| PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4
| PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
| PTA_FMA | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
[Bug c++/66590] New: switch statement: incorrect warning reaches end of non-void function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590 Bug ID: 66590 Summary: switch statement: incorrect warning reaches end of non-void function Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brutus at free dot fr Target Milestone: --- Created attachment 35803 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35803action=edit code snippet generated erroneous end of non-void function warning If the attached code is compiled with -Wall, gcc versions 4.9.2, 5.1 and others incorrectly warn about reaching end of non-void function. this is typically reproduced with: /opt/install/gcc-4.9.2/bin/g++ -Wall -c switch.cpp warning disappears if: -optimisation is at least -O1 -OR declaration of ~A() line 1 is removed -OR declaration of variable a line 6 is removed -OR declaration of variable tmp line 9 is removed -OR break on line 9 is removed
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #8 from Mikael Morin mikael at gcc dot gnu.org ---
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index fece3ab..0b96de1 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7079,7 +7077,7 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
{
tmp = gfc_conv_array_lbound (desc, n);
tmp = fold_build2_loc (input_location, MINUS_EXPR,
-TREE_TYPE (base), tmp, loop.from[dim]);
+TREE_TYPE (base), tmp, from);
tmp = fold_build2_loc (input_location, MULT_EXPR,
TREE_TYPE (base), tmp,
gfc_conv_array_stride (desc, n));
[Bug rtl-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
Martin Sebor msebor at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Component|c++ |rtl-optimization
--- Comment #3 from Martin Sebor msebor at gcc dot gnu.org ---
Since this isn't C++ specific but rather a doing of the RTL optimizer I changed
the component to rtl-optimization.
On powerpc64, which historically has implemented the same static branch
prediction strategy, and where IBM XLC emits the same code as Clang, GCC emits
the following at -O1:
foo:
...
cmpdi 7,3,0
beq 7,.L2
bl bar1
...
b .L1
.L2:
bl bar2
...
.L1:
...
blr
while the following at -O2:
foo:
...
cmpdi 7,3,0
...
bne 7,.L6
bl bar2
...
blr
.L6:
bl bar1
...
blr
Comparing the RTL dumps between -O1 and -O2 it looks like the change is
introduced in the basic block reordering (bbro) pass that only runs at -O2.
There, the if_then_else eq instruction
(jump_insn 7 6 8 2 (set (pc)
(if_then_else (eq (reg:CC 75 7 [156])
(const_int 0 [0]))
(label_ref 12)
(pc))) t.c:5 693 {*rs6000.md:12637}
(expr_list:REG_DEAD (reg:CC 75 7 [156])
(int_list:REG_BR_PROB 6100 (nil)))
- 12)
...
(call_insn 14 13 17 3 (parallel [
(call (mem:SI (symbol_ref:DI (bar2) [flags 0x41] function_decl
0x3fff84018c10 bar2) [0 bar2 S4 A8])
is replaced with
(jump_insn 7 6 13 2 (set (pc)
(if_then_else (ne (reg:CC 75 7 [156])
(const_int 0 [0]))
(label_ref:DI 53)
(pc))) t.c:5 693 {*rs6000.md:12637}
(expr_list:REG_DEAD (reg:CC 75 7 [156])
(int_list:REG_BR_PROB 3900 (nil)))
- 53)
...
(call_insn 14 13 34 3 (parallel [
(call (mem:SI (symbol_ref:DI (bar2) [flags 0x41] function_decl
0x3fff84018c10 bar2) [0 bar2 S4 A8])
I would expect this to then be corrected if necessary according to the
processor's static branch prediction strategy but it clearly doesn't happen for
powerpc64 or apparently x86_64.
[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #1) BTW: x86_64 is missing any form of zero-extended cmove. ... please see [1] how x86_64 implements it (*movsicc_noc_zext). [1] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01306.html
[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|tree-optimization --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- REG_BR_PROB 6100 (nil) This is the issue.
[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66464 --- Comment #6 from Leo Carreon lcarreon at bigpond dot net.au --- Has this fix been included in the recent gcc-5.1.1-3 update on Fedora 22?
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #9 from James Almer jamrial at gmail dot com --- Created attachment 35804 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35804action=edit Preprocessed code where a test instruction is still generated Please look at the attachment. [jamrial@archVM ~]$ gcc -std=c99 -march=haswell -O3 -c hevc_ps.i [jamrial@archVM ~]$ objdump --disassemble hevc_ps.o | grep -B2 -A2 bzhi 5854: c4 62 22 f7 d6 sarx %r11d,%esi,%r10d 5859: c4 62 22 f7 da sarx %r11d,%edx,%r11d 585e: c4 e2 70 f5 f6 bzhi %ecx,%esi,%esi 5863: 45 89 9e 68 33 00 00mov%r11d,0x3368(%r14) 586a: 41 89 c3mov%eax,%r11d -- 589d: 85 f6 test %esi,%esi 589f: 75 0d jne58ae ff_hevc_decode_nal_sps+0x1a6e 58a1: c4 e2 70 f5 d2 bzhi %ecx,%edx,%edx 58a6: 85 d2 test %edx,%edx 58a8: 0f 84 5a 03 00 00 je 5c08 ff_hevc_decode_nal_sps+0x1dc8 [jamrial@archVM ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local --libdir=/usr/local/lib --libexecdir=/usr/local/lib --mandir=/usr/local/share/man --infodir=/usr/local/share/info --enable-languages=c,c++,lto --enable-shared --disable-bootstrap --enable-threads=posix --enable-libmpx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror Thread model: posix gcc version 6.0.0 20150618 (experimental) (GCC) Not sure why the new model is not working here.
[Bug tree-optimization/64130] vrp: handle non zero constant divided by range cannot be zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
--- Comment #5 from kugan at gcc dot gnu.org ---
I think it should be in from front-end?
Tried fixing it in VRP like:
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -9943,12 +9943,43 @@ simplify_stmt_using_ranges (gimple_stmt_iterator *gsi)
{
enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
tree rhs1 = gimple_assign_rhs1 (stmt);
+ tree rhs2 = gimple_assign_rhs2 (stmt);
switch (rhs_code)
{
case EQ_EXPR:
case NE_EXPR:
- /* Transform EQ_EXPR, NE_EXPR into BIT_XOR_EXPR or identity
+
+ /* PR64130. If there is a statement (integer_cst / var == 0) and
+integer_cst = TYPE_MAX (TREE_TYPE (var))
+then (integer_cst / var) cannot be 0. Hence this condition will
+be always false. */
+ if (rhs_code == EQ_EXPR
+ TREE_CODE (rhs1) == SSA_NAME
+ integer_zerop (rhs2))
+ {
+ gimple g = SSA_NAME_DEF_STMT (rhs1);
+
+ if (is_gimple_assign (g)
+ INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (g)))
+ TREE_CODE (gimple_assign_rhs1 (g)) == INTEGER_CST
+ TREE_CODE (gimple_assign_rhs2 (g)) == SSA_NAME
+ gimple_assign_rhs_code (g) == TRUNC_DIV_EXPR)
+ {
+ tree r1 = gimple_assign_rhs1 (g);
+ tree r2 = gimple_assign_rhs2 (g);
+ tree max = TYPE_MAX_VALUE (TREE_TYPE (r2));
+ if (compare_values (r1, max) == -1
+ || compare_values (r1, max) == 0)
+ {
+ gimple_assign_set_rhs_with_ops (gsi, NOP_EXPR, rhs2);
+ update_stmt (stmt);
+ return true;
+ }
+ }
+ }
+
+ /* Transform EQ_EXPR, NE_EXPR into BIT_XOR_EXPR or identity
if the RHS is zero or one, and the LHS are known to be boolean
values. */
if (INTEGRAL_TYPE_P (TREE_TYPE (rhs1)))
But by the time we are in VRP, variable a is already promoted to that fits
the constant.
[Bug target/66591] New: [SH] ICE: in get_reload_reg, at lra-constraints.c:633 with -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66591
Bug ID: 66591
Summary: [SH] ICE: in get_reload_reg, at lra-constraints.c:633
with -mlra
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kkojima at gcc dot gnu.org
CC: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
When I tried to build trunk with cross SH trunk compiler, I've got
tree-ssa-math-opts.c:1030:1: internal compiler error: in get_reload_reg, at
lra-constraints.c:633
Here is a reduced test case
static const unsigned char table[8] = { 0, 1, 1, 2, 2, 3, 3, 4, };
int
foo (long long n)
{
if (n n 8)
foo (table[n]);
return 0;
}
The problem starts when LRA tries to reload the insn
(insn 23 22 24 5 (set (reg:QI 181)
(mem/u/j:QI (plus:SI (reg/f:SI 179)
(subreg:SI (reg/v:DI 168 [ n ]) 0)) [0 table S1 A8])) rel.cc:7
271 {*movqi}
(expr_list:REG_DEAD (reg/f:SI 179)
(expr_list:REG_DEAD (reg/v:DI 168 [ n ])
(nil
.reload says
Creating newreg=189 from oldreg=168, assigning class R0_REGS to address
r189
Creating newreg=190 from oldreg=189, assigning class R0_REGS to address
r190
Creating newreg=191 from oldreg=190, assigning class R0_REGS to address
r191
...
Creating newreg=279 from oldreg=278, assigning class R0_REGS to address
r279
which shows that something loops.
It looks that LRA tries to find DImode R0_REGS hardware register for
reg 168 and fails to do so because R1 is allocated already in the above
test case unfortuantely. So LRA gives another DImode newreg for it
and tries again. Thus it drops into the loop.
This won't happen on other targets which have enough index registers
and looks to be very rare even on SH in the actual codes. I think that
pre-allocating R0 is enough for that issue ATM. It would be a yet another
issue that is appropriate for R0-preallocating pass.
Now I'm testing the patch below.
diff --git a/config/sh/sh.c b/config/sh/sh.c
index 8fc8197..af8727e 100644
--- a/config/sh/sh.c
+++ b/config/sh/sh.c
@@ -1780,7 +1780,6 @@ prepare_move_operands (rtx operands[], machine_mode mode)
win on avarage for LRA. */
else if (sh_lra_p ()
TARGET_SH1 ! TARGET_SH2A
- (mode == QImode || mode == HImode)
((REG_P (operands[0]) MEM_P (operands[1]))
|| (REG_P (operands[1]) MEM_P (operands[0]
{
@@ -1788,7 +1787,8 @@ prepare_move_operands (rtx operands[], machine_mode mode)
rtx reg = operands[load_p ? 0 : 1];
rtx adr = XEXP (operands[load_p ? 1 : 0], 0);
- if (REGNO (reg) = FIRST_PSEUDO_REGISTER
+ if ((mode == QImode || mode == HImode)
+ REGNO (reg) = FIRST_PSEUDO_REGISTER
GET_CODE (adr) == PLUS
REG_P (XEXP (adr, 0))
(REGNO (XEXP (adr, 0)) = FIRST_PSEUDO_REGISTER)
@@ -1800,6 +1800,17 @@ prepare_move_operands (rtx operands[], machine_mode
mode)
emit_move_insn (r0_rtx, operands[1]);
operands[1] = r0_rtx;
}
+ if (REGNO (reg) = FIRST_PSEUDO_REGISTER
+ GET_CODE (adr) == PLUS
+ REG_P (XEXP (adr, 0))
+ (REGNO (XEXP (adr, 0)) = FIRST_PSEUDO_REGISTER)
+ SUBREG_P (XEXP (adr, 1))
+ REG_P (SUBREG_REG (XEXP (adr, 1
+ {
+ rtx r0_rtx = gen_rtx_REG (GET_MODE (XEXP (adr, 1)), R0_REG);
+ emit_move_insn (r0_rtx, XEXP (adr, 1));
+ XEXP (adr, 1) = r0_rtx;
+ }
}
}
[Bug tree-optimization/66580] New: max reduction does not auto vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66580
Bug ID: 66580
Summary: max reduction does not auto vectorize
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dejan.crnila at dewesoft dot si
Target Milestone: ---
following code does (max reduction) not auto vectorize on x64/mingw gcc
#include stdio.h
#include float.h
int main()
{
float a[] __attribute__((aligned(0x20))) = {0, 1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13, 14, 15, 16};
float maxval = -FLT_MAX;
for (size_t i = 0; i 16; i++)
maxval = a[i] maxval ? a[i] : maxval;
printf(%g\n, maxval);
}
compiled as
gcc test.c -O3 -Wall -o test.exe -ftree-vectorizer-verbose=6
-fopt-info-vec-all -ffast-math -mavx
not supported or bug?
[Bug c++/66571] Template substitution causes some OpenMP rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66571 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Jun 18 09:54:17 2015 New Revision: 224599 URL: https://gcc.gnu.org/viewcvs?rev=224599root=gccview=rev Log: PR c++/66571 * pt.c (tsubst_omp_clause_decl): New function. (tsubst_omp_clauses): Use it or tsubst_copy instead of tsubst_expr on OMP_CLAUSE_DECL. * g++.dg/gomp/pr66571-1.C: New test. Modified: trunk/gcc/cp/ChangeLog
[Bug middle-end/66567] [CHKP] internal compiler error: in assign_parms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66567 --- Comment #1 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jun 18 10:09:22 2015 New Revision: 224600 URL: https://gcc.gnu.org/viewcvs?rev=224600root=gccview=rev Log: gcc/ PR middle-end/66567 * ipa-chkp.c (chkp_maybe_create_clone): Require functions to be instrumentable. * tree-chkp.c (chkp_replace_function_pointer): Use chkp_instrumentable_p instead of attribute check. gcc/testsuite/ PR middle-end/66567 * gcc.target/i386/mpx/pr66567.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/mpx/pr66567.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-chkp.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chkp.c
[Bug tree-optimization/66510] [6 Regression] gcc.target/arm/pr53636.c FAILs after r224221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66510 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug c++/66583] New: incorrect implicitly-defined move constructor for class with anonymous union and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66583
Bug ID: 66583
Summary: incorrect implicitly-defined move constructor for
class with anonymous union and NSDMI
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code wrongly prints 0 instead of the correct 1:
$ g++ -std=c++11 union.cc
$ ./a.out
0
(reproducible with both 4.9.2 and 5.1.0)
#include algorithm
#include iostream
struct A {
A() { };
A(const A) { }
};
struct B {
union {
int m_1 = 0;
int m_2;
};
A dummy;
};
int main()
{
B b;
b.m_1 = 1;
B c(std::move(b));
std::cout c.m_1 std::endl;
}
The assembly code for B::B(B) when compiling unoptimized has this (x86-64):
movl(%rdx), %edx
movl%edx, (%rax)
Until here, we correctly copy the object representation of the anonymous union
(12.8p16).
movq-8(%rbp), %rax
movl$0, (%rax)
And then we seem to evaluate the non-static data member initializer for m_1,
which is (obviously) wrong.
[Bug middle-end/66568] [CHKP] internal compiler error: in expand_expr_addr_expr_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66568 --- Comment #1 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jun 18 10:14:38 2015 New Revision: 224601 URL: https://gcc.gnu.org/viewcvs?rev=224601root=gccview=rev Log: gcc/ PR middle-end/66568 * cfgexpand.c (expand_return): Handle missing bounds. (expand_gimple_stmt_1): Likewise. * tree-chkp.c (chkp_expand_zero_bounds): New. * tree-chkp.h (chkp_expand_zero_bounds): New. gcc/testsuite/ PR middle-end/66568 * gcc.target/i386/mpx/pr66568.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/mpx/pr66568.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chkp.c trunk/gcc/tree-chkp.h
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to kugan from comment #6) -fno-tree-forwprop works. forwprop propagates: vect__11.22_96 = (vector(4) float) vect_c.21_94; vect__13.24_98 = (vector(4) signed int) vect__11.22_96; into: vect__13.24_98 = (vector(4) signed int) vect_c.21_94; this seems to be the reason why we have expand_fix with V4SI in to mode and from mode. trunk code seems significantly different due to match-and-simplify. Should we disallow this propagation? Any thoughts? So this is a sign-conversion only? Because I can't see how we reach expand_fix with V4SI - V4SI... unless the operation code remains a FIX_TRUNC_EXPR which would be a bug. Checking with a cross.
[Bug c++/66584] New: gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584
Bug ID: 66584
Summary: gcc differs in static, branch-prediction cost from icc
in switch.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jmcguiness at liquidcapital dot com
Target Milestone: ---
This means that code optimised for icc is sub-optimal for icc and the reverse
is true. I feel that this feature should be more clearly documented in the web
pages man pages.
For the following code:
extern void bar1();
extern void bar2();
extern void bar3();
void foo(int i) {
switch(i) {
case 1:
bar1(); // gcc: least likely | icc: most likely
break;
case 2:
bar2(); // gcc: less likely | icc: less likely
break;
default:
bar3(); // gcc: most likely | icc: least likely
}
}
gcc v4.8.2 v5.10 for -O2 -O3 produce:
foo(int):
cmpl$1, %edi
je .L3
cmpl$2, %edi
jne .L8
jmp bar2()
.L8:
jmp bar3()
.L3:
jmp bar1()
From which the static probabilities are quoted, above.
Conversely icc produces:
foo(int):
cmpl $1, %edi #9.10
jne ..B1.3# Prob 67% #9.10
jmp bar1() #11.2
..B1.3: # Preds ..B1.1
cmpl $2, %edi #9.10
jne ..B1.5# Prob 50% #9.10
jmp bar2() #14.5
..B1.5: # Preds ..B1.3
jmp bar3() #17.5
From which the static probabilities are quoted, above.
Please not: I feel this is *only* a bug in the documentation!
It would be nice if my optimised (for speed) code would be optimised (for
speed) on both platforms in the same way, so that I wouldn't have to optimise
my code, but that is only my taste.
[Bug target/66569] [CHKP] internal compiler error: in assign_by_spills
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66569 --- Comment #1 from Ilya Enkovich ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Thu Jun 18 10:18:48 2015 New Revision: 224602 URL: https://gcc.gnu.org/viewcvs?rev=224602root=gccview=rev Log: gcc/ PR target/66569 * function.c (assign_bounds): Add arguments assign_regs, assign_special, assign_bt. (assign_parms): For vararg functions handle bounds in BT and special slots after incoming vararg bounds. gcc/testsuite/ PR target/66569 * gcc.target/i386/mpx/chkp-vararg.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/mpx/pr66569.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66585] New: Internal compiler error when initialize field with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66585 Bug ID: 66585 Summary: Internal compiler error when initialize field with lambda Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: farmaazon at gmail dot com Target Milestone: --- Created attachment 35799 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35799action=edit this code cause internal compiler error I compile attached file using command: g++ --std=c++11 bug.cpp -save-temps -v and get following output: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-5-20150519/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --with-default-libstdcxx-abi=c++98 Thread model: posix gcc version 5.1.0 (GCC) COLLECT_GCC_OPTIONS='-std=c++11' '-save-temps' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -E -quiet -v -D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o bug.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-std=c++11' '-save-temps' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -fpreprocessed bug.ii -quiet -dumpbase bug.cpp -mtune=generic -march=x86-64 -auxbase bug -std=c++11 -version -o bug.s GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2502e86cc323bb15ad071f82f9632779 bug.cpp: In instantiation of ‘someClassT::lambda(T) [with T = int]’: bug.cpp:8:4: required from ‘struct someClassint::lambda(int)’ bug.cpp:16:17: required from here bug.cpp:8:9: internal compiler error: Segmentation fault [](T x) ^
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
Indeed:
./cc1plus -quiet t.ii -O3 -I include
t.ii: In function ‘void fn1()’:
t.ii:3:6: error: invalid types in conversion to integer
void fn1() {
^
vector(4) signed int
vector(4) unsigned int
vect__13.24_98 = (vector(4) signed int) vect_c.21_94;
Jakub, isn't this just PR66233?
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- It is. *** This bug has been marked as a duplicate of bug 66233 ***
[Bug tree-optimization/66233] [4.8/4.9/5/6 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 66554 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/66233] [4.8/4.9 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.2.0, 6.0 Summary|[4.8/4.9/5/6 Regression]|[4.8/4.9 Regression] |internal compiler error: in |internal compiler error: in |expand_fix, at |expand_fix, at |optabs.c:5358 |optabs.c:5358 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk/5.
[Bug tree-optimization/66233] [4.8/4.9 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Ok, I'll look at the 4.9/4.8 fix then.
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Have you bisected what fixed this in 5.1?
[Bug middle-end/66581] New: [CHKP] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66581
Bug ID: 66581
Summary: [CHKP] internal compiler error: SSA corruption
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
cat test.i
void *a;
int b;
void
fn1 (void)
{
void *c = l_nop;
l_nop:
for (; b;)
;
int *d = c;
c = fn1;
*d = 1;
goto *a;
}
gcc -fcheck-pointer-bounds -mmpx test.i
Unable to coalesce ssa_names 11 and 13 which are marked as MUST COALESCE.
__bound_tmp.3_11(ab) and __bound_tmp.3_13(ab)
test.i: In function 'fn1.chkp':
test.i:5:1: internal compiler error: SSA corruption
fn1 (void)
^
0xf00ce1 fail_abnormal_edge_coalesce
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/tree-ssa-coalesce.c:918
0xf01dc5 coalesce_partitions
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/tree-ssa-coalesce.c:1221
0xf024af coalesce_ssa_name()
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/tree-ssa-coalesce.c:1366
0xe83f86 remove_ssa_form
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/tree-outof-ssa.c:1003
0xe848c9 rewrite_out_of_ssa(ssaexpand*)
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/tree-outof-ssa.c:1237
0x851361 execute
/gnumnt/msticlxl7_users/ienkovic/issues/mpx/gcc/gcc/cfgexpand.c:5872
Fails on GCC 6 and GCC 5.1
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 --- Comment #8 from kugan at gcc dot gnu.org --- Starting bisect now.
[Bug c++/66573] Unexpected change in static, branch-prediction cost from O1 to O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573 --- Comment #1 from Jason McG jmcguiness at liquidcapital dot com --- Note that clang++ for all tested versions (3.0, 3.2, 3.3, 3.4.1, 3.5, 3.5.1, 3.6 (rc2), 3.7 (experimental)) produce the same assembler output for -O1, -O2 -O3: foo(bool):# @foo(bool) testb %dil, %dil je .LBB0_2 jmp bar1()# TAILCALL .LBB0_2: jmp bar2()# TAILCALL With bar1() being the statically-predicted branch, as per icc and Intel's own documentation (as referenced in the link in the initial comment).
[Bug c++/66573] Unexpected change in static, branch-prediction cost from O1 to O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66573
--- Comment #2 from Jason McG jmcguiness at liquidcapital dot com ---
If I try with this code:
#define likely(x) __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)
extern void bar1();
extern void bar2();
void foo(bool i) {
// if (i)
if (likely(i))
bar1();
else
bar2();
}
Then the assembly output for gcc 4.8.2 5.10 (the ones I tested) for -O0, -O1,
-O2 -O3 is the same:
foo(bool):
testb %dil, %dil
je .L2
jmp bar1()
.L2:
jmp bar2()
i.e. gcc now behaves as per icc and clang++. So using __builtin_expect seems to
be a work-around to get gcc to behave like other compilers.
I would sincerely hope that at least the documentation for these optimisation
options warns the programmer that gcc optimises if-else statements in the
reverse manner to other major compilers and even across it's own optimisation
levels (!), as this apparent change in behaviour is most unexpected...
[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66533 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- ICE started with r208426.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug tree-optimization/66510] [6 Regression] gcc.target/arm/pr53636.c FAILs after r224221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66510 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jun 18 09:39:13 2015 New Revision: 224598 URL: https://gcc.gnu.org/viewcvs?rev=224598root=gccview=rev Log: 2015-06-18 Richard Biener rguent...@suse.de PR tree-optimization/66510 * tree-vect-stmts.c (vectorizable_load): Properly compute the number of vector loads for SLP permuted loads. * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Also check the stride for loop vectorization. (vect_enhance_data_refs_alignment): Deal with SLP adjusted vectorization factor. (vect_analyze_group_access): If the group size is not a power of two require a epilogue loop. * tree-vect-loop.c (vect_analyze_loop_2): Move alignment compute and optimizing and alias test pruning after final vectorization factor computation. * tree-vect-slp.c (vect_build_slp_tree_1): Remove check on vector alignment. (vect_transform_slp_perm_load): Properly compute the original number of vector load stmts. * gcc.dg/vect/slp-perm-12.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/slp-perm-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c
[Bug c/66582] New: -Wstrict-overflow issues invalid warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66582
Bug ID: 66582
Summary: -Wstrict-overflow issues invalid warning.
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matthias.meixner at verifone dot com
Target Milestone: ---
Compiling the code below gives a warning when compiled as follows.
gcc -O3 -Wall -c opt.c -DSHOWWARN
opt.c: In function ‘test’:
opt.c:18:9: warning: assuming signed overflow does not occur when assuming that
(X + c) = X is always true [-Wstrict-overflow]
if(tst last || tst first) return 1234;
^
opt.c:13:23: warning: assuming signed overflow does not occur when assuming
that (X + c) = X is always true [-Wstrict-overflow]
if (first tst tst last ) return 1234;
The strange thing is that it does not give any warning at all, when compiled
using:
gcc -O3 -Wall -c opt.c
The difference between the two is just the order of the comparisons which
should not make any real difference.
This is the code that was used:
==
int get(int *a, int *b);
int test()
{
int last,tst,first;
get(last,first);
tst = last;
if (tst =0) tst += ;
if (first last) {
if (first tst tst last ) return 1234;
}
else
{
#ifdef SHOWWARN
if(tst last || tst first) return 1234;
#else
if(tst first || tst last) return 1234;
#endif
}
return 4321;
}
[Bug c++/66543] False positive warning variable set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66543 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-18 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66533 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-18 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. ICEs since 4.9, was rejected with 4.8.
[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578 --- Comment #3 from vehre at gcc dot gnu.org --- Strictly speaking has this not much to do with the renewed allocate(). The pseudo code shows that with and without the block construct the offset of the source array's temporary descriptor is computed to be zero, while the lbound is one. This would lead to a memory issue in either case, wouldn't the program w/o the block construct not compute the temporary offset for addressing the elements w/o respect to the descriptor's offset (by using the negative lbound).
[Bug target/66554] [4.9 Regression] ICE (in expand_fix, at optabs.c:5365) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554 --- Comment #6 from kugan at gcc dot gnu.org --- -fno-tree-forwprop works. forwprop propagates: vect__11.22_96 = (vector(4) float) vect_c.21_94; vect__13.24_98 = (vector(4) signed int) vect__11.22_96; into: vect__13.24_98 = (vector(4) signed int) vect_c.21_94; this seems to be the reason why we have expand_fix with V4SI in to mode and from mode. trunk code seems significantly different due to match-and-simplify. Should we disallow this propagation? Any thoughts?
[Bug c++/66585] Internal compiler error when initialize field with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66585
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-06-18
CC||trippels at gcc dot gnu.org
Known to work||4.9.2
Ever confirmed|0 |1
Known to fail||5.0, 6.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat bug.ii
class A {
template typename, typename using _Requires = int;
public:
template typename _Functor, typename = _Requires_Functor, void
A(_Functor);
};
template class T class B {
A f = [](T) {};
};
Bint a;
markus@x4 tmp % g++ -c --std=c++11 bug.ii
bug.ii: In instantiation of ‘BT::lambda(T) [with T = int]’:
bug.ii:9:10: required from ‘struct Bint::lambda(int)’
bug.ii:12:8: required from here
bug.ii:9:13: internal compiler error: Segmentation fault
A f = [](T) {};
^
0xccc84f crash_signal
../../gcc/gcc/toplev.c:369
0x62adea contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:2971
0x62adea instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:20496
0x66a9fc instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9647
0x66a9fc instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9715
0x707c2b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:140
0x6445bf tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15743
0x731c98 get_nsdmi(tree_node*, bool)
../../gcc/gcc/cp/init.c:558
0x740fca walk_field_subobs
../../gcc/gcc/cp/method.c:1213
0x741ae4 synthesized_method_walk
../../gcc/gcc/cp/method.c:1539
0x745c3a get_defaulted_eh_spec(tree_node*)
../../gcc/gcc/cp/method.c:1570
0x6530eb maybe_instantiate_noexcept(tree_node*)
../../gcc/gcc/cp/pt.c:20111
0x6adeda mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4991
0x5c6a80 build_over_call
../../gcc/gcc/cp/call.c:7496
0x5d1a8e build_new_method_call_1
../../gcc/gcc/cp/call.c:8212
0x5d1a8e build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8282
0x5d2a49 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7822
0x736338 expand_default_init
../../gcc/gcc/cp/init.c:1728
0x736338 expand_aggr_init_1
../../gcc/gcc/cp/init.c:1829
0x737034 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1578
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 c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66584
--- Comment #1 from Jason McG jmcguiness at liquidcapital dot com ---
(In reply to Jason McG from comment #0)
I got my static bp summaries wrong, corrected:
void foo(int i) {
switch(i) {
case 1:
bar1(); // gcc: less likely (same as default) | icc: most likely
break;
case 2:
bar2(); // gcc: most likely | icc: less likely
break;
default:
bar3(); // gcc: less likely (same as case 1) | icc: least likely
}
}
[Bug tree-optimization/66233] [4.8/4.9 Regression] internal compiler error: in expand_fix, at optabs.c:5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66233 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35800 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35800action=edit gcc49-pr66233.patch Untested 4.9 version of the fix.
