[Bug tree-optimization/92608] [9/10 Regression] ICE: Segmentation fault (in find_loop_guard)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92608 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added CC||prathamesh3492 at gcc dot gnu.org --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- Posted patch upstream: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02061.html Thanks, Prathamesh
[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195 --- Comment #11 from Dmitry G. Dyachenko --- r278496 fix my original problem. Thank you
[Bug target/92592] Redundant comparison after subtraction on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92592 --- Comment #2 from Andrew Pinski --- I think this is really a dup of bug 3507.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 92414, which changed state. Bug 92414 Summary: [10 Regression] internal compiler error: tree check: expected constructor, have error_mark in cxx_eval_store_expression, at cp/constexpr.c:4009 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/90867] [8/9 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] |Multiplication or typecast |Multiplication or typecast |of integer and double |of integer and double |always zero when... |always zero when... --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/90898] [8/9 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |insert_clobber_before_stack |insert_clobber_before_stack |_restore, at|_restore, at |tree-ssa-ccp.c:2112 |tree-ssa-ccp.c:2112 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 91195, which changed state. Bug 91195 Summary: [10 regression] incorrect may be used uninitialized smw (272711, 273474] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/90840] [8/9 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |simplify_subreg, at |simplify_subreg, at |simplify-rtx.c:6441 |simplify-rtx.c:6441 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/92414] [10 Regression] internal compiler error: tree check: expected constructor, have error_mark in cxx_eval_store_expression, at cp/constexpr.c:4009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/90767] [9 Regression] jumbled error message with this and const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 09:55:56 2019 New Revision: 278492 URL: https://gcc.gnu.org/viewcvs?rev=278492=gcc=rev Log: PR c++/90767 * call.c (complain_about_no_candidates_for_method_call): If conv->from is not a type, pass to complain_about_bad_argument lvalue_type of conv->from. * g++.dg/diagnostic/pr90767-1.C: New test. * g++.dg/diagnostic/pr90767-2.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/diagnostic/pr90767-1.C branches/gcc-9-branch/gcc/testsuite/g++.dg/diagnostic/pr90767-2.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/call.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/92594] [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92594 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-20 Known to work||9.2.1 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Jonathan Wakely --- Regressed with r276968: PR c++/91930 - ICE with constrained inherited default ctor. The testcase was crashing because lazily_declare_fn was failing to add a defaulted constructor, because the implicit declaration was less constrained than the inherited default constructor. But when we have an inherited constructor, we shouldn't be trying to declare a default constructor in the first place, because it counts as "a user-declared constructor". With that fixed I needed to adjust a couple of inherited constructor testcases that previously had been diagnosing the default constructor as deleted rather than not declared. * name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR for inherited constructor.
[Bug middle-end/90796] [8/9 Regression] GCC: O2 vs O3 output differs on simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 --- Comment #16 from Michael Matz --- (In reply to Jakub Jelinek from comment #14) > Time to backport now? Hmpf, I've actually done the regstrapping for gcc9 already but then forgot to submit. Thanks for the reminder.
[Bug middle-end/90796] [8/9 Regression] GCC: O2 vs O3 output differs on simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 Jakub Jelinek changed: What|Removed |Added CC||vsevolod.livinskij at frtk dot ru --- Comment #15 from Jakub Jelinek --- *** Bug 91240 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/91240] [8/9/10 Regression] Wrong code with -O3 due to unroll and jam pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91240 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 90796 ***
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
Aleksey changed:
What|Removed |Added
CC||rndfax at yandex dot ru
--- Comment #12 from Aleksey ---
Committed test case gcc/testsuite/gcc.target/powerpc/pr71785.c still fails on
the latest GCC version. It seems some flags affect result.
For example, this command:
gcc -S -O3 gcc/testsuite/gcc.target/powerpc/pr71785.c
produces good result - all computed gotos are of type "jump reg":
$ fgrep jmp pr71785.s
jmp *%rax
jmp *%rax
jmp *%rax
jmp *%rax
$
But adding these two flags "-fno-reorder-blocks-and-partition
-fno-reorder-blocks" we get command like this:
gcc -S -O3 -fno-reorder-blocks-and-partition -fno-reorder-blocks
gcc/testsuite/gcc.target/powerpc/pr71785.c
and we see that it does not optimize one goto:
$ fgrep jmp pr71785.s
jmp .L2
jmp *%rax
jmp *%rax
jmp *%rax
jmp *%rax
$
I investigated this a little in the source code of GCC. And found that in
gcc/bb-reorder.c one basic block is not optimized
(pass_duplicate_computed_gotos) because of failing this condition
"single_pred_p (bb)" in this for-loop block, in this if statement:
for (ei = ei_start (bb->preds); (e = ei_safe_edge (ei)); )
{
basic_block pred = e->src;
/* Do not duplicate BB into PRED if that is the last predecessor, or if
we cannot merge a copy of BB with PRED. */
if (single_pred_p (bb)
|| !single_succ_p (pred)
|| e->flags & EDGE_COMPLEX
|| pred->index < NUM_FIXED_BLOCKS
|| (JUMP_P (BB_END (pred)) && !simplejump_p (BB_END (pred)))
|| (JUMP_P (BB_END (pred)) && CROSSING_JUMP_P (BB_END (pred
{
ei_next ();
continue;
}
If I get it right, happens this: bb, which has "jmp reg", has several
predecessors, which all have "jmp rel" to this bb. After merging this bb into
such a predecessor, bb have one predecessor less. When bb leaves with one
predecessor it falls into this if and stop optimizing.
One may say, that it's not that big deal, that only the first jump is not
optimized. But with additional flag "-mcmodel=large" and this patch on the
committed test case file gcc/testsuite/gcc.target/powerpc/pr71785.c:
```
diff --git a/gcc/testsuite/gcc.target/powerpc/pr71785.c
b/gcc/testsuite/gcc.target/powerpc/pr71785.c
index c667ad8..6c8dde6 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr71785.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr71785.c
@@ -28,6 +28,7 @@ extern void do_stuff_b(int arg);
extern void do_stuff_c(int arg);
extern int someglobal;
+extern void *jump;
void
eval(op *op)
@@ -43,10 +44,14 @@ eval(op *op)
CASE_OP_A:
someglobal++;
op++;
+ if (op->opcode == OP_END)
+ goto *jump;
goto *dispatch_table[op->opcode];
CASE_OP_B:
do_stuff_b(op->arg);
op++;
+ if (op->opcode == OP_END)
+ goto *jump;
goto *dispatch_table[op->opcode];
CASE_OP_C:
do_stuff_c(op->arg);
```
the results become bad:
gcc -S -O3 -fno-reorder-blocks-and-partition -fno-reorder-blocks -mcmodel=large
gcc/testsuite/gcc.target/powerpc/pr71785_patched.c
$ fgrep jmp pr71785.s
jmp .L2
jmp .L14
jmp *%rax
jmp *%rax
jmp .L6
jmp *%rax
jmp *%rax
$
More real-world example of mine from project that I'm working on is using these
flags:
gcc -S -O3 -fno-reorder-blocks-and-partition -fno-reorder-blocks -mcmodel=large
-fno-crossjumping -fno-gcse -fno-PIE
gcc/testsuite/gcc.target/powerpc/pr71785_patched.c
which gives this:
$ fgrep jmp pr71785.s
jmp .L2
jmp .L4
jmp *%rax
jmp *%rax
jmp *%rax
jmp .L6
jmp *%rax
jmp *%rax
jmp *%rax
$
If the first jump is not that crucial - it can be "jmp rel + jmp reg" - all
other jumps must be "jmp reg" only. Moreover, basic blocks are not traversed in
order they appear in source file, so in one day the first jump becomes "jmp rel
+ jmp reg", the other day (depending on the source file and basic block
traversing order) some crucial goto becomes "jmp rel + jmp reg", instead of
just "jmp reg". And this breaks everything.
Is it possible to fix that?
[Bug tree-optimization/91355] [8/9/10 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Component|c++ |tree-optimization
--- Comment #3 from Jakub Jelinek ---
Slightly cleaned up testcase for g++.dg/torture/
// PR tree-optimization/91355
// { dg-do run { target c++14_down } }
unsigned int d = 0;
struct S {
S () { d++; }
S (const S &) { d++; }
~S () { d--; }
};
void
foo (int i) throw (int) // { dg-warning "dynamic exception specifications are
deprecated" "" { target c++11 } }
{
if (i == 0)
throw 3;
S d;
throw 3;
}
int
main ()
{
try { foo (1); } catch (...) {}
if (d)
__builtin_abort ();
}
The sink pass first sinks d = d - 1; statements across resx 4; into a new basic
block which is made new successor of the bb containing resx 4;, so:
:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
resx 4
becomes:
:
resx 4
[count: 0]:
:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
goto ; [100.00%]
sink_code_in_bb has:
/* We can't move things across abnormal edges, so don't try. */
FOR_EACH_EDGE (e, ei, bb->succs)
if (e->flags & EDGE_ABNORMAL)
goto earlyout;
Shouldn't that be & (EDGE_ABNORMAL | EDGE_EH) ? Or are there any cases where
we actually want to sink something across EH edge? Even if yes, we shouldn't
put anything before landing pads IMHO.
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #13 from Segher Boessenkool --- (In reply to Aleksey from comment #12) > But adding these two flags "-fno-reorder-blocks-and-partition > -fno-reorder-blocks" If you say that basic blocks should not be reordered, then they are not. All behaving perfectly as expected. These options will cause exactly the same kind of "problems" everywhere else as well. > Is it possible to fix that? Yes, don't use compilers options that degrade performance, if you want good performance?
[Bug tree-optimization/92596] New: [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596
Bug ID: 92596
Summary: [10 Regression] ICE in exact_div, at poly-int.h:2162
since r278406
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org
Target Milestone: ---
I see the following ICE:
$ cat div2.i
typedef struct {
long n[5];
} secp256k1_fe;
int a, b, c;
void fn1(secp256k1_fe *p1, int p2) { p1->n[2] = p1->n[3] = p1->n[4] = p2; }
void fn2() {
fn1(b, !c);
fn1(a, !c);
}
$ gcc -c div2.i -O3
div2.i: In function ‘fn2’:
div2.i:8:7: warning: passing argument 1 of ‘fn1’ makes pointer from integer
without a cast [-Wint-conversion]
8 | fn1(b, !c);
| ^
| |
| int
div2.i:6:24: note: expected ‘secp256k1_fe *’ but argument is of type ‘int’
6 | void fn1(secp256k1_fe *p1, int p2) { p1->n[2] = p1->n[3] = p1->n[4] =
p2; }
| ~~^~
div2.i:9:7: warning: passing argument 1 of ‘fn1’ makes pointer from integer
without a cast [-Wint-conversion]
9 | fn1(a, !c);
| ^
| |
| int
div2.i:6:24: note: expected ‘secp256k1_fe *’ but argument is of type ‘int’
6 | void fn1(secp256k1_fe *p1, int p2) { p1->n[2] = p1->n[3] = p1->n[4] =
p2; }
| ~~^~
during GIMPLE pass: slp
div2.i:7:6: internal compiler error: in exact_div, at poly-int.h:2162
7 | void fn2() {
| ^~~
0x738c34 poly_int<1u, poly_result::is_poly>::type,
poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int_pod<1u, unsigned long>
const&, unsigned long)
/home/marxin/Programming/gcc/gcc/poly-int.h:2162
0x738c34 poly_int<1u, poly_result::result_kind>::type>
exact_div<1u, unsigned long, unsigned long>(poly_int_pod<1u, unsigned long>
const&, poly_int_pod<1u, unsigned long> const&)
/home/marxin/Programming/gcc/gcc/poly-int.h:2175
0x738c34 vect_get_num_vectors
/home/marxin/Programming/gcc/gcc/tree-vectorizer.h:1490
0x738c34 vect_slp_analyze_node_operations_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2795
0x738c34 vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2905
0x1064d78 vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2863
0x1064d78 vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2863
0x1065778 vect_slp_analyze_operations(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2939
0x106b352 vect_slp_analyze_bb_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3267
0x106b352 vect_slp_bb_region
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3328
0x106b352 vect_slp_bb(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3463
0x106d34f execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1320
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-20 Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug ipa/92372] [10 Regression] ICE in ipa_update_overall_fn_summary at gcc/ipa-fnsummary.c:3671 since r277780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #1 from Zdenek Sojka ---
Simpler testcase, likely related (r278484):
$ cat testcase-min2.i
__attribute__((flatten)) void a() { a(); }
$ x86_64-pc-linux-gnu-gcc -O -fPIC testcase-min2.i -wrapper valgrind,-q
==16177== Invalid write of size 4
==16177==at 0x65BAAD: ipa_update_overall_fn_summary(cgraph_node*) [clone
.cold] (ipa-fnsummary.c:3755)
==16177==by 0x19317E3: ipa_inline (ipa-inline.c:2612)
==16177==by 0x19317E3: (anonymous
namespace)::pass_ipa_inline::execute(function*) (ipa-inline.c:3025)
==16177==by 0xEA35B7: execute_one_pass(opt_pass*) (passes.c:2500)
==16177==by 0xEA4ED6: execute_ipa_pass_list(opt_pass*) (passes.c:2927)
==16177==by 0xB20600: ipa_passes (cgraphunit.c:2541)
==16177==by 0xB20600: symbol_table::compile() [clone .part.0]
(cgraphunit.c:2618)
==16177==by 0xB2257C: compile (cgraphunit.c:2598)
==16177==by 0xB2257C: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2865)
==16177==by 0xF9771E: compile_file() (toplev.c:483)
==16177==by 0x98B331: do_compile (toplev.c:2275)
==16177==by 0x98B331: toplev::main(int, char**) (toplev.c:2414)
==16177==by 0x98EEAE: main (main.c:39)
==16177== Address 0xc is not stack'd, malloc'd or (recently) free'd
==16177==
during IPA pass: inline
testcase-min2.i:1:1: internal compiler error: Segmentation fault
1 | __attribute__((flatten)) void a() { a(); }
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See
Vamos evoluir juntos?
seu leitor nao suporta emails html
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 --- Comment #5 from Segher Boessenkool --- The whole function can be something as simple as mode = mode_for_vector (mode, 16 / GET_MODE_SIZE (mode)); if (this is actually an existing mode && !VECTOR_UNIT_NONE (mode)) return mode; return word_mode; Or, why not?
[Bug tree-optimization/91355] [8/9/10 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355 --- Comment #6 from Jakub Jelinek --- I think we have two issues. One is that if we sink something on the edge between resx and corresponding landing pad, ehcleanup2 is upset, and the other one is that it is really not beneficial to sink the stmts there. If we fix the latter, we'd just have a latent bug though. In the testcase, both best_bb (the bb from splitting the EH edge) as well as early_bb have count of 0, because this is all EH stuff and happens only if the code throws (which is always, but we handle EH as something very rare). r254698 changed best_bb->count.to_frequency < early_bb->count.to_frequency * 82% to !(best_bb->count.apply_scale(100,1) > early_bb->count.apply_scale(82,1)) and so with zero counts the condition was false, but now it is true. Though, the comment talks about !(... >= ...) rather than !(... > ...). Honza, shouldn't that be !(... >= ...) as the comment says? At least for the case of zero counts, if early_bb has the same count as best_bb, it isn't profitable to sink it, it should be profitable only if it has 82% smaller count (or smaller). Changing the > into >= makes the wrong-code go away, though as I said, we have a latent issue and from what I understood, PRE might be inserting on such edges too, otherwise we wouldn't split it.
[Bug middle-end/91433] Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433 --- Comment #9 from Richard Biener --- *** Bug 91494 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/91355] [8/9/10 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355 --- Comment #4 from Jakub Jelinek --- bb 10 into which it is sunk has been created by split_critical_edges, although the edge from the resx 4; bb to the landing pad is not critical, there is: /* PRE inserts statements to edges and expects that since split_critical_edges was done beforehand, committing edge insertions will not split more edges. In addition to critical edges we must split edges that have multiple successors and end by control flow statements, such as RESX. Go ahead and split them too. This matches the logic in gimple_find_edge_insert_loc. */
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #6 from Andrew Sutton --- I'm going to send a patch for this, hopefully this morning, that ties concept diagnostics into static asserts. It wasn't as bad as I thought it was going to be. I didn't implement this: static_assert (!Int); because I'm not sure what would be good to print. It may be possible to completely invert all the diagnostics (e.g., failed because f(x) is valid), but that would likely take some heroic effort.
[Bug tree-optimization/92595] New: [10 Regression] ICE in related_vector_mode, at stor-layout.c:534 since r278229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92595
Bug ID: 92595
Summary: [10 Regression] ICE in related_vector_mode, at
stor-layout.c:534 since r278229
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target Milestone: ---
Starting with the revision, I see the following issue:
$ cat greedy.ii
void *operator new(unsigned, void *a) { return a; }
class b {
public:
using c = int *;
c e();
c h();
};
template class j : b {
public:
void l() {
for (auto f = h(), g = e(); f != g; ++f)
new (f) d();
}
};
class m {
public:
enum i {};
struct C {
i : 8;
i k : 8;
};
};
class o {
j n;
o();
};
o::o() { n.l(); }
$ ./xg++ -B. -m32 -O3 greedy.ii -c -mtune=generic -march=i586
during GIMPLE pass: vect
greedy.ii: In constructor ‘o::o()’:
greedy.ii:27:1: internal compiler error: in related_vector_mode, at
stor-layout.c:534
27 | o::o() { n.l(); }
| ^
0x78ae2a related_vector_mode(machine_mode, scalar_mode, poly_int<1u, unsigned
long>)
/home/marxin/Programming/gcc/gcc/stor-layout.c:534
0x78ae2a related_vector_mode(machine_mode, scalar_mode, poly_int<1u, unsigned
long>)
/home/marxin/Programming/gcc/gcc/stor-layout.c:531
0x12702b3 vectorizable_store
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:7826
0x127ebba vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:10953
0x12a5a9e vect_schedule_slp_instance
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4241
0x12b090f vect_schedule_slp(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4360
0x129841e vect_transform_loop(_loop_vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.c:8609
0x12b57ce try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:989
0x12b6271 vectorize_loops()
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1125
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/92595] [10 Regression] ICE in related_vector_mode, at stor-layout.c:534 since r278229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92595 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-20 Known to work||9.2.0 Host||x86_64-linux-gnu Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug c++/92580] "if constexpr" not discarding branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92580 Paul Targosz changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Paul Targosz --- closing issue because you're right
[Bug rtl-optimization/91333] [9/10 Regression] suboptimal register allocation for inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333 --- Comment #3 from Marc Glisse --- gcc version 9.2.1 20191109 (Debian 9.2.1-19) (current debian testing/unstable) gives me the 3 movapd, whether I use -O1, -O2 or -O3, and -Os gives 2 movapd. I didn't try with a vanilla gcc, not sure which debian-specific patch could be relevant (-fno-pie doesn't change anything). With gcc-snapshot (Debian 20191008-1), only -O1 gives some movapd (only 2).
[Bug target/92573] [10 Regression] ICE in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92573 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Segher Boessenkool --- Fixed. Thanks for the report!
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 --- Comment #14 from Aleksey --- (In reply to Segher Boessenkool from comment #13) > (In reply to Aleksey from comment #12) > > But adding these two flags "-fno-reorder-blocks-and-partition > > -fno-reorder-blocks" > > If you say that basic blocks should not be reordered, then they > are not. All behaving perfectly as expected. > > These options will cause exactly the same kind of "problems" > everywhere else as well. > > > Is it possible to fix that? > > Yes, don't use compilers options that degrade performance, if > you want good performance? Performance is not the case here, so don't bother with it. Strict order of labels and using everywhere "jmp reg" instead of "jmp rel + jmp reg" - this is what is important. Documentation (https://gcc.gnu.org/onlinedocs/gccint/Edges.html#Edges) says "During the earlier stages of the compilation process, GCC tries to avoid such dense flow graphs by factoring computed jumps". Then it states that "the computed jumps are un-factored in the later passes of the compiler (in the pass called pass_duplicate_computed_gotos)". It would be helpful if you give the explanation how these options affect "un-factoring".
[Bug fortran/48303] [Legacy] Support Character constants in DATA statement for non-character variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48303 MarkEggleston changed: What|Removed |Added CC||mark.eggleston at codethink dot co ||m --- Comment #6 from MarkEggleston --- See https://gcc.gnu.org/viewcvs/gcc?view=revision=277975 I'm pretty sure this can be closed as fixed.
[Bug c++/92597] New: std::fma gives nan using -march=sandybridge+ with asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597 Bug ID: 92597 Summary: std::fma gives nan using -march=sandybridge+ with asm volatile Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: leppkes at stce dot rwth-aachen.de Target Milestone: --- Created attachment 47307 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47307=edit tiny example with makefile to reproduce. I attached a small example to illustrate my problem. Short: -O1+ -march=sandybridge+ gives wrong values when using asm volatile (which is taken from google benchmark). To reproduce: $>make g++ -O1 test.cpp -o gcc.exe ./gcc.exe > gcc.txt g++ -O1 -march=sandybridge test.cpp -o gcc_march.exe ./gcc_march.exe > gcc_march.txt diff gcc.txt gcc_march.txt 6,7c6,7 < FMA: 0; TYPE: double; ASM Volatile: 1 => y=0 < FMA: 1; TYPE: long double; ASM Volatile: 1 => y=0 --- > FMA: 0; TYPE: double; ASM Volatile: 1 => y=6.95302e-305 > FMA: 1; TYPE: long double; ASM Volatile: 1 => y=-nan make: *** [makefile:14: diff_gcc] Error 1 So not using asm volatile gives the correct values. In the makefile, clang is also possible to test, which seems to work propper (as well as Intel C++). To check clang, just type $>make diff_clang clang++ -O1 test.cpp -o clang.exe ./clang.exe > clang.txt clang++ -O1 -march=sandybridge test.cpp -o clang_march.exe ./clang_march.exe > clang_march.txt diff clang.txt clang_march.txt Using -O0 gives correct values btw, so it seems inside an optimizer. Cheers, Klaus
[Bug c++/92594] [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92594 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/92593] [10 Regression] ICE with CTAD using undeclared constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92593 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/92582] [10 Regression] internal compiler error: Segmentation fault with concept on constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92582 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365 --- Comment #7 from Martin Liška --- Just for the record, I see the failure in spatialindex package.
[Bug target/90867] [8/9/10 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 20 08:31:43 2019
New Revision: 278482
URL: https://gcc.gnu.org/viewcvs?rev=278482=gcc=rev
Log:
PR target/90867
* config/i386/i386-options.c (ix86_valid_target_attribute_tree): Don't
clear opts->x_ix86_isa_flags{,2} here...
(ix86_valid_target_attribute_inner_p): ... but here when seeing
arch=. Also clear opts->x_ix86_isa_flags{,2}_explicit.
* gcc.target/i386/pr90867.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr90867.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-options.c
trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/92537] [10 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:2775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92537 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug c/90898] [8/9/10 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 08:29:35 2019 New Revision: 278481 URL: https://gcc.gnu.org/viewcvs?rev=278481=gcc=rev Log: PR c/90898 * tree-ssa-ccp.c (insert_clobber_before_stack_restore): Remove assertion. (insert_clobbers_for_var): Fix a typo in function comment. * gcc.dg/pr90898.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr90898.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug c++/92504] [9 Regression] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] ICE on|[9 Regression] ICE on gcc-9 |gcc-9 -fopenmp: internal|-fopenmp: internal compiler |compiler error: tree check: |error: tree check: expected |expected tree that contains |tree that contains 'decl |'decl common' structure,|common' structure, have |have 'baselink' in |'baselink' in |get_inner_reference, at |get_inner_reference, at |expr.c:7238 |expr.c:7238 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/92593] New: ICE with CTAD using undeclared constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92593
Bug ID: 92593
Summary: ICE with CTAD using undeclared constraint
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 67491
Target Milestone: ---
template // oops, should be std::integral
struct ref_view
{
ref_view(T) { }
};
ref_view r{1};
This crashes when compiled with -std=gnu++2a:
ice.cc:1:10: error: 'integral' has not been declared
1 | template // oops, should be std::integral
| ^~~~
ice.cc:4:11: warning: unnecessary parentheses in declaration of 'T'
[-Wparentheses]
4 | ref_view(T) { }
| ^
ice.cc:4:17: error: expected ';' at end of member declaration
4 | ref_view(T) { }
| ^
| ;
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/90867] [8 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression]|[8 Regression] |Multiplication or typecast |Multiplication or typecast |of integer and double |of integer and double |always zero when... |always zero when... --- Comment #9 from Jakub Jelinek --- Fixed for 9.3+ too.
[Bug middle-end/90840] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |simplify_subreg, at |simplify_subreg, at |simplify-rtx.c:6441 |simplify-rtx.c:6441 --- Comment #7 from Jakub Jelinek --- Fixed for 9.3+ too.
[Bug c++/92504] [9 Regression] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/92584] A 454.calculix optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 --- Comment #2 from Martin Liška --- (In reply to rguent...@suse.de from comment #1) > On Tue, 19 Nov 2019, marxin at gcc dot gnu.org wrote: > > > I noticed that the speed drop back on the trunk happened since r278281. > > Would you be interested in what loop optimization made the difference? > > Well, the revs probably caused changes in (early) unrolling with the > better performance seen with less unrolling. We know that even more > unrolling will increase performance though. Ok, so the benchmark likes unrolling :) > > Not sure what you are asking? My question is simple: Can we somehow tweak our defaults so that we can speed up calculix. Note that the speed up is 2x.
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #5 from Georg-Johann Lay --- Author: gjl Date: Wed Nov 20 08:19:44 2019 New Revision: 278478 URL: https://gcc.gnu.org/viewcvs?rev=278478=gcc=rev Log: Make 0-series device specs work with older versions of avr-gcc. PR target/92545 * config/avr/specs.h (LINK_SPEC) <%(link_pm_base_address)>: Remove. * config/avr/gen-avr-mmcu-specs.c (print_mcu) <*link_pm_base_address>: Don't write spec. <*link_arch>: Add --defsym=__RODATA_PM_OFFSET__= as needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c trunk/gcc/config/avr/specs.h
[Bug sanitizer/92589] heuristic to avoid flexible array members too liberal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 --- Comment #4 from Jakub Jelinek --- (In reply to Kees Cook from comment #2) > Is there anything to enforce a strict "only consider empty array size as > flexible array member" mode? This is an unfortunate weakening of the array > bounds checker as there are plenty of structures that have a fixed-size > array as the final member. There is -fsanitize=bounds-strict.
[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92590 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-20 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Regressed with r276968: PR c++/91930 - ICE with constrained inherited default ctor. The testcase was crashing because lazily_declare_fn was failing to add a defaulted constructor, because the implicit declaration was less constrained than the inherited default constructor. But when we have an inherited constructor, we shouldn't be trying to declare a default constructor in the first place, because it counts as "a user-declared constructor". With that fixed I needed to adjust a couple of inherited constructor testcases that previously had been diagnosing the default constructor as deleted rather than not declared. * name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR for inherited constructor.
[Bug middle-end/90840] [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 08:32:56 2019 New Revision: 278483 URL: https://gcc.gnu.org/viewcvs?rev=278483=gcc=rev Log: PR middle-end/90840 * expmed.c (store_bit_field_1): Handle the case where op0 is not a MEM and has a mode that doesn't have corresponding integral type. * gcc.c-torture/compile/pr90840.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr90840.c Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/92584] A 454.calculix optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-20 Blocks||26163 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- > > I've tried multiple times to no avail ... :/ But yeah. I'll have another > look ;) It's gfortran.dg/reassoc_4.f btw. IIRC. See also the > --param adjustment therein ... Honza lowered the param at some point, > regressing things. Hehe, that's good that we have it isolated as a test-case. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug c++/90767] [9 Regression] jumbled error message with this and const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-20 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[9/10 Regression] jumbled |[9 Regression] jumbled |error message with this and |error message with this and |const |const Ever confirmed|0 |1 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/90898] [8/9 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 09:53:15 2019 New Revision: 278489 URL: https://gcc.gnu.org/viewcvs?rev=278489=gcc=rev Log: PR c/90898 * tree-ssa-ccp.c (insert_clobber_before_stack_restore): Remove assertion. (insert_clobbers_for_var): Fix a typo in function comment. * gcc.dg/pr90898.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr90898.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/tree-ssa-ccp.c
[Bug c++/92504] [9 Regression] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:7238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 09:52:27 2019 New Revision: 278488 URL: https://gcc.gnu.org/viewcvs?rev=278488=gcc=rev Log: Backported from mainline 2019-11-19 Jakub Jelinek PR c++/92504 * semantics.c (handle_omp_for_class_iterator): Don't call cp_fully_fold on cond. * g++.dg/gomp/pr92504.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/gomp/pr92504.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/semantics.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/92537] [10 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:2775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92537 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Nov 20 10:40:09 2019 New Revision: 278494 URL: https://gcc.gnu.org/viewcvs?rev=278494=gcc=rev Log: 2019-11-20 Richard Biener PR tree-optimization/92537 * tree-vect-slp.c (vect_analyze_slp_instance): Move CTOR vectorization validity check... (vect_slp_analyze_operations): ... here. * gfortran.dg/pr92537.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr92537.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug c++/92593] [10 Regression] ICE with CTAD using undeclared constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92593
Jonathan Wakely changed:
What|Removed |Added
Keywords||needs-bisection
Known to work||9.2.1
Summary|ICE with CTAD using |[10 Regression] ICE with
|undeclared constraint |CTAD using undeclared
||constraint
Known to fail||10.0
--- Comment #1 from Jonathan Wakely ---
With GCC 9 and -std=gnu++2a -fconcepts there's no ICE:
ice.cc:1:10: error: 'integral' has not been declared
1 | template // oops, should be std::integral
| ^~~~
ice.cc:4:11: warning: unnecessary parentheses in declaration of 'T'
[-Wparentheses]
4 | ref_view(T) { }
| ^
ice.cc:4:17: error: expected ';' at end of member declaration
4 | ref_view(T) { }
| ^
| ;
ice.cc:7:13: error: class template argument deduction failed:
7 | ref_view r{1};
| ^
ice.cc:7:13: error: no matching function for call to 'ref_view(int)'
ice.cc:2:8: note: candidate: 'template< >
ref_view(ref_view< >)-> ref_view< >'
2 | struct ref_view
|^~~~
ice.cc:2:8: note: template argument deduction/substitution failed:
[Bug c++/92594] New: [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92594
Bug ID: 92594
Summary: [10 Regression] internal compiler error: in
build_value_init_noctor, at cp/init.c:400 using
std::tuple
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
the following code ices on me:
```
template struct tuple {
tuple() : _M_head_impl() {}
_Head _M_head_impl;
};
template struct pod_tuple { type0 _head; };
struct e {};
struct bar : e {
using e::e;
};
int main() { tuple> a; }
```
with
```
> g++-git -std=c++17 -c ice.cpp
ice.cpp: In instantiation of ‘tuple<_Head>::tuple() [with _Head =
pod_tuple]’:
ice.cpp:10:36: required from here
ice.cpp:2:26: internal compiler error: in build_value_init_noctor, at
cp/init.c:400
2 | tuple() : _M_head_impl() {}
| ^
0x5ddd2b build_value_init_noctor(tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:400
0x6ab8f5 build_value_init(tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:379
0x6b1c46 perform_member_init
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:810
0x6b1c46 emit_mem_initializers(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:1374
0x7365b4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17529
0x734c5a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17509
0x734c5a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17826
0x7341fc tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17509
0x7341fc instantiate_decl(tree_node*, bool, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:25312
0x7532eb instantiate_pending_templates(int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:25428
0x699aa0 c_parse_final_cleanups()
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/decl2.c:4848
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/91333] [9/10 Regression] suboptimal register allocation for inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-20 CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- For -O2, I actually can't reproduce, all revisions I've tried emit just addsd. For -O1, this regressed with r270060. And while for -O3 it also regressed in the same revision, starting with r274994 it is again a single addsd.
[Bug tree-optimization/92537] [10 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:2775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92537 --- Comment #6 from Richard Biener --- One issue that I think can pop up with the way we now make nodes built from scalars (aka turn them into externs) is that it can possibly invalidate earlier validation of other SLP instances. It's probably not the case here though, a way out if we run into this issue would be to unshare the node we are externalizing. There is for example vectorizable_shift which is asymmetric in what it supports as shift argument (but it favors externs here, being less capable for internal defs - but eventually there's the opposite case elsewhere unless we'd decleare that a bug). Testing patch.
[Bug middle-end/91195] [10 regression] incorrect may be used uninitialized smw (272711, 273474]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91195 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 08:26:52 2019 New Revision: 278479 URL: https://gcc.gnu.org/viewcvs?rev=278479=gcc=rev Log: PR middle-end/91195 * tree-ssa-phiopt.c (cond_store_replacement): Move lhs unsharing earlier. Set TREE_NO_WARNING on the rhs1 of the artificially added load. * gcc.dg/pr91195.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr91195.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 92584, which changed state. Bug 92584 Summary: A 454.calculix optimization opportunity https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/92584] A 454.calculix optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Biener --- (In reply to Martin Liška from comment #4) > > > > I've tried multiple times to no avail ... :/ But yeah. I'll have another > > look ;) It's gfortran.dg/reassoc_4.f btw. IIRC. See also the > > --param adjustment therein ... Honza lowered the param at some point, > > regressing things. > > Hehe, that's good that we have it isolated as a test-case. Ah, FDO. Well, the train run is completely different from the ref one so FDO performance is notoriously bad for calculix.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #16 from Florian Weimer --- (In reply to rdapp from comment #15) > Any feedback on the two options I proposed? Is the .S file variant (I posted > last) ok? I'd prefer the patch from comment 13, but I'm not a GCC developer. You should post the patch to gcc-patches. I don't know enough about the architecture to review the CFI annotations for correctness, sorry.
[Bug middle-end/90840] [8/9 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 09:55:01 2019 New Revision: 278491 URL: https://gcc.gnu.org/viewcvs?rev=278491=gcc=rev Log: PR middle-end/90840 * expmed.c (store_bit_field_1): Handle the case where op0 is not a MEM and has a mode that doesn't have corresponding integral type. * gcc.c-torture/compile/pr90840.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/pr90840.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/expmed.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/90867] [8/9 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 20 09:54:02 2019
New Revision: 278490
URL: https://gcc.gnu.org/viewcvs?rev=278490=gcc=rev
Log:
PR target/90867
* config/i386/i386.c (ix86_valid_target_attribute_tree): Don't
clear opts->x_ix86_isa_flags{,2} here...
(ix86_valid_target_attribute_inner_p): ... but here when seeing
arch=. Also clear opts->x_ix86_isa_flags{,2}_explicit.
* gcc.target/i386/pr90867.c: New test.
Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr90867.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/i386/i386.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/90796] [8/9 Regression] GCC: O2 vs O3 output differs on simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- Time to backport now?
[Bug c++/90767] [9/10 Regression] jumbled error message with this and const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Nov 20 08:33:56 2019 New Revision: 278484 URL: https://gcc.gnu.org/viewcvs?rev=278484=gcc=rev Log: PR c++/90767 * call.c (complain_about_no_candidates_for_method_call): If conv->from is not a type, pass to complain_about_bad_argument lvalue_type of conv->from. * g++.dg/diagnostic/pr90767-1.C: New test. * g++.dg/diagnostic/pr90767-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr90767-1.C trunk/gcc/testsuite/g++.dg/diagnostic/pr90767-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/92584] A 454.calculix optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 --- Comment #3 from rguenther at suse dot de --- On Wed, 20 Nov 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 > > --- Comment #2 from Martin Liška --- > (In reply to rguent...@suse.de from comment #1) > > On Tue, 19 Nov 2019, marxin at gcc dot gnu.org wrote: > > > > > I noticed that the speed drop back on the trunk happened since r278281. > > > Would you be interested in what loop optimization made the difference? > > > > Well, the revs probably caused changes in (early) unrolling with the > > better performance seen with less unrolling. We know that even more > > unrolling will increase performance though. > > Ok, so the benchmark likes unrolling :) > > > > > Not sure what you are asking? > > My question is simple: Can we somehow tweak our defaults so that we can speed > up calculix. Note that the speed up is 2x. I've tried multiple times to no avail ... :/ But yeah. I'll have another look ;) It's gfortran.dg/reassoc_4.f btw. IIRC. See also the --param adjustment therein ... Honza lowered the param at some point, regressing things.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #15 from rdapp at linux dot ibm.com --- Any feedback on the two options I proposed? Is the .S file variant (I posted last) ok?
[Bug target/92534] [10 regression] gcc.dg/vect/bb-slp-42.c fails after r278262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92534 Kewen Lin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Kewen Lin --- This is related to the realign vector load. It only fail with -mno-allow-movmisalign (which is disabled from Power8), I can't see the abort if I specified the option explicitly on Power8. The generated IR below is incorrect: vectp.43_73 = [(int *)b_17(D) + 4B]; vect__160.44_21 = __builtin_altivec_mask_for_load (vectp.43_73); ==> Here we use the vectp.43_73 (b+4), this is unexpected. vectp.46_20 = [(int *)b_17(D) + 4B]; vectp.46_19 = vectp.46_20 + 18446744073709551612; ==> Here we use the vectp.46_19 (b) vectp.46_18 = vectp.46_19 & -16B; vect__160.47_206 = MEM [(int *)vectp.46_18]; vectp.46_207 = vectp.46_19 + 15; ==> Here we use the vectp.46_19 (b) + 15 vectp.46_208 = vectp.46_207 & -16B; vect__160.48_209 = MEM [(int *)vectp.46_208]; vect__160.49_210 = REALIGN_LOAD ; vect__144.50_211 = VEC_PERM_EXPR ; If I adjusted it as the below code, it can pass. msq = vect_setup_realignment (first_stmt_info_for_drptr && !slp_perm ? first_stmt_info_for_drptr : first_stmt_info, gsi, _token, alignment_support_scheme, NULL_TREE, _loop); Need more time to figure out it's reasonable.
[Bug c++/90767] [9 Regression] jumbled error message with this and const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug c/90898] [8 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |insert_clobber_before_stack |insert_clobber_before_stack |_restore, at|_restore, at |tree-ssa-ccp.c:2112 |tree-ssa-ccp.c:2112 --- Comment #7 from Jakub Jelinek --- Fixed for 9.3+ too.
[Bug jit/92483] [10 Regression] many jit test failures due to ABRT, SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92483
--- Comment #1 from David Malcolm ---
Author: dmalcolm
Date: Wed Nov 20 17:51:41 2019
New Revision: 278515
URL: https://gcc.gnu.org/viewcvs?rev=278515=gcc=rev
Log:
jit: fix ICE with GCC_JIT_BOOL_OPTION_SELFCHECK_GC since r278084 (PR jit/92483)
Since r278084 (part of the params refactoring), most of libgccjit's
test suite has been ICEing.
The root cause is that jit-playback.c injects params to its fake_args
here:
/* Aggressively garbage-collect, to shake out bugs: */
if (get_bool_option (GCC_JIT_BOOL_OPTION_SELFCHECK_GC))
{
ADD_ARG ("--param");
ADD_ARG ("ggc-min-expand=0");
ADD_ARG ("--param");
ADD_ARG ("ggc-min-heapsize=0");
}
(building a vec of char * where the char * are allocated using xstrdup)
and r278084 added this logic to decode_cmdline_options_to_array:
964 /* Interpret "--param" "key=name" as "--param=key=name". */
965 const char *needle = "--param";
966 if (i + 1 < argc && strcmp (opt, needle) == 0)
967 {
968 const char *replacement
969 = opts_concat (needle, "=", argv[i + 1], NULL);
970 argv[++i] = replacement;
971 }
Note that at line 970 it manipulates the argv in-place, inserting a
new option allocated with opts_concat, which uses opts_obstack
(itself initialized from toplev::main).
jit-playback.c cleans up its fake arguments using "free", at which
point we have a free of the middle of an obstack and an ICE.
This patch fixes the issue by using the new syntax for the params.
Fixes all 60 FAILs in jit.sum, restoring the number of PASS results
from 2033 to 10469.
gcc/jit/ChangeLog:
PR jit/92483
* jit-playback.c (gcc::jit::playback::context::make_fake_args):
Update GCC_JIT_BOOL_OPTION_SELFCHECK_GC for new --param syntax.
Modified:
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/jit-playback.c
[Bug ipa/92109] [10 Regression] ICE in modify_call_stmt, at ipa-param-manipulation.c:1586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92109
--- Comment #6 from Martin Jambor ---
So this helps:
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index bfcebb20495..359ea53d8a6 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -1079,6 +1079,7 @@ symbol_table::materialize_all_clones (void)
FOR_EACH_FUNCTION (node)
{
if (node->clone_of && node->decl != node->clone_of->decl
+ && !node->in_other_partition
&& !gimple_has_body_p (node->decl))
{
if (!node->clone_of->clone_of)
but I a doubt it is a safe thing to do (inline clones of a clone
probably can happen to be in a different ltrans than the offline clone
and then this will break) but it IMHO shows that the materialization
of this clone in this ltrans in this particular case is useless.
Hm, perhaps the following should work?
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index bfcebb20495..cc689d3d386 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -1079,6 +1079,7 @@ symbol_table::materialize_all_clones (void)
FOR_EACH_FUNCTION (node)
{
if (node->clone_of && node->decl != node->clone_of->decl
+ && (!node->body_removed || !node->in_other_partition)
&& !gimple_has_body_p (node->decl))
{
if (!node->clone_of->clone_of)
I'll see what breaks when I change the flag body_removed to mean what
it says (i.e. node->release_body really was called) first though.
[Bug other/92090] [10 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- So fixed in trunk, waiting for backports?
[Bug target/92592] Redundant comparison after subtraction on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92592 --- Comment #3 from Marc Glisse --- IFN_SUB_OVERFLOW recognition?
[Bug target/91702] [9/10 Regression] ICE with mips16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91702 --- Comment #5 from Dragan Mladjenovic --- Yes, I believe so.
[Bug target/91494] Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91494 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- duplicate. *** This bug has been marked as a duplicate of bug 91433 ***
[Bug tree-optimization/91355] [8/9/10 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
||rth at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
I'm afraid I don't know enough of the EH rules on what's wrong, so will just
try to describe what happens:
;; basic block 3, loop depth 0
;;pred: 2
_10 = __cxa_allocate_exception (4);
MEM[(int *)_10] = 3;
__cxa_throw (_10, &_ZTIi, 0B);
;;succ: 6
;; basic block 4, loop depth 0
;;pred: 2
d.0_14 = d;
_15 = d.0_14 + 1;
d = _15;
_6 = __cxa_allocate_exception (4);
MEM[(int *)_6] = 3;
__cxa_throw (_6, &_ZTIi, 0B);
;;succ: 5
;; basic block 5, loop depth 0
;;pred: 4
:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
resx 4
;;succ: 6
;; basic block 6, loop depth 0
;;pred: 3
;;5
:
_20 = __builtin_eh_filter (1);
if (_20 == -1)
goto ; [0.00%]
else
goto ; [0.00%]
;;succ: 8
;;7
Now, if not -fno-tree-sink or Honza's change is in, sink changes that to:
;; basic block 5, loop depth 0, count 0 (precise), probably never executed
;;prev block 4, next block 10, flags: (NEW, REACHABLE, VISITED)
;;pred: 4 [never] count:0 (precise) (EH,EXECUTABLE)
:
resx 4
;;succ: 10 [never] count:0 (precise) (EH,EXECUTABLE)
;; basic block 10, loop depth 0, count 0 (precise), probably never executed
;;prev block 5, next block 9, flags: (NEW)
;;pred: 5 [never] count:0 (precise) (EH,EXECUTABLE)
:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
goto ; [100.00%]
;;succ: 6 [always] count:0 (precise) (FALLTHRU)
;; basic block 9, loop depth 0, count 0 (precise), probably never executed
;;prev block 10, next block 6, flags: (NEW)
;;pred: 3 [never] count:0 (precise) (EH,EXECUTABLE)
:
;;succ: 6 [always] count:0 (precise) (FALLTHRU)
;; basic block 6, loop depth 0, count 0 (precise), probably never executed
;;prev block 9, next block 7, flags: (NEW, REACHABLE, VISITED)
;;pred: 9 [always] count:0 (precise) (FALLTHRU)
;;10 [always] count:0 (precise) (FALLTHRU)
:
_20 = __builtin_eh_filter (1);
if (_20 == -1)
goto ; [0.00%]
else
goto ; [0.00%]
;;succ: 8 [never] count:0 (precise) (TRUE_VALUE,EXECUTABLE)
;;7 [never] count:0 (precise) (FALSE_VALUE,EXECUTABLE)
Before ehcleanup2 the difference is then (-fno-tree-sink -O1 vs. -ftree-sink
-O1):
;; basic block 5, loop depth 0
;;pred: 4
:
- d.1_16 = d;
- _17 = d.1_16 + 4294967295;
- d = _17;
resx 4
;;succ: 6
;; basic block 6, loop depth 0
+;;pred: 5
+:
+ d.1_16 = d;
+ _17 = d.1_16 + 4294967295;
+ d = _17;
+ goto ; [100.00%]
+;;succ: 8
+
+;; basic block 7, loop depth 0
;;pred: 3
-;;5
+:
+;;succ: 8
+
+;; basic block 8, loop depth 0
+;;pred: 7
+;;6
:
_20 = __builtin_eh_filter (1);
Now, ehcleanup2 removes resx 4; for some reason:
Before removal of unreachable regions:
Eh tree:
- 1 allowed_exceptions land:{1,},{3,} filter :-1 types:int
+ 1 allowed_exceptions land:{4,},{1,},{3,} filter :-1 types:int
4 cleanup land:{2,}
Reachable regions: n_bits = 8, set = {1 4 }
-Reachable landing pads: n_bits = 4, set = {1 2 }
+Reachable landing pads: n_bits = 5, set = {1 2 4 }
Removing unreachable landing pad 3
After removal of unreachable regions:
Eh tree:
- 1 allowed_exceptions land:{1,} filter :-1 types:int
+ 1 allowed_exceptions land:{4,},{1,} filter :-1 types:int
4 cleanup land:{2,}
+Removing basic block 7
+Removing basic block 5
+Removing unreachable region 4
...
;; basic block 5, loop depth 0
;;pred: 4
-:
+:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
- resx 4
;;succ: 6
and in *.optimized dump that means:
;; basic block 5, loop depth 0
;;pred: 4
-:
+:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
- __builtin_eh_copy_values (1, 4);
;;succ: 6
change and abort.
[Bug c++/92593] [10 Regression] ICE with CTAD using undeclared constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92593 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #2 from Andrew Sutton --- It looks like the deduction isn't failing appropriately. The compiler things the declaration of r has type "ref_view<>", which is apparently causing infinite recursion in a call to reshape_init_class.
[Bug target/92573] [10 Regression] ICE in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92573 --- Comment #1 from Segher Boessenkool --- Author: segher Date: Wed Nov 20 13:38:52 2019 New Revision: 278497 URL: https://gcc.gnu.org/viewcvs?rev=278497=gcc=rev Log: rs6000: Fix UNORDERED without NaNs, for DFP (PR92573) This is the analogue of r278103, but for DFP. PR target/92573 * config/rs6000/dfp.md (dfptstsfi__ for DFP_TEST and DDTD): Handle UNORDERED if !HONOR_NANS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/dfp.md
[Bug rtl-optimization/91161] [9/10 Regression] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
--- Comment #3 from Alexander Monakov ---
With -fno-dce, a NOTE_INSN_DELETED_LABEL appears between the last "real" insn
in the basic block (a sibcall) and a barrier rtx:
(call_insn/u/c 20 19 12 3 (call (mem:QI (symbol_ref:DI ("ni") [flags 0x3]
) [0 ni S1 A8])
(const_int 0 [0])) "pr91161.c":23:7 679 {*call}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:QI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("ni") [flags 0x3]
)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list (use (reg:QI 0 ax))
(expr_list:DI (use (reg:DI 5 di))
(nil
(note 12 20 21 ("x6") NOTE_INSN_DELETED_LABEL 5)
(barrier 21 12 22)
Is this valid? I assume NOTE_INSN_DELETED can appear in that position as well?
If so, shouldn't begin_move_insn use next_nonnote_insn rather than plain
NEXT_INSN to find either the barrier or the label of the next bb?
[Bug libgomp/92511] [OpenACC] Support subset subarray mappings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92511 --- Comment #2 from jules at gcc dot gnu.org --- Author: jules Date: Wed Nov 20 17:51:09 2019 New Revision: 278514 URL: https://gcc.gnu.org/viewcvs?rev=278514=gcc=rev Log: OpenACC "present" subarrays: runtime API return value and unmapping fixes PR libgomp/92511 libgomp/ * oacc-mem.c (present_create_copy): Fix device pointer return value in case of "present" subarray. Use tgt->tgt_start instead of tgt->to_free in non-present/create case. (delete_copyout): Change error condition to fail only on copies outside of mapped block. Adjust error message accordingly. * testsuite/libgomp.oacc-c-c++-common/copyin-devptr-1.c: New test. * testsuite/libgomp.oacc-c-c++-common/copyin-devptr-2.c: New test. * testsuite/libgomp.oacc-c-c++-common/lib-20.c: Adjust expected error message. * testsuite/libgomp.oacc-c-c++-common/lib-23.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-22.c: Allow test to pass now. * testsuite/libgomp.oacc-c-c++-common/lib-30.c: Likewise. Reviewed-by: Thomas Schwinge Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/copyin-devptr-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/copyin-devptr-2.c Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-mem.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-20.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-23.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c
[Bug jit/92483] [10 Regression] many jit test failures due to ABRT, SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92483 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Should be fixed by r278515.
[Bug c++/92601] New: error: type variant differs by TYPE_NEEDS_CONSTRUCTING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92601
Bug ID: 92601
Summary: error: type variant differs by TYPE_NEEDS_CONSTRUCTING
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Happens for the following test-case:
$ cat verify.ii
typedef int size_t;
template struct integral_constant {
static constexpr int value = __v;
};
template struct A;
template using __remove_cv_t = typename A<_Tp>::type;
template
struct B : integral_constant {};
template class tuple;
template struct A {
using type = tuple;
};
template struct C { typedef __remove_cv_t __type; };
template class D {
public:
typedef typename C<_Tp>::__type type;
};
template struct enable_if;
template struct F {};
template class G {
public:
int operator*();
void operator++();
};
template
bool operator!=(G<_Iterator, _Container>, G<_Iterator, _Container>);
template class H;
template >> class vector {
public:
typedef G iterator;
iterator begin();
iterator end();
};
template struct pack_c { typedef pack_c type; };
template struct make_index_pack_join;
template
struct make_index_pack_join, pack_c>
: pack_c {};
template
struct I
: make_index_pack_join::type, typename I::type>
{};
template <> struct I<1> : pack_c {};
template
struct are_tuples_compatible_not_same
: F::type, int>::value> {};
template struct tuple_impl;
template
struct tuple_impl, Ts...> {
template , UTuple>::value>::type>
tuple_impl(UTuple &&);
};
template class tuple {
tuple_impl::type> _impl;
tuple(tuple &) = default;
};
vector message_handler_registrations;
void fn1() {
for (auto t : message_handler_registrations)
;
}
$ g++ -std=c++17 -fchecking verify.ii -c -g
verify.ii: In instantiation of ‘struct C >’:
verify.ii:16:35: required from ‘class D >’
verify.ii:44:8: required from ‘struct are_tuples_compatible_not_same,
tuple_impl >&>’
verify.ii:50:60: required by substitution of ‘template, UTuple>::value>::type
> tuple_impl >::tuple_impl(UTuple&&) [with UTuple =
tuple_impl >&; typename
enable_if, UTuple>::value>::type
= ]’
verify.ii:53:33: required from ‘class tuple’
verify.ii:59:17: required from here
verify.ii:13:28: error: type variant differs by TYPE_NEEDS_CONSTRUCTING
13 | template struct C { typedef __remove_cv_t __type; };
|^
unit-size
align:8 warn_if_not_align:0 symtab:-1658842336 alias-set -1
canonical-type 0x7fe19d202738 fields
context
full-name "struct tuple_impl >"
needs-constructor X(constX&) this=(X&) n_parents=0 use_template=1
interface-unknown
pointer_to_this reference_to_this
chain >
private nonlocal decl_3 VOID verify.ii:54:47
align:1 warn_if_not_align:0 offset_align 1 context
chain
public private external autoinline QI verify.ii:55:3 align:16
warn_if_not_align:0 context
full-name "tuple< >::tuple(tuple<
>&) [with Ts = {const char*, const char*}]"
template-info 0x7fe19d204bc0 chain >> context
full-name "class tuple"
needs-constructor X(X&) this=(X&) n_parents=0 use_template=1
interface-unknown
pointer_to_this reference_to_this
chain >
full-name "__remove_cv_t"
X(X&) this=(X&) n_parents=0 use_template=1 interface-unknown
chain >
verify.ii:13: confused by earlier errors, bailing out
$ g++ -std=c++17 -fchecking verify.ii -c
is fine, started with r258964, before that the code was rejected.
[Bug c++/92601] error: type variant differs by TYPE_NEEDS_CONSTRUCTING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92601 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-20 Target Milestone|--- |9.3 Ever confirmed|0 |1 Known to fail||10.0, 9.2.0
[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Wed Nov 20 20:01:25 2019 New Revision: 278523 URL: https://gcc.gnu.org/viewcvs?rev=278523=gcc=rev Log: PR 92463 MPFR modernization in GFortran Now that we require a minimum of MPFR 3.1.0+ to build GCC, we can do some modernization of the MPFR usage in the GFortran frontend. This patch replaces 1) GMP_RND* with MPFR_RND* 2) mp_exp_t with mpfr_exp_t 3) mp_prec_t with mpfr_prec_t 4) mp_rnd_t with mpfr_rnd_t gcc/fortran/ChangeLog: 2019-11-20 Janne Blomqvist PR fortran/92463 * arith.c (gfc_mpfr_to_mpz): Change mp_exp_t to mpfr_exp_t. (gfc_check_real_range): Likewise. * gfortran.h (GFC_RND_MODE): Change GMP_RNDN to MPFR_RNDN. * module.c (mio_gmp_real): Change mp_exp_t to mpfr_exp_t. * simplify.c (degrees_f): Change mp_rnd_t to mpfr_rnd_t. (radians_f): Likewise. (fullprec_erfc_scaled): Change mp_prec_t to mpfr_prec_t. (asympt_erfc_scaled): Likewise. (gfc_simplify_nearest): Change mp_exp_t to mpfr_exp_t, and GMP_RND* to MPFR_RND*. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/simplify.c
[Bug tree-optimization/92152] [10 Regression] Wrong code (Resurrection of PR53663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152 --- Comment #6 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #5) > Indeed, following testcase aborts on x86_64-linux with -O2/-O3/-Os and > succeeds with -O0/-O1/-Og: That testcase reminds me of 14319.
[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858 --- Comment #3 from Jakub Jelinek --- Reduced testcase: _Complex float f = __builtin_ctanf (1.0f + 1.0if);
[Bug c++/91706] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91706
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
template struct A;
template struct B;
struct C {
template static int c ();
};
template struct D : C {
using c = decltype (c);
using E = typename A::E;
};
D> g;
Without -g this is a accepts-invalid.
[Bug other/92090] [8/9 regression] ICE in gcc.dg/atomic/c11-atomic-exec-5.c starting with r276469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090 Segher Boessenkool changed: What|Removed |Added Known to work||10.0 Summary|[10 regression] ICE in |[8/9 regression] ICE in |gcc.dg/atomic/c11-atomic-ex |gcc.dg/atomic/c11-atomic-ex |ec-5.c starting with|ec-5.c starting with |r276469 |r276469 Known to fail|10.0| --- Comment #17 from Segher Boessenkool --- Yes.
[Bug target/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071 --- Comment #4 from Jakub Jelinek --- I'd say this should be fixed in the arm backend, instead of asserts it should check whether operands are aligned and if not, perform unaligned load or store, because the amount of spots in the middle-end that actually just call emit_move_insn when they see a MEM is huge.
[Bug tree-optimization/92152] [10 Regression] Wrong code (Resurrection of PR53663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Indeed, following testcase aborts on x86_64-linux with -O2/-O3/-Os and succeeds
with -O0/-O1/-Og:
union U
{
long long i;
long f;
} v;
long
foo (long *f)
{
*f = 1;
v.i = 0;
v.f = 0;
return *f;
}
int
main ()
{
if (foo () != 0)
__builtin_abort ();
return 0;
}
Started with r271813.
[Bug target/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Cleaned up reduced testcase, still ICEs with current trunk at -O2:
void *a;
union U { double c; char d[8]; };
void bar (union U);
void
foo (void)
{
union U b;
__builtin_memcpy (b.d, a, 8);
bar (b);
}
[Bug target/91702] [9/10 Regression] ICE with mips16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91702 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- .
[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 --- Comment #3 from Janne Blomqvist --- Author: jb Date: Wed Nov 20 20:08:29 2019 New Revision: 278525 URL: https://gcc.gnu.org/viewcvs?rev=278525=gcc=rev Log: PR 92463 MPFR modernization: Revert r269139 Commit r269139 fixed an accidental dependency on MPFR 3.0. As we now require at least MPFR 3.1.0+ we can revert it and instead use the simpler MPFR 3.0+ code. ChangeLog entry of the original commit was: 2019-02-23 David Malcolm Jakub Jelinek PR middle-end/88074 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p. (norm2_add_squared): Likewise. Use mp_exp_t rather than mpfr_exp_t. ChangeLog for this commit: 2019-11-20 Janne Blomqvist PR fortran/92463 Revert r269139 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_regular_p instead of mpfr_number_p && !mpfr_zero_p. (norm2_add_squared): Likewise. Use mpfr_exp_t rather than mp_exp_t. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
[Bug tree-optimization/88074] [7 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 --- Comment #38 from Janne Blomqvist --- Author: jb Date: Wed Nov 20 20:08:29 2019 New Revision: 278525 URL: https://gcc.gnu.org/viewcvs?rev=278525=gcc=rev Log: PR 92463 MPFR modernization: Revert r269139 Commit r269139 fixed an accidental dependency on MPFR 3.0. As we now require at least MPFR 3.1.0+ we can revert it and instead use the simpler MPFR 3.0+ code. ChangeLog entry of the original commit was: 2019-02-23 David Malcolm Jakub Jelinek PR middle-end/88074 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p. (norm2_add_squared): Likewise. Use mp_exp_t rather than mpfr_exp_t. ChangeLog for this commit: 2019-11-20 Janne Blomqvist PR fortran/92463 Revert r269139 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_regular_p instead of mpfr_number_p && !mpfr_zero_p. (norm2_add_squared): Likewise. Use mpfr_exp_t rather than mp_exp_t. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
[Bug c++/92597] std::fma gives nan using -march=sandybridge+ with asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Using r constraint for long double doesn't make much sense, long double on ix86 is something that can be held in memory or i387 stack, but you don't want that in GPRs. "+m" works, so does "+g". With "+m" it works because the constant is forced into memory and thus the memory is naturally matching, "+g" is internally turned into "=g" and "0" and so ends up matching too, but "+m,r" is internally turned into "=m,r" "m,0" rather than "=m,r" "0,0" and so the memory can be different and is in this case, the input (i.e. %1) is .rodata memory with the constant and output (i.e. %0) is some stack slot.
