[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223 Bug 45223 depends on bug 42108, which changed state. Bug 42108 Summary: [4.9 Regression] 50% performance regression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/42108] [4.9 Regression] 50% performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.4 |5.0 Known to fail||4.9.3 --- Comment #73 from Richard Biener --- (In reply to Dominique d'Humieres from comment #72) > > Fixed on trunk (solar). > > Any plan for 4.9 or should this PR closed as FIXED? I don't plan backporting this unless FE maintainers insist so let's close as fixed.
[Bug tree-optimization/69720] [4.9/5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69720 Richard Biener changed: What|Removed |Added Known to work||6.0 Summary|[4.9/5/6 Regression] wrong |[4.9/5 Regression] wrong |code at -O3 on |code at -O3 on |x86_64-linux-gnu|x86_64-linux-gnu Known to fail|6.0 | --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/69999] [6 Regression] ICE in verify_loop_structure, at cfgloop.c:1639 (error: loop with header 3 not in loop tree) at -O3 or -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/69995] [5/6 Regression] [C++14] Invalid result when evaluating constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.4
[Bug target/69994] [6 regression] test case gfortran.dg/reassoc_6.f fails starting with r233669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-29 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a looksee.
[Bug tree-optimization/69991] missed tail merge optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69991 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug ipa/69990] decl alignment not respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69990 Richard Biener changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #4 from Richard Biener --- I think this looks reasonable. OTOH we might simply choose to prevail the decl with bigger alignment?
[Bug ipa/69990] [5/6 Regression] decl alignment not respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69990 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |5.4 Summary|decl alignment not |[5/6 Regression] decl |respected |alignment not respected
[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989 --- Comment #9 from Richard Biener --- (In reply to Jeffrey A. Law from comment #3) > WRT fallout and reverting on the gcc-5 branch. Based on what I'm seeing, > that may make sense. > > The problem in this particular case is we've marked loops for fixup, then > loop distribution is explicitly calling checking_verify_loop_structure. > > checking_verify_loop_structure will assert that loops do not need fixup, and > of course, that assertion fails. There's at least a half-dozen of these > explicit calls that can fail in a similar manner. > > I'm going to poke a bit, but my inclination is to pull the patch from the > trunk and the branch. Well, the remove_edge hook is very low-level so all the intelligent adjustments we do in higher level cfg hooks may now get spurious fixups. For example what loop distribution does should never get you more loops and the checking_verify_loop_structure is supposed to check for that ... [I've always chickened to add auto handling to the very low level CFG hooks... eventually we might want to guard that in a way to only trigger on non-loop passes or make high level CFG ops call _raw low-level workers avoiding those updates] I will have a look myself as well.
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/69983] [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-29 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug target/70012] test case gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012 --- Comment #1 from Richard Biener --- Might be a testsuite artifact in not reaching the cost model check but rejecting vectorization earlier (try bumping N to 32, after peeling for alignment no vectorized iteration would be left so we don't peel for alignment anymore thus we can't handle the store).
[Bug target/70011] [6 regression] test case gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #2 from Richard Biener --- Unfortunately the testcase doesn't tell why it's not profitable to vectorize this. Is it vectorized now?
[Bug target/70007] [4.9/5/6 Regression] wrong code with -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug tree-optimization/70005] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug c++/70001] [5/6 regression] Infinity compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70001 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.4 Summary|[5 regression] Infinity |[5/6 regression] Infinity |compilation time|compilation time
[Bug target/69706] internal compiler error: in extract_constrain_insn, at recog.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706 --- Comment #9 from Eric Botcazou --- Author: ebotcazou Date: Mon Feb 29 10:20:31 2016 New Revision: 233808 URL: https://gcc.gnu.org/viewcvs?rev=233808&root=gcc&view=rev Log: PR target/69706 * config/sparc/sparc.c (ROUND_ADVANCE): Rename to... (NWORDS_UP): ...this (init_cumulative_args): Minor tweaks. (sparc_promote_function_mode): Likewise. (scan_record_type): Delete. (traverse_record_type): New function template. (classify_data_t): New structure type. (classify_registers): New inline function. (function_arg_slotno): In 64-bit mode, bail out early if FP slots are exhausted. Instantiate traverse_record_type on classify_registers and deal with the case of a structure passed in slot #15 with no FP field in the first word. (assign_data_t): New structure type. (compute_int_layout): New static function. (compute_fp_layout): Likewise. (count_registers): New inline function. (assign_int_registers): New static function. (assign_fp_registers): Likewise. (assign_registers): New inline function. (function_arg_record_value_1): Delete. (function_arg_record_value_2): Likewise. (function_arg_record_value_3): Likewise. (function_arg_record_value): Adjust to above changes. Instantiate traverse_record_type on count_registers to first count the number of registers to be used and then on assign_registers to assign them. (function_arg_union_value): Adjust to above renaming. (sparc_function_arg_1); Minor tweaks. Remove commented out code. (sparc_arg_partial_bytes): Adjust to above renaming. Deal with the case of a structure passed in slot #15 (sparc_function_arg_advance): Likewise. (function_arg_padding): Minor tweak. Added: trunk/gcc/testsuite/gcc.target/sparc/20160229-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/testsuite/ChangeLog
[Bug c/69972] duplicate integer overflow diagnostic in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69972 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/70007] [4.9/5/6 Regression] wrong code with -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007
--- Comment #1 from Uroš Bizjak ---
PRE pass is moving (insn 7) out of the loop. Before the transformation, we
have:
(code_label 84 2 5 3 2 "" [1 uses])
(note 5 84 6 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 6 5 7 3 (set (reg:DI 117 [ v32u64_1+24 ])
(mem/j/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])) pr70007.c:10 85
{*movdi_internal}
(nil))
(insn 7 6 8 3 (parallel [
(set (reg:DI 88 [ _4 ])
(rotatert:DI (reg:DI 117 [ v32u64_1+24 ])
(const_int 19 [0x13])))
(clobber (reg:CC 17 flags))
]) pr70007.c:10 607 {*rotrdi3_1}
(expr_list:REG_DEAD (reg:DI 117 [ v32u64_1+24 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (rotatert:DI (mem/j/c:DI (plus:DI (reg/f:DI 16
argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(const_int 19 [0x13]))
(nil)
But PRE pass moves this insn out of the loop, although we have update of
[argp+88] memory location inside the loop:
(note 3 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 113 2 NOTE_INSN_FUNCTION_BEG)
(insn 113 2 116 2 (set (reg:DI 183 [ v32u64_1+24 ])
(mem/j/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])) -1
(nil))
(insn 116 113 117 2 (set (reg:DI 178 [ _4 ])
(rotatert:DI (mem/j/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(const_int 19 [0x13]))) 603 {*bmi2_rorxdi3_1}
(nil))
...
(code_label 84 125 5 3 2 "" [1 uses])
(note 5 84 110 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 110 5 104 3 (set (reg:DI 117 [ v32u64_1+24 ])
(reg:DI 183 [ v32u64_1+24 ])) pr70007.c:10 -1
(expr_list:REG_EQUAL (mem/j/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(nil)))
(insn 104 110 115 3 (set (reg:DI 88 [ _4 ])
(reg:DI 178 [ _4 ])) pr70007.c:10 -1
(expr_list:REG_EQUAL (rotatert:DI (mem/j/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(const_int 19 [0x13]))
(nil)))
(insn 8 115 9 3 (set (mem/j/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(reg:DI 183 [ v32u64_1+24 ])) pr70007.c:10 -1
(nil))
...
(insn 45 114 107 3 (set (mem/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(reg:DI 183 [ v32u64_1+24 ])) pr70007.c:11 -1
(expr_list:REG_DEAD (reg:DI 142)
(nil)))
...
(jump_insn 87 86 88 3 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 84)
(pc))) pr70007.c:13 635 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 9100 (nil)))
-> 84)
...
(note 88 87 109 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 109 88 101 4 (set (reg:DI 173 [ v32u64_1+24 ])
(reg:DI 183 [ v32u64_1+24 ])) pr70007.c:14 -1
(expr_list:REG_EQUAL (mem/j/c:DI (plus:DI (reg/f:DI 16 argp)
(const_int 88 [0x58])) [1 v32u64_1+24 S8 A64])
(nil)))
...
Moving rorx insn after .L2 label, IOW changing:
rorx$19, 160(%rsp), %r8
movq136(%rsp), %rax
movq144(%rsp), %rdi
movq152(%rsp), %rsi
movq72(%rsp), %r12
movq80(%rsp), %rbp
movq88(%rsp), %rbx
pcmpeqd %xmm6, %xmm6
.L2:
orw %r8w, 98(%rsp)
...
movq%rdx, 160(%rsp)
...
to:
movq136(%rsp), %rax
movq144(%rsp), %rdi
movq152(%rsp), %rsi
movq72(%rsp), %r12
movq80(%rsp), %rbp
movq88(%rsp), %rbx
pcmpeqd %xmm6, %xmm6
.L2:
rorx$19, 160(%rsp), %r8
orw %r8w, 98(%rsp)
...
movq%rdx, 160(%rsp)
...
fixes the testcase.
(BTW:
rorx$19, 160(%rsp), %r8
can be substituted with
movq160(%rsp), %r8
rorq$19, %r8
in the final assembly to "simulate" BMI2 insn without BMI.)
[Bug target/69706] internal compiler error: in extract_constrain_insn, at recog.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #10 from Eric Botcazou --- This will be fixed in the upcoming GCC 6.0 release. No backport planned since this has never worked and the fix contains an ABI change.
[Bug middle-end/69983] [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983 --- Comment #2 from Richard Biener --- So we fail analyzing the loop nest because a) the loop header check of the inner loop makes it conditionally executed, b) we have outer loop IV computes i+-1 guarded by that check. For a/b) it would be best if the outer loop were tail duplicated. Looking at the other reported fallout now.
[Bug rtl-optimization/70007] [4.9/5/6 Regression] wrong code with -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||ebotcazou at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org Component|target |rtl-optimization Ever confirmed|0 |1 --- Comment #2 from Uroš Bizjak --- Confirmed as RTL optimization problem, CCs added.
[Bug target/69994] [6 regression] test case gfortran.dg/reassoc_6.f fails starting with r233669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
--- Comment #2 from Richard Biener ---
On ppc64le I see
offset.3_15 = ~stride.2_11;
_45 = (unsigned long) stride.2_11;
_49 = (unsigned long) offset.3_15;
_14 = _45 + 1;
_51 = _14 + _49;
which is supposed to be optimized via
/* ~A + A -> -1 */
(simplify
(plus:c (bit_not @0) @0)
(if (!TYPE_OVERFLOW_TRAPS (type))
{ build_all_ones_cst (type); }))
but on x86_64 is optimized by VRP2 it seems. Note that on x86_64 we have
a simpler
offset.3_15 = ~stride.2_11;
_34 = (unsigned long) stride.2_11;
_38 = (unsigned long) offset.3_15;
_39 = _34 + _38;
and not face the +1 which confuses things on ppc64le here.
It is IVOPTs generating the above two variants and reassoc not "fixing"
the association. Which also hints at that this is reassocs job to catch.
This is what I'm going to try now. And it has that code already, just
it is confused by the casts. Fixing that.
[Bug target/70004] [6 Regression] FAIL: gcc.target/aarch64/scalar_shift_1.c scan-assembler-times neg\\td[0-9]+, d[0-9]+ 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70004 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed for -mtune=thunderx. Passes for -mtune=cortex-a53 and cortex-a57
[Bug c/69972] duplicate integer overflow diagnostic in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69972 --- Comment #2 from Marek Polacek --- The first warning is shown by default and comes from parser_build_binary_op: 3612 if (TREE_OVERFLOW_P (result.value) 3613 && !TREE_OVERFLOW_P (arg1.value) 3614 && !TREE_OVERFLOW_P (arg2.value)) 3615 overflow_warning (location, result.value); The second is emitted with -Wpedantic in build_enumerator: 8199 constant_expression_warning (value);
[Bug c/69973] ICE on excessive attribute vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69973 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I have a hunch that there's a dup of this.
[Bug c/69993] Misleading wording for -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69993 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- This proposal makes sense to me -> confirmed.
[Bug middle-end/69983] [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #3 from Dominik Vogt --- Also fails on s390x with -m64 and -m31.
[Bug middle-end/69983] [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org --- On arm-none-eabi too
[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #18 from Dominik Vogt --- I've no opinion on wether the patch is good or not, but it does make the test failure go away on s390x.
[Bug target/70009] test case libgomp.oacc-c-c++-common/vprop.c fails starting with its introduction in r233607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #1 from Dominik Vogt --- Also fails on s390x with -m64 and -m31.
[Bug c++/69995] [5/6 Regression] [C++14] Invalid result when evaluating constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Looks like this was rejected until commit 905a1e85fe60a887cd97ee882d88ae90f1ab0419 Author: jason Date: Mon Jan 12 14:15:07 2015 + PR c++/64547 * constexpr.c (cxx_eval_call_expression): A call to a void function doesn't need to return a value. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219466 138bc75d-0d04-0410-961f-82ee72b 054a4
[Bug target/69994] [6 regression] test case gfortran.dg/reassoc_6.f fails starting with r233669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994 --- Comment #3 from Richard Biener --- Created attachment 37821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37821&action=edit untested fix Patch I am testing.
[Bug tree-optimization/69999] [6 Regression] ICE in verify_loop_structure, at cfgloop.c:1639 (error: loop with header 3 not in loop tree) at -O3 or -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I still see this even with current trunk (~ r233808).
[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69942 --- Comment #2 from Yuri Rumyantsev --- I attached patch which resolves failure.
[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69942 --- Comment #3 from Yuri Rumyantsev --- Created attachment 37822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37822&action=edit proposed patch Patch to resolve ifcvt5.c failure.
[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989
--- Comment #10 from Richard Biener ---
So - we have an irreducible region that has a reducible part (a memset loop).
The entry into that reducible part is marked as EDGE_IRREDUCIBLE_LOOP.
Loop distribution re-directs the src of the exit of that reducible part
(also marked irreducible) but ends up removing the entry. So we trigger
the "redundant" (?) edge flag check (if the edge is part of an irreducible
region both the src and dest should be marked irreducible as well).
Now... with an embedded reducible sub-CFG that seems no longer true.
Restricting ourselves to
void
remove_edge (edge e)
{
if (current_loops != NULL)
{
rescan_loop_exit (e, false, true);
/* If we remove an edge that is part of an irreducible region
or we remove an entry into an irreducible region we may expose
new natural loops. */
if (! loops_state_satisfies_p (LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS)
|| e->dest->flags & BB_IRREDUCIBLE_LOOP)
loops_state_set (LOOPS_NEED_FIXUP);
}
"fixes" this particular regression. But of course as soon as the reducible
sub-CFG were removed in other ways (redirecting the entry and removing the
exit edge) we'd be back at the very same issue.
So I think we can't rely on those flags given the odd sub-CFG marking.
But in fact what we could do is instead of
static inline void
checking_verify_loop_structure (void)
{
if (flag_checking)
verify_loop_structure ();
}
do
static inline void
checking_verify_loop_structure (void)
{
loops_state_clear (LOOPS_NEED_FIXUP);
if (flag_checking)
verify_loop_structure ();
}
because that's essentially what those checking_verify_loop_structure will
assert (and it'll be useful then to avoid excessive fixups as well).
[Bug ada/70015] New: Finalizer not called depending on declaration order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70015 Bug ID: 70015 Summary: Finalizer not called depending on declaration order Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: tjk at tksoft dot com Target Milestone: --- Created attachment 37823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37823&action=edit Example 1 where Finalizer call gets omitted Call to the Finalizer for an object doesn't get called, or gets called twice, unless declarations are placed in a specific order. I wrote five versions of the same code, with two versions producing the bug; two are workarounds which make the code useless, and the fifth example actually makes the code work as it should. The behavior is unpredictable and violates the expected behavior of a controlled type, so this should probably be classified as a rather serious issue. The original code is for a parser, and written in a pretty predictable way, so I wouldn't be surprised if there was other code out there where this bug just hasn't been noticed. A missing Finalizer call will only be noticed if the controlled resource misbehaves because of a lacking call to the finalizer. Complete list of examples: http://tksoft.com/people/troy/ada/dtor_examples/
[Bug ada/70015] Finalizer not called depending on declaration order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70015 Troy Korjuslommi changed: What|Removed |Added URL||http://tksoft.com/people/tr ||oy/ada/dtor_examples/ --- Comment #1 from Troy Korjuslommi --- Platform is x86_64 GNU/Linux.
[Bug tree-optimization/69760] [4.9/5 Regression] Wrong 64-bit memory address caused by an unneeded overflowing 32-bit integer multiplication on x86_64 under -O2 and -O3 code optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69760 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #13 from Dominik Vogt --- Created attachment 37824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37824&action=edit Dump file of reassoc_6.f This commit introduces a regression on s390x (-m64): FAIL: gfortran.dg/reassoc_6.f -O scan-tree-dump-not optimized "~" (Dump file of the test attached.)
[Bug tree-optimization/69980] [6 regression] Supposedly wrong SLP code emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69980 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Feb 29 13:24:24 2016 New Revision: 233809 URL: https://gcc.gnu.org/viewcvs?rev=233809&root=gcc&view=rev Log: 2016-02-19 Richard Biener PR tree-optimization/69980 * tree-vect-slp.c (vect_attempt_slp_rearrange_stmts): Update permutation of those we need to keep. * gfortran.dg/vect/pr69980.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/vect/pr69980.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/69980] [6 regression] Supposedly wrong SLP code emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69980 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/70004] [6 Regression] FAIL: gcc.target/aarch64/scalar_shift_1.c scan-assembler-times neg\\td[0-9]+, d[0-9]+ 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70004
--- Comment #2 from ktkachov at gcc dot gnu.org ---
The function that changes is:
test_corners_sisd_si (Int32x1 b)
{
force_simd_si (b);
b = b >> 31;
force_simd_si (b);
b = b >> 0;
b += b >> 33; /* { dg-warning "right shift count >= width of type" } */
return b;
}
basically, it moves the value back into the integer registers and performs the
shift there.
This shift right by 33 is undefined anyway, so this testcase is bogus. We
should just remove it.
[Bug c++/69954] internal compiler error: in dependent_type_p, at cp/pt.c:21141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69954 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- This was fixed on the trunk in r229210. Doesn't seem to be a dup of PR60153 or PR69095.
[Bug c++/69954] internal compiler error: in dependent_type_p, at cp/pt.c:21141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69954 Marek Polacek changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug ipa/69990] [5/6 Regression] decl alignment not respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69990 --- Comment #5 from Alan Modra --- I don't think we can make the decl with the larger alignment prevail. Aren't we stuck with "c" due to it being referenced by the constructor? It goes like: 1) "c" is referenced in a constructor, thus make_decl_rtl for "c" 2) make_decl_rtl puts "c" in an anchor block, 3) anchor block contents can't move, so "c" alignment can't change, 4) "a" can be changed by ipa_increase_alignment, and the alias info isn't yet available so there's no way to stop that happening, 5) "a" therefore must be prevented from aliasing "c". I guess testing for exact equality of alignment is too strict, and I should also allow an alias from smaller to larger alignment if the larger alignment is a multiple of the smaller.
[Bug c++/69995] [5/6 Regression] [C++14] Invalid result when evaluating constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 --- Comment #12 from David Malcolm --- (In reply to Manuel López-Ibáñez from comment #11) > (In reply to Markus Trippelsdorf from comment #6) > > Bingo! With both files present I can even reproduce it on my x86_64 machine. > > Unfortunately, I cannot reproduce it with r230753, so it seems quite a > recent regression. (something is broken in the machine of the compile farm > that I use for development and I cannot build a more recent GCC). > > If you want to investigate further, add a breakpoint just before calling > linemap_position_for_loc_and_offset(), figure out if the arguments passed > make sense and if they do, why the corresponding assert is triggering. > > The assert triggering is one of these two: > > if (linemap_assert_fails (r <= set->highest_location) > || linemap_assert_fails (map == linemap_lookup (set, r))) I'm able to reproduce it (e.g. with r233722) by copying attachment 37812 to "t.c", and then copying attachment 37813 to "cmds-check.c" in the same dir, and running: ./xgcc -B. -c t.c -Wformat from that dir. (gdb) p /x r $2 = 0x5daef40 (gdb) p /x set->highest_location $3 = 0x5dc71a0 (gdb) p r <= set->highest_location $4 = true (gdb) p map $5 = (const line_map_ordinary *) 0x715baf20 (gdb) call linemap_lookup (set, r) $6 = (const line_map *) 0x715baf40 (gdb) p (map == linemap_lookup (set, r)) $7 = false i.e. it's the 2nd conditional that's failing.
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 --- Comment #13 from Markus Trippelsdorf --- Yeah, see also comment 5.
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #14 from David Malcolm ---
(gdb) p *map
$8 = { = {start_location = 98229568, reason = LC_RENAME_VERBATIM},
to_file = 0x2709850 "cmds-check.c", to_line = 7836,
included_from = -1, sysp = 0 '\000', m_column_and_range_bits = 12,
m_range_bits = 5}
(gdb) call linemap_lookup (set, r)
$9 = (const line_map *) 0x715baf40
(gdb) p *(const line_map_ordinary *)$9
$11 = { = {start_location = 98233888, reason = LC_RENAME}, to_file =
0x2709850 "cmds-check.c", to_line = 7837,
included_from = -1, sysp = 0 '\000', m_column_and_range_bits = 13,
m_range_bits = 5}
The .i file has:
if (!silent)
fprintf(
# 7836 "cmds-check.c" 3 4
stderr
# 7836 "cmds-check.c"
,
"Chunk[%llu, %u, %llu]: length(%llu), offset(%llu), type(%llu) mismatch
with block group[%llu, %u, %llu]: offset(%llu), objectid(%llu), flags(%llu)\n",
The relevant code in cmds-check.c looks like this:
7835 if (!silent)
7836 fprintf(stderr,
7837 "Chunk[%llu, %u, %llu]:
length(%llu), offset(%llu), type(%llu) mismatch with block group[%llu, %u,
%llu]: offset(%llu), objectid(%llu), flags(%llu)\n",
7838 chunk_rec->objectid,
7839 chunk_rec->type,
7840 chunk_rec->offset,
7841 chunk_rec->length,
7842 chunk_rec->offset,
7843 chunk_rec->type_flags,
7844 block_group_rec->objectid,
7845 block_group_rec->type,
7846 block_group_rec->offset,
7847 block_group_rec->offset,
7848 block_group_rec->objectid,
7849 block_group_rec->flags);
Within the .i it looks like this:
if (!silent)
fprintf(
# 7836 "cmds-check.c" 3 4
stderr
# 7836 "cmds-check.c"
,
"Chunk[%llu, %u, %llu]: length(%llu), offset(%llu), type(%llu) mismatch
with block group[%llu, %u, %llu]: offset(%llu), objectid(%llu), flags(%llu)\n",
Note that the very long line containing the format string was 191 chars long;
looks like it triggered a transition to a new ordinary line map, since the
default 7 bits of length, for a maximum column number of 127.
[Bug c++/69995] [5/6 Regression] [C++14] Invalid result when evaluating constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Feb 29 14:25:57 2016 New Revision: 233810 URL: https://gcc.gnu.org/viewcvs?rev=233810&root=gcc&view=rev Log: PR c++/69995 * constexpr.c (cxx_eval_store_expression): Unshare init. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-array3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #15 from David Malcolm ---
A minimal reproducer:
$ cat t3.c
extern int printf (const char *__restrict __format, ...);
void test (void)
{
printf
("%llu01233456789012334567890123345678901233456789012334567890123345678901233456789012334567890123345678901233456789012334567890123345678901233456789");
}
$ ./xgcc -B. -c t3.c -Wformat
t3.c: In function ‘test’:
t3.c:4:3: internal compiler error: in linemap_position_for_loc_and_offset, at
libcpp/line-map.c:924
printf
("%llu01233456789012334567890123345678901233456789012334567890123345678901233456789012334567890123345678901233456789012334567890123345678901233456789");
^~
0x197628e linemap_position_for_loc_and_offset(line_maps*, unsigned int,
unsigned int)
../../src/libcpp/line-map.c:924
0x84a988 location_from_offset
../../src/gcc/c-family/c-format.c:139
0x850683 format_type_warning
../../src/gcc/c-family/c-format.c:2672
0x84fbb0 check_format_types
../../src/gcc/c-family/c-format.c:2474
0x84f996 check_format_info_main
../../src/gcc/c-family/c-format.c:2424
0x84d266 check_format_arg
../../src/gcc/c-family/c-format.c:1688
0x835a1c check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned
long), void*, tree_node*, unsigned long)
../../src/gcc/c-family/c-common.c:9783
0x83573d check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned
long), void*, tree_node*, unsigned long)
../../src/gcc/c-family/c-common.c:9716
0x84c281 check_format_info
../../src/gcc/c-family/c-format.c:1423
0x84b4fe check_function_format(tree_node*, int, tree_node**)
../../src/gcc/c-family/c-format.c:1093
0x8355c8 check_function_arguments(unsigned int, tree_node const*, int,
tree_node**)
../../src/gcc/c-family/c-common.c:9695
0x778701 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../src/gcc/c/c-typeck.c:3051
0x778d64 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../src/gcc/c/c-typeck.c:3102
0x7c10a2 c_parser_postfix_expression_after_primary
../../src/gcc/c/c-parser.c:8262
0x7c07c0 c_parser_postfix_expression
../../src/gcc/c/c-parser.c:8075
0x7bc581 c_parser_unary_expression
../../src/gcc/c/c-parser.c:6893
0x7bb9ae c_parser_cast_expression
../../src/gcc/c/c-parser.c:6722
0x7ba631 c_parser_binary_expression
../../src/gcc/c/c-parser.c:6531
0x7b9e80 c_parser_conditional_expression
../../src/gcc/c/c-parser.c:6302
0x7b9b6e c_parser_expr_no_commas
../../src/gcc/c/c-parser.c:6219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 --- Comment #16 from David Malcolm --- Created attachment 37825 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37825&action=edit Minimal reproducer Looks like BZ line-wrapped the inline copy; here it is as an attachment.
[Bug c/69798] ICE on invalid code on x86_64-linux-gnu in c_parser_braced_init, at c/c-parser.c:4338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69798 --- Comment #3 from Marek Polacek --- Started with r204172.
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 --- Comment #17 from David Malcolm --- (In reply to David Malcolm from comment #16) > Created attachment 37825 [details] > Minimal reproducer > > Looks like BZ line-wrapped the inline copy; here it is as an attachment. Interestingly, Chromium line-wraps it when I view it in BZ. The printf call is meant to be all on one line. Though am not sure if that affects the reproducibility.
[Bug target/70016] New: [Regression] pr52429.c fails since r233745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016 Bug ID: 70016 Summary: [Regression] pr52429.c fails since r233745 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: kyrylo.tkachov at arm dot com Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: aarch64-none-linux-gnu Since r233745 ([AArch64] Set TREE_TARGET_GLOBALS in aarch64_set_current_function when new tree is the default node to recalculate optab availability), I've noticed that: FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) on target aarch64-none-linux-gnu The log contains: spawn -ignore SIGHUP /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/gcc/xgcc -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc 3/gcc/ /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/torture/pr52429.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto -fno-use-linker-pl ugin -flto-partition=none -g -ftree-parallelize-loops=4 -DSTACK_SIZE=16384 -S -o pr52429.s /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/torture/pr52429.c: In function 'foo': /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/torture/pr52429.c:24:1: internal compiler error: Segmentation fault 0xade075 crash_signal /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/toplev.c:335 0x91f88e record_operand_costs /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/ira-costs.c:1293 0x91fdba scan_one_insn /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/ira-costs.c:1471 0x91fdba process_bb_for_costs /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/ira-costs.c:1592 0x9214e7 find_costs_and_classes /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/ira-costs.c:1699 0x922552 ira_set_pseudo_classes(bool, _IO_FILE*) /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/ira-costs.c:2239 0x1061ecd alloc_global_sched_pressure_data /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:7244 0x1061ecd sched_init() /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:7394 0x10679ed haifa_sched_init() /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:7406 0xa84fae schedule_insns() /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3504 0xa85864 rest_of_handle_sched /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3717 0xa85864 execute /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3825
[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652 --- Comment #10 from Ilya Enkovich --- Author: ienkovich Date: Mon Feb 29 14:32:24 2016 New Revision: 233811 URL: https://gcc.gnu.org/viewcvs?rev=233811&root=gcc&view=rev Log: gcc/testsuite/ 2016-02-29 Yuri Rumyantsev PR tree-optimization/69652 * gcc.dg/torture/pr69652.c: Delete test. * gcc.dg/vect/pr69652.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr69652.c Removed: trunk/gcc/testsuite/gcc.dg/torture/pr69652.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/70016] [6 Regression] pr52429.c fails since r233745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||ktkachov at gcc dot gnu.org Target Milestone|--- |6.0 Summary|[Regression] pr52429.c |[6 Regression] pr52429.c |fails since r233745 |fails since r233745 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed
[Bug target/70011] [6 regression] test case gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011 --- Comment #3 from Bill Schmidt --- I'll have a look at the differences in output from GCC 5 and GCC 6.
[Bug target/70008] [ARM] Reverse subtract with carry can be generated in thumb2 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70008 --- Comment #1 from Richard Earnshaw --- Huh? The attribute (set_attr "arch" "*,a") Should disable the second alternative for Thumb.
[Bug c++/69995] [5/6 Regression] [C++14] Invalid result when evaluating constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/69995] [5/6 Regression] [C++14] Invalid result when evaluating constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995 --- Comment #6 from Jason Merrill --- Author: jason Date: Mon Feb 29 14:49:17 2016 New Revision: 233813 URL: https://gcc.gnu.org/viewcvs?rev=233813&root=gcc&view=rev Log: PR c++/69995 * constexpr.c (cxx_eval_store_expression): Unshare init. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-array3.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug c++/65985] [5/6 Regression] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 --- Comment #7 from Jason Merrill --- Author: jason Date: Mon Feb 29 14:49:12 2016 New Revision: 233812 URL: https://gcc.gnu.org/viewcvs?rev=233812&root=gcc&view=rev Log: PR c++/65985 * constexpr.c (build_constexpr_constructor_member_initializers): Handle an additional STATEMENT_LIST. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-assert2.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug c++/65985] [5/6 Regression] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|5.2 |5.4 --- Comment #8 from Jason Merrill --- Fixed.
[Bug target/70011] [6 regression] test case gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 Ever confirmed|0 |1 --- Comment #4 from Bill Schmidt --- Looks like another case where the test case hasn't kept up with changes to the vectorizer and the Power hardware. In GCC 5, we have an unaligned access and choose to peel for alignment. In GCC 6, we recognize that we have an unaligned access but that it is supported by hardware, and we analyze the loop without peeling. In GCC 5, the peeling is unprofitable (number of iterations is 7, and we need 11 to make it profitable in light of the extra setup code). In GCC 6, the cost model says we only need 5 iterations to make it profitable, so the loop is vectorized. I think that earlier in GCC 6 we still didn't vectorize this. It looks like we now produce better code because vect_recog_mult_pattern kicks in where it didn't before. I think this probably would fail the same way on BE on a POWER8 system. Bill Seurer, can you confirm that the BE system you tested on was a POWER7? The alignment issue should be due to P8 hardware improvements, not anything endian-related. If that's the case, then I think we just need to adjust this test case to skip the failing predicate when hardware alignment is supported, similar to the big set of tests I changed last year for the same reason.
[Bug target/70016] [6 Regression] pr52429.c fails since r233745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016 --- Comment #2 from ktkachov at gcc dot gnu.org --- this_target_ira_int->x_init_cost is NULL when it's used, causing the ICE. I would have expected target_reinit to have properly initialised it when called through save_target_globals_default_opts. Unfortunately I'm not very familiar with the globals target switching logic so it's not immediately clear to me where the fix should be. If I call ira_init () after init_regs () in target_reinit () in toplev.c then the ICE goes away, but is that the correct place to do it?
[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984 --- Comment #2 from Edmar Wienskoski --- Right, but the variables A and B are *unsigned short*. Both A, and B are promoted to signed int, but max value is 65535. So, the result of A*B *can* be bigger than 31 bits. Thanks
[Bug target/69994] [6 regression] test case gfortran.dg/reassoc_6.f fails starting with r233669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- But it is 64-bit comparison. The result of the multiplication is still at most 0xfffe0001UL, so certainly not negative in 64-bit integer, E is not negative either. So, do you have an evidence of wrong-code, or just don't like jbe to be emitted when it doesn't really matter?
[Bug target/69994] [6 regression] test case gfortran.dg/reassoc_6.f fails starting with r233669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Feb 29 15:30:50 2016 New Revision: 233816 URL: https://gcc.gnu.org/viewcvs?rev=233816&root=gcc&view=rev Log: 2016-02-29 Richard Biener PR tree-optimization/69994 * tree-ssa-reassoc.c (gimple_nop_conversion_p): New function. (get_unary_op): Look through nop conversions. (ops_equal_values_p): New function, look for equality diregarding nop conversions. (eliminate_plus_minus_pair): Use ops_equal_values_p (repropagate_negates): Do not use get_unary_op here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug rtl-optimization/44281] [4.9/5/6 Regression] Global Register variable pessimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281 Bernd Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #24 from Bernd Schmidt --- There is a possibility to fix it, but concerns that doing so would be invalid in the presence of signal handlers that want to access the global reg. Discussion here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01401.html Therefore, WONTFIX. I think the real recommendation here is not to use global register vars.
[Bug rtl-optimization/70007] [4.9/5/6 Regression] wrong code with -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007 H.J. Lu changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #3 from H.J. Lu --- It started with r188664.
[Bug c/69798] ICE on invalid code on x86_64-linux-gnu in c_parser_braced_init, at c/c-parser.c:4338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69798
--- Comment #4 from Marek Polacek ---
There are two c_parser_postfix_expression calls that should probably be guarded
with something like
8044 if (c_parser_peek_2nd_token (parser)->type !=
CPP_OPEN_PAREN
8045 || c_parser_peek_token (parser)->id_kind != C_ID_ID)
8046 {
8047 c_parser_error (parser, "expected function-name
%<(%>");
8048 expr.value = error_mark_node;
8049 }
[Bug c++/65189] [4.9/5/6 Regression] --fdump-translation-unit is broken for virtual dtors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65189 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Jason Merrill --- This was a deliberate change in the contents of the vtable; the destructor for an abstract class can never be called through the vtable in conforming code, so we stopped referring to it from the vtable. I would suggest updating ABICC to ignore this mismatch (for a destructor in a class that also refers to __cxa_pure_virtual).
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 --- Comment #18 from Manuel López-Ibáñez --- I think the heuristic I implemented to figure out on which map we can encode the new location does not work. The heuristic assumes that if map[0].start_location <= loc + offset < map[1].start_location, then we can encode loc+offset in map[0], however, this is not true in this case because map[0] does not seem to be able to encode anything beyond loc (any loc+offset returns 4:11). I don't really understand why this is the case: we seem to waste a lot of location numbers that do not point to anything. If there is a way to tell which map should encode a particular line,column, then we simply should use that map if there are free locations left to do so.
[Bug c++/63433] init_priority not working on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63433 Ramana Radhakrishnan changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Ramana Radhakrishnan --- No information in nearly 14 months after a request for a reproducer.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 --- Comment #6 from marc at kdab dot com --- To expand on my previous comment: the compiler is even allowed to elide the copy if that would save a read/write from a volatile object. So I don't see how this can be implemented anywhere except the front-end.
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 --- Comment #3 from marc at kdab dot com --- This really should be top priority. But no comment on it for almost three years by GCC devs.
[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #4 from Edmar Wienskoski ---
I forgot that default on x86 is 64 bits.
Repeating the test with -m32 still shows the signed comparison.
Here:
#include
void main ()
{
unsigned short int A, B;
unsigned long C,D;
unsigned long E = 0xFFFEFFEUL;
scanf("%hu %hu %lu", &A, &B, &D);
C=A*B;
printf("A:%08X, B:%08X, C:%08X, D:%08X, E:%08X\n", A, B, C, D, E);
if (C <= D)
printf("C<=D\n");
if (C <= E) //this compare has issue
printf("C<=E\n");
}
Compiling with:
gcc -O3 -m32 -o unsig_comp unsig_comp.c
And excuting as:
./unsig_comp
65535 65535 65535
A:, B:, C:FFFE0001, D:, E:0FFFEFFE
C<=E
gives me the wrong answer.
The same problem with -m64 as well, but because the compiler
reduces one of the comparisons to 32 bits:
cmpq8(%rsp), %rbp
jbe .L6
.L2:
cmpl$268431358, %ebx
jg .L1
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 --- Comment #19 from Manuel López-Ibáñez --- (In reply to Manuel López-Ibáñez from comment #18) > I don't really understand why this is the case: we seem to waste a lot of > location numbers that do not point to anything. If there is a way to tell > which map should encode a particular line,column, then we simply should use > that map if there are free locations left to do so. Perhaps by trying first linemap_position_for_line_and_column (set, map, line, column+offset) if that returns a location >= map[1].start_location, then if (line < ORDINARY_MAP_STARTING_LINE_NUMBER (map+1)), try again with map++, until either we run out of maps or the next map encodes a higher line, and in those cases we give up.
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 --- Comment #4 from Thomas Braun --- (I'm no gcc dev at all) In general gcc is much better in doing NRVO/URVO than other compilers according to my analysis [1]. So maybe the competitors need to get better first ;) [1]: http://www.byte-physics.de/cpp-copy-elision
[Bug target/70014] [ARM] Predicate does not match constraint (*subsi3_carryin_const)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70014 --- Comment #1 from Richard Earnshaw --- More importantly, the constraint on operand 2 is for just a constant. but the predicate accepts a register. That's something the register allocator could not handle.
[Bug middle-end/69983] [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
--- Comment #5 from Richard Biener ---
comment #2 (In reply to Richard Biener from comment #2)
> So we fail analyzing the loop nest because a) the loop header check of the
> inner
> loop makes it conditionally executed, b) we have outer loop IV computes i+-1
> guarded by that check.
>
> For a/b) it would be best if the outer loop were tail duplicated.
>
> Looking at the other reported fallout now.
That's unrelated.
So the CFG is the following.
:
:
# i_34 = PHI <1(3), prephitmp_55(7)>
if (_49 > 1)
goto ;
else
goto ;
:
_52 = i_34 + -1;
_53 = i_34 + 1;
goto ;
:
:
# j_35 = PHI <1(10), _14(4)>
_10 = P[i_34][j_35];
_11 = j_35 + -1;
_12 = P[i_34][_11];
_13 = _10 + _12;
_14 = j_35 + 1;
_15 = P[i_34][_14];
_16 = _13 + _15;
_18 = P[_52][j_35];
_19 = _16 + _18;
_21 = P[_53][j_35];
_22 = _19 + _21;
_23 = _22 / 5.0e+0;
P[i_34][j_35] = _23;
if (_14 < _49)
goto ;
else
goto ;
:
_54 = i_34 + 1;
goto ;
:
# prephitmp_55 = PHI <_53(5), _54(9)>
if (_30 > prephitmp_55)
goto ;
else
goto ;
:
:
return;
and hoisting the loop header check out of the outer loop fixes the PR
(thus for example run it at -O3). loop unswitching performs this
optimization. Not sure if we can improve things otherwise - the IV
computations of i + 1 / i - 1 are inside the inner loop and thus guarded
by the check. The only thing we can do is try to improve the overflow
detection in SCEV / niter analysis to conclude the now unsigned IV { 1, +, 1
}_1
does not overflow because of the loop header check:
_30 = N1_6(D) + -1;
if (_30 > 1)
goto ;
else
goto ;
that would be done via chrec_convert / convert_affine_scev here. Sadly
the outer loop has no control-IVs recorded for example because of the
redundant _53 / _54 IV update fed into the PHI in bb 6. Looks like that
mess is caused by PRE first hoisting the loop invariant i + 1 / i - 1
and then PREing it (but not hoisting because it doesn't implement that...).
[Bug target/70011] [6 regression] test case gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011 Bill Schmidt changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #5 from Bill Schmidt --- I've verified such a fix for LE (P8) and BE (P7, P8). I'll get the patch submitted.
[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985 --- Comment #20 from David Malcolm --- In r230331 I added a range-packing optimization; looks like I forgot to update linemap_position_for_loc_and_offset accordingly. Sorry. The input "offset" is a column offset, and that is no longer applicable as a offset to loc. I'm investigating a fix.
[Bug libfortran/69788] FAIL: gfortran.dg/derived_constructor_comps_6.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69788 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11, ||arm-none-linux-gnueabihf CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- I'm seeing this fail at -O0 on arm-none-linux-gnueabihf on the GCC 5 branch. On trunk it passes. The failure is a segfault
[Bug fortran/70006] Duplicate errors "label not defined"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70006 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > > OK, How about WONTFIX? If the programmer fixes the > > issue reported in the "duplicate" error message, then > > the problem goes away. > > Well, this is quite general: if your code does not generate any error you'll > never the the shortcomings of the error handling! Nevertheless the laters > have to be fixed from a QOI point of view. It's not general at all. If the programmer fixes the error reported in the first message, then the second error message will not occur. Fairly simple concept. (It's clear that when I added -fmax-errors to gfortran, I should have made the default 1 instead of 25.) > > Amazing what an error message can convey! > > > > PS: The first duplicate error can be fixed by a > > trivial 3 character patch. The second duplicate > > error will probably take a significant rewrite of > > how labels are handle. Good luck. > > AFAIU the gfortran error handling, "duplicate" here does not mean that the > errors are repeated more than once as in pr44978, but rather that the first > errors are "shadowed" by the last ones. Compiling the following modified test gfortran is reporting the correct number of error messages as there are four errors in the original code. I've actually read the code (and fixed the first issue in my local code repository). The first set of duplicate error messages can be fixed with these three characters: loc. The second set of duplicated error messages requires someone to rewrite how labels are handled. Given that a sensible error message is emitted, it's not worth the effort.
[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984 --- Comment #5 from Jakub Jelinek --- Even if the computation is 32-bit, by the time you multiply say (unsigned short int) 0x with itself, you get undefined behavior. So, as has been said, if you want to perform the multiplication in unsigned long or unsigned int, you need to cast one of the operands.
[Bug ada/70017] New: Ada: c52103x test failure on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017 Bug ID: 70017 Summary: Ada: c52103x test failure on s390x Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com CC: ebotcazou at gcc dot gnu.org, krebbel at gcc dot gnu.org Target Milestone: --- Host: s390x Target: s390x My knowledge of Ada is practically zero, but I'm debugging a few Ada test failures on s390x (gcc-4.7 or earlier). -- snip -- ,.,. C52103X ACATS 2.5 16-02-29 16:03:21 C52103X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS, THE LENGTHS MUST MATCH; ALSO CHECK WHETHER CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE ARRAYS. - C52103X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST + 3. raised STORAGE_ERROR : System.Stack_Checking.Operations.Stack_Check: stack over\ flow detected FAIL: c52103x -- snip -- This happens here: -- snip -- TYPE TA42 IS ARRAY( INTEGER RANGE IDENT_INT(-2)..IDENT_INT(INTEGER'LAST) ) OF BOOLEAN ; ... OBJ_DCL: DECLARE -- THIS BLOCK DECLARES TWO BOOLEAN ARRAYS THAT -- HAVE INTEGER'LAST + 3 COMPONENTS; -- STORAGE_ERROR MAY BE RAISED. ARR41 : TA41 ; ARR42 : TA42 ; -- snip -- This is a reduced test (that fails with ulimit -s 131072): -- snip -- procedure c52103x is begin declare type T is array(integer range -2..1000) of boolean; begin declare A : T; begin null; end; end; end; -- snip -- As far as I understand this code, it assumes that only the first few memory pages of the array are allocated in the stack initially and the rest is allocated when actually accessed. However, on s390x first a snippet of three pages is allocated and checked, followed immediately by the rest of the array plus another check that fails because the stack is too small for that: -- snip -- _ada_c52103x: stmg%r11,%r15,88(%r15) larl%r13,.L4 aghi%r15,-168 lgr %r11,%r15 lgr %r1,%r15 aghi%r1,-12280 # <-- first three pages lgr %r2,%r1 brasl %r14,_gnat_stack_check # <-- OK lgr %r1,%r15 lgr %r12,%r1 lg %r1,.L5-.L4(%r13) agr %r1,%r15# <-- rest of array lgr %r2,%r1 brasl %r14,_gnat_stack_check # <-- FAIL ... .section.rodata .align 8 .L4: .L6: .quad -1008 .L5: .quad -10012288 -- snip -- (Stack on s390x grows down.) I've no idea whether this is the intended behaviour (i.e. the test case has a bug) or not, and if not whether I should look for the bug in the s390x backend or somewhere else.
[Bug tree-optimization/69811] A gcc folding issue at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69811 Jakub Jelinek changed: What|Removed |Added Summary|[5/6 Regression] A gcc |A gcc folding issue at -O0 |folding issue at -O0| --- Comment #7 from Jakub Jelinek --- Removing the regression marker, at -O0 we don't/shouldn't guarantee folding outside of initializers or constexpr expressions.
[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984 --- Comment #6 from Edmar Wienskoski --- Hummm, You are almost convincing me, one last question, be patient with me. As Andrew posted: C = A * B should be equivalent to: C = (unsigned long)( ((int)A) * ((int)B) ) The variables are promoted *before* the multiplication. How come (int)65535 multiplied by itself is undefined behavior ? Or (unsigned short) 0x7FFF multiplied by itself, would not be undefined behavior as well ? In fact, re-writing the code as above, will generate unsigned comparison. So, why "C = A * B" is not doing the same ?
[Bug target/70016] [6 Regression] pr52429.c fails since r233745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 70002. Also see bug 64047 which was fixed for rs6000 backend. *** This bug has been marked as a duplicate of bug 70002 ***
[Bug target/70002] [6 Regression] gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin -flto-partition=none ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002 Andrew Pinski changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- *** Bug 70016 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984 --- Comment #7 from Andrew Pinski --- (In reply to Edmar Wienskoski from comment #6) > Hummm, You are almost convincing me, one last question, > be patient with me. > > As Andrew posted: > C = A * B > should be equivalent to: > C = (unsigned long)( ((int)A) * ((int)B) ) > > The variables are promoted *before* the multiplication. > How come (int)65535 multiplied by itself is undefined behavior ? Because signed integer overflow is undefined. That is if there is an overflow for int*int, the outcome is undefined. Since GCC Knows both sides of the multiplier is positive, GCC treats the outcome of the multiply to be also positive (due to overflow being undefined).
[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984 --- Comment #8 from Jakub Jelinek --- 0x7fff * 0x7 is 0x3fff0001 and that is representable in int, so there is no overflow. 0xb504 * 0xb504 is 0x7ffea810 and thus also representable in int, no overflow. 0xb505ULL * 0xb505ULL is 0x80001219ULL, which is not representable in int, thus 0xb505 * 0xb505 has signed multiplication overflow and undefined behavior.
[Bug libgomp/70009] test case libgomp.oacc-c-c++-common/vprop.c fails starting with its introduction in r233607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009 Andrew Pinski changed: What|Removed |Added Target|powerpc*-*-*|powerpc*-*-*, aarch64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 Component|target |libgomp CC||jakub at gcc dot gnu.org Host|powerpc*-*-*| Ever confirmed|0 |1 Build|powerpc*-*-*| --- Comment #2 from Andrew Pinski --- Also fails on aarch64-linux-gnu in LP64 mode. Confirmed. FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vprop.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for exce ss errors) UNRESOLVED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vprop.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 compilat ion failed to produce executable FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/vprop.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 execution te st
[Bug tree-optimization/69999] [6 Regression] ICE in verify_loop_structure, at cfgloop.c:1639 (error: loop with header 3 not in loop tree) at -O3 or -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Started with r231915. Confirmed that r233754 nor r233787 makes no difference here.
[Bug target/70002] [6 Regression] gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin -flto-partition=none ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-29 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Or better look at what i386 does in its set_current_function, what rs6000 does looks weird to me.
