[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #2 from Aldy Hernandez ---
Here is another testcase pulled from pr95653 which I'm marking as a duplicate
of this one.
This one needs -O2 -fno-tree-scev-cprop to reproduce.
char b (void);
char *d;
int e;
int f;
void
g (char *h)
{
while (d)
{
long i = b ();
if (h + i > d)
break;
if (f > 0 || e)
do
*h++ = *h;
while (--i);
}
}
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 Aldy Hernandez changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Aldy Hernandez --- Mine.
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 Aldy Hernandez changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #4 from Aldy Hernandez --- *** Bug 95653 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/95653] [11 Regression] ICE: SIGSEGV in gimple_bb (gimple.h:1847) with -ftree-loop-vectorize -fno-tree-scev-cprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95653 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Aldy Hernandez --- duplicate *** This bug has been marked as a duplicate of bug 95649 ***
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 Aldy Hernandez changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #5 from Aldy Hernandez --- The problem here is that the code in propagate_into_phi_args() was previously in evrp but is now in the engine itself and affecting all clients. CCP and copyprop are two of these clients. The subst & fold engine is changing the CFG (phis in this case) and neither pass is expecting it. A hack showing that it's the PHI propagation is attached below. We could make these passes clean-up the CFG for example, but that may be heavy handed if they're supposed to be lightweight ??. Instead we could either move propagate_into_phi_args back into evrp, or only run it if a CHANGE_CFG_FLAG or somesuch is passed to the engine constructor. I'll work on a patch. - NOT A FIX: diff --git a/gcc/tree-ssa-propagate.c b/gcc/tree-ssa-propagate.c index 4fda296ef9e..249867d8633 100644 --- a/gcc/tree-ssa-propagate.c +++ b/gcc/tree-ssa-propagate.c @@ -1228,7 +1228,7 @@ substitute_and_fold_dom_walker::before_dom_children (basic_block bb) } } - substitute_and_fold_engine->propagate_into_phi_args (bb); + //substitute_and_fold_engine->propagate_into_phi_args (bb); return NULL; }
[Bug tree-optimization/95662] [11 regression] ICE at gimple-expr.c:87 since r11-1146
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95662 --- Comment #1 from Aldy Hernandez --- This is likely a duplicate of pr95649 (see my note there), but I cannot verify as I don't have access to the spec2006 sources.
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 --- Comment #7 from Aldy Hernandez --- Hmmm, previous code propagating into PHI args had: - if (vr->singleton_p (&val) && may_propagate_copy (arg, val)) - propagate_value (use_p, val); We seem to have lost the check for constants, and we're now propagating any old value from get_value_range-- which may be another SSA name: + if (val && may_propagate_copy (arg, val)) + propagate_value (use_p, val); Testing the following: diff --git a/gcc/tree-ssa-propagate.c b/gcc/tree-ssa-propagate.c index 4fda296ef9e..01ee7fd33eb 100644 --- a/gcc/tree-ssa-propagate.c +++ b/gcc/tree-ssa-propagate.c @@ -1035,7 +1035,8 @@ substitute_and_fold_engine::propagate_into_phi_args (basic_block bb) || virtual_operand_p (arg)) continue; tree val = get_value (arg, phi); - if (val && may_propagate_copy (arg, val)) + if (val && is_gimple_min_invariant (val) + && may_propagate_copy (arg, val)) propagate_value (use_p, val); } }
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #8) > I still don't understand why propagating one SSA_NAME for another is causing > headaches later though. TBH, I don't either. When I compile the .c test in this PR with the following options: -O2 -fno-tree-scev-cprop -fdisable-tree-ccp1 -fdisable-tree-ccp2 -fdisable-tree-copyprop1 -fdisable-tree-evrp -fdisable-tree-vrp1 -fdisable-tree-ccp1 -fdisable-tree-ccp2 -fdisable-tree-ccp3 ...I still get an ICE, but there is no change in the IL between trunk without the offending patch, and with the patch that broke the test. This would indicate that there is some on-the-side structure that is being altered by the phi argument propagation. I did notice that the IL *does* change in the middle of one of the copyprop (or ccp?) passes, but it gets cleaned up to whatever was there before. Later in SCEV, we ICE while trying to look at the SSA_NAME_DEF_STMT of an SSA which no longer exists in the IL. This happens in chrec_contains_symbols_defined_in_loop(). A wild guess is that the loop info is getting mucked up somehow. I can investigate more deeply if desired, but since this was a silly typo, I'm gonna leave it alone for now. Closing as fixed in mainline.
[Bug tree-optimization/96397] GCC Fails to exploit ranges from overflow tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com --- Comment #1 from Aldy Hernandez --- >From a previous conversation with Jeff, I believe the corresponding IL is this: ;; basic block 11, loop depth 0, count 487351684 (estimated locally), maybe hot ;; Invalid sum of incoming counts 749887186 (estimated locally), should be 487351684 (estimated locally) ;;prev block 10, next block 12, flags: (NEW, REACHABLE, VISITED) ;;pred: 18 [82.6% (guessed)] count:749887186 (estimated locally) (FALSE_VALUE,EXECUTABLE) _109 = .ADD_OVERFLOW (_106, 1); _110 = REALPART_EXPR <_109>; # DEBUG size => _110 _111 = IMAGPART_EXPR <_109>; # DEBUG fail => (_Bool) _111 if (_111 != 0) goto ; [17.38%] else goto ; [82.62%] The ranger knows that _111 can only be [0,1], but we don't currently have a backwards solver for the IMAGPART_EXPR code. Currently it's unimplemented as "op_unknown". I suppose we could implement it, and the ranger should be then able to solve for _109 (and eventually _106). It would take a little twiddling, since range-ops currently doesn't look at USE/DEF chains, and it would have to for the IMAGPART_EXPR since not all IMAGPART_EXPR's are created equal. E.g. for DEF's of .ADD_OVERFLOW, it means something totally different than the IMAGPART_EXPR of a complex number. Andrew, can you verify this is doable with minor tweaks?
[Bug tree-optimization/96430] internal compiler error: in verify_range, at value-range.cc:354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96430 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2020-08-03 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Aldy Hernandez --- Mine. Confirmed.
[Bug tree-optimization/96430] internal compiler error: in verify_range, at value-range.cc:354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96430 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Aldy Hernandez --- Fixed in mainline.
[Bug c/96540] gcc fails to build on Darwin 19.6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540 --- Comment #4 from Aldy Hernandez --- Does this patch fix the problem? https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html
[Bug c/96540] gcc fails to build on Darwin 19.6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Aldy Hernandez --- Fixed upstream.
[Bug bootstrap/96813] [11 Regression] Broken bootstrap-lto-lean profiled bootstrap since r11-2883-gbf19cbc9cea6161f3deb63040601090828c44c53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96813 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #3 from Aldy Hernandez --- Mine. Confirmed. Something's hokey with my irange API conversion of DOM, which also affects the threader because I abstracted some code out. Will investigate.
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #2 from Aldy Hernandez --- Mine. Thank you for the much reduced help case. It'll save me a lot of time.
[Bug tree-optimization/96822] [11 regression] Starting with r11-2833 ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96822 Aldy Hernandez changed: What|Removed |Added Depends on||96818 --- Comment #1 from Aldy Hernandez --- I cannot confirm, as I don't have access to spec, but this looks very similar to PR96818 which I can reproduce. It's not the exact same pathway, but they both end up calling find_case_label_range() which I have definitely touched with my patch. I will mark this as depending on 96818 for now, and perhaps the reporter can monitor that PR for proposed fixes. Thanks for reporting this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 [Bug 96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
[Bug middle-end/87798] EH lowering is creating a gimple_switch statement with type-incompatible index and case labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87798
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed|2018-10-30 00:00:00 |2020-08-27
--- Comment #1 from Aldy Hernandez ---
This seems to be the same problem we're seeing in PR96818, which interestingly
is C++, so this affects more than just Ada:
bool operatorY ();
struct l
{
int m;
int k;
void n ();
l ()
{
while (operatorY ())
switch ((unsigned char) k)
case 0:
{
n ();
case 1:if (m)
;
}
}
};
void
p ()
{
l ();
}
In simplify_stmt_for_jump_threading we see:
(gdb) p debug(switch_stmt)
switch (_6) [33.33%], case 0: [33.33%], case 1:
[33.33%]>
;; Type of switch operand _6 is "int":
(gdb) p debug_generic_stmt(switch_stmt->op[0].typed.type)
int
;; gimple_switch_label(switch_stmt, 1):
(gdb) p debug_generic_stmt(switch_stmt->op[2])
case 0:;
;; Type of CASE_LOW of case 0 is unsigned char:
(gdb) p debug_generic_stmt(switch_stmt->op[2].exp.operands[0].typed.type)
unsigned char
I won't go into the details of the other PR, but suffice to say that it's
caused by switch operands being a different type than the case low/high values.
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
Aldy Hernandez changed:
What|Removed |Added
CC||jason at redhat dot com,
||law at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Depends on||87798
--- Comment #3 from Aldy Hernandez ---
[Could other gimple experts pontificate here?]
This is caused by the problem reported in PR87798.
We have a switch_stmt with a control variable of type int:
int _6;
...
_6 = _5 & 255;
switch (_6) [33.33%], case 0: [33.33%], case 1:
[33.33%]>
But the cases are unsigned char:
(gdb) p debug_tree(case_high)
constant 1>
This is causing us to intersect incompatible ranges:
(gdb) p debug (range_of_op)
int [0, 255]
$21 = void
(gdb) p debug (label_range)
unsigned char [0, 1]
$22 = void
(gdb)
Are incompatible switch operands and labels valid gimple? I would say no.
This look like a latent bug.
FWIW, the reason this was working before was because the original code used
tree_int_cst_compare which upgrades everything to a widest_int before doing the
comparison:
inline int
tree_int_cst_compare (const_tree t1, const_tree t2)
{
return wi::cmps (wi::to_widest (t1), wi::to_widest (t2));
}
I could hack around it, but would rather we fix the underlying problem.
Is this valid gimple or not?
Thanks.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87798
[Bug 87798] EH lowering is creating a gimple_switch statement with
type-incompatible index and case labels
[Bug middle-end/87798] EH lowering is creating a gimple_switch statement with type-incompatible index and case labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87798
--- Comment #2 from Aldy Hernandez ---
And a C version:
int a, b, c;
void d() {
unsigned short e;
while (b)
;
e = (e + 5) / 0;
switch (e)
case 0:
case 3:
c = a;
}
[Bug tree-optimization/96823] ice from irange::irange_intersect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96823 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||aldyh at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Aldy Hernandez --- This is a duplicate of 96818. We're trying to intersect incompatible ranges because the switch control variable type is not the same as the label type. (gdb) p debug(switch_stmt) switch (_10) [50.00%], case 0: [50.00%], case 3: [50.00%]> $3 = void (gdb) p debug(range_of_op) int [0, 65535] <-- int $4 = void (gdb) p debug(label_range) short unsigned int [0, 3] <-- short unsigned *** This bug has been marked as a duplicate of bug 96818 ***
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 Aldy Hernandez changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from Aldy Hernandez --- *** Bug 96823 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 Aldy Hernandez changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Aldy Hernandez --- I would still like to get to the root of the problem, but in the meantime we could easily hack around it by casting the label range to the switch operand type (or is it the other way around per language rules?): diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 8c1a1854daa..434ddcdd6ed 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -3850,6 +3850,7 @@ find_case_label_range (gswitch *switch_stmt, const irange *range_of_op) if (!case_high) case_high = CASE_LOW (max_label); widest_irange label_range (CASE_LOW (min_label), case_high); + range_cast (label_range, range_of_op->type ()); label_range.intersect (range_of_op); if (label_range.undefined_p ()) return gimple_switch_label (switch_stmt, 0);
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 Aldy Hernandez changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #6 from Aldy Hernandez --- *** Bug 96813 has been marked as a duplicate of this bug. ***
[Bug bootstrap/96813] [11 Regression] Broken bootstrap-lto-lean profiled bootstrap since r11-2883-gbf19cbc9cea6161f3deb63040601090828c44c53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96813 Aldy Hernandez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Aldy Hernandez --- Confirmed that this is the same issue. Bootstrap succeeds with the workaround in 96818. *** This bug has been marked as a duplicate of bug 96818 ***
[Bug tree-optimization/96967] [11 Regression] ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-08 Ever confirmed|0 |1 --- Comment #1 from Aldy Hernandez --- Confirmed. This is the same issue as PR96818. It's another intersect that's missing a cast. Testing the following patch: diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index f7b0692..b493e40 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -3828,6 +3828,8 @@ find_case_label_range (gswitch *switch_stmt, const irange *range_of_op) tree case_high = CASE_HIGH (label) ? CASE_HIGH (label) : CASE_LOW (label); int_range_max label_range (CASE_LOW (label), case_high); + if (!types_compatible_p (label_range.type (), range_of_op->type ())) + range_cast (label_range, range_of_op->type ()); label_range.intersect (range_of_op); if (label_range == *range_of_op) return label;
[Bug tree-optimization/96967] [11 Regression] ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Aldy Hernandez --- fixed in trunk
[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131 --- Comment #17 from Aldy Hernandez --- Author: aldyh Date: Thu Oct 17 12:38:38 2019 New Revision: 277107 URL: https://gcc.gnu.org/viewcvs?rev=277107&root=gcc&view=rev Log: PR tree-optimization/92131 * tree-vrp.c (value_range_base::dump): Display +INF for both pointers and integers when appropriate. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/92111] [10 Regression] ICE during GIMPLE pass: dom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92111 --- Comment #5 from Aldy Hernandez --- Please include any flags that were used in building things. For example, it looks like it needs at least -std=c++17 to work. I can't reproduce with a ./cc1plus -O2. I also can't reproduce with -flto: ./xgcc -B./ a.ii -w -O2 -std=c++17 -flto /usr/bin/ld: /lib/../lib64/crt1.o: in function `_start': (.text+0x24): undefined reference to `main' /usr/bin/ld: /tmp/cczITmdb.ltrans0.ltrans.o:(.qtversion[qt_version_tag]+0x0): undefined reference to `qt_version_tag' collect2: error: ld returned 1 exit status Have you tried with a more recent trunk? Can you reproduce at all without -flto, as LTO is a bit trickier to debug, and may require you sending more files. Can you narrow down the source to the smallest subset that can still reproduce the bug?
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #5 from Aldy Hernandez 2013-02-05 15:57:55 UTC --- I'll take a peek.
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-05 Ever Confirmed|0 |1 --- Comment #8 from Aldy Hernandez 2013-02-05 23:52:30 UTC --- Confirmed with cloog 0.18 and isl 0.11, both installed in /build/install, and configuring GCC with: /source/gcc/configure --disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran --with-cloog=/build/install --with-isl=/build/install houston:/build/55022-f90/gcc/pr55022$ ls air_main.f90 botwall.f90 datax.inp datay.inp topwall.f90 houston:/build/55022-f90/gcc/pr55022$ ../xgcc -B../ -O2 -fgraphite-identity air_main.f90 botwall.f90 topwall.f90 -L ../../x86_64-unknown-linux-gnu/libgfortran/.libs/ -lgfortran -lm houston:/build/55022-f90/gcc/pr55022$ ./a.out ... ... 1290.000625547555 0.01001.945421 1440.000674419139 0.01002.198194 1660.000728576510 0.0100 NaN 168 100.000735868323 0.0100 NaN
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Aldy Hernandez changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Aldy Hernandez 2013-02-06 18:18:54 UTC --- I'm sorry, but the reporter is going to have to reduce this significantly before we can debug this. This is a huge mess of spaghetti code with tons of global and common variables scattered throughout, as well as state being passed around in files. Dominique, please reduce this to the smallest amount of reproducible code, so we can attack this. Avoid reading and writing to files (as I see, these have only a minimal amount of data anyhow), and global variables if at all possible. Please only keep the code that is relevant to reproduce the problem.
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Aldy Hernandez changed: What|Removed |Added CC||matz at gcc dot gnu.org, ||sebpop at gmail dot com --- Comment #10 from Aldy Hernandez 2013-02-06 21:08:02 UTC --- This regression started when we moved graphite from using PPL over to ISL. The patch submission started here: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html 2012-07-02 Richard Guenther Michael Matz Tobias Grosser Sebastian Pop and the revision is trunk@189156. Provided this test gets further reduced as I have mentioned in comment 9, can any of you gentlemen look at this?
[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-02-07 CC||aldyh at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Aldy Hernandez 2013-02-07 16:11:34 UTC --- Isn't this a duplicate of PR 52272? That is, fixing 52272, along with the 410.bwaves regressions, also fixes this PR? Can we close this as a duplicate?
[Bug middle-end/55943] [4.6/4.7/4.8 Regression] ICE in gen_reg_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55943 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-07 CC||aldyh at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Aldy Hernandez 2013-02-07 21:13:06 UTC --- Confirmed with a cross to --target=ia64-linux-gnu.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #7 from Aldy Hernandez 2013-02-07 22:43:25 UTC --- I'll take a look.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 --- Comment #8 from Aldy Hernandez 2013-02-07 22:44:17 UTC --- I'll take a look.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555
--- Comment #9 from Aldy Hernandez 2013-02-07
23:24:42 UTC ---
Further reduced testcase, reproducible on both C and C++:
float farg;
unsigned val;
void __attribute__((optimize("O")))
test()
{
val = __builtin_ceilf(farg);
}
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 --- Comment #10 from Aldy Hernandez 2013-02-09 19:07:44 UTC --- Created attachment 29404 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29404 untested patch Untested proposed patch.
[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868 Aldy Hernandez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #5 from Aldy Hernandez 2013-02-09 19:15:15 UTC --- *** This bug has been marked as a duplicate of bug 52272 ***
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regression of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #17 from Aldy Hernandez 2013-02-09 19:15:15 UTC --- *** Bug 52868 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #4 from Aldy Hernandez 2013-02-11 22:02:02 UTC --- Honza. Are you interested in investigating this as Richard suggests, or can we close this as WONTFIX?
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Aldy Hernandez changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-12 CC||aldyh at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Aldy Hernandez 2013-02-12 17:13:18 UTC --- Confirmed with OpenFOAM 2.1.1. I'll see if I can narrow this down.
[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290 --- Comment #4 from Aldy Hernandez 2013-02-13 17:14:46 UTC --- Created attachment 29441 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29441 testcase Preprocessed testcase reproducible with ./cc1plus -O3
[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Aldy Hernandez 2013-02-13 17:16:12 UTC --- Duplicate. I even confirmed that Jakub's untested patch for 56265 fixes the problem. *** This bug has been marked as a duplicate of bug 56265 ***
[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 Aldy Hernandez changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Aldy Hernandez 2013-02-13 17:16:12 UTC --- *** Bug 56290 has been marked as a duplicate of this bug. ***
[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56108 Aldy Hernandez changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #2 from Aldy Hernandez 2013-02-15 19:45:55 UTC --- Mine.
[Bug middle-end/56140] GCC inlines incorrect function in __transaction_relaxed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56140 Aldy Hernandez changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #1 from Aldy Hernandez 2013-02-15 19:46:13 UTC --- Mine.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #21 from Aldy Hernandez 2013-02-18
19:38:40 UTC ---
Another less invasive option could be to force the return value of my_ldexp()
to go through memory, thus chopping off the excess precision before returning:
--- a.c2013-02-18 20:37:23.0 +0100
+++ b.c2013-02-18 20:36:42.0 +0100
@@ -404,7 +404,11 @@
e += 1;
}
} else
- return d;
+ {
+volatile double force_round = d;
+return force_round;
+
+ }
}
}
But basically, you'd have to carefully keep track of when you have to use
volatiles.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 --- Comment #12 from Aldy Hernandez 2013-02-19 00:04:59 UTC --- Author: aldyh Date: Tue Feb 19 00:04:49 2013 New Revision: 196129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196129 Log: PR target/52555 * genopinit.c (raw_optab_handler): Use this_fn_optabs. (swap_optab_enable): Same. (init_all_optabs): Use argument instead of global. * tree.h (struct tree_optimization_option): New field target_optabs. * expr.h (init_all_optabs): Add argument to prototype. (TREE_OPTIMIZATION_OPTABS): New. (save_optabs_if_changed): Protoize. * optabs.h: Declare this_fn_optabs. * optabs.c (save_optabs_if_changed): New. Declare this_fn_optabs. (init_optabs): Add argument to init_all_optabs() call. * function.c (invoke_set_current_function_hook): Handle per function optabs. * function.h (struct function): New field optabs. * config/mips/mips.c (mips_set_mips16_mode): Handle when optimization_current_node has changed. * target-globals.h (save_target_globals_default_opts): Protoize. * target-globals.c (save_target_globals_default_opts): New. c-family/ * c-common.c (handle_optimize_attribute): Call save_optabs_if_changed. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52555.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/config/mips/mips.c trunk/gcc/expr.h trunk/gcc/function.c trunk/gcc/function.h trunk/gcc/genopinit.c trunk/gcc/optabs.c trunk/gcc/optabs.h trunk/gcc/target-globals.c trunk/gcc/target-globals.h trunk/gcc/tree.h
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Aldy Hernandez 2013-02-19 00:14:33 UTC --- fixed on trunk
[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56108
Aldy Hernandez changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #3 from Aldy Hernandez 2013-02-19
02:15:12 UTC ---
The first statement of this relaxed transaction is an inline asm:
__transaction_relaxed { __asm__(""); }
The problem here is we don't insert a BUILT_IN_TM_IRREVOCABLE call at the
beginning of the transaction because we bypass doing so here:
for (region = d->all_tm_regions; region; region = region->next)
{
/* If we're sure to go irrevocable, don't transform anything. */
if (d->irrevocable_blocks_normal
&& bitmap_bit_p (d->irrevocable_blocks_normal,
region->entry_block->index))
{
transaction_subcode_ior (region, GTMA_DOES_GO_IRREVOCABLE);
transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE);
continue;
}
need_ssa_rename |=
ipa_tm_transform_calls (node, region, region->entry_block,
d->irrevocable_blocks_normal);
}
I don't understand why we explicitly bypass here. I mean, if this bypass was
for TM clones, we're already handling them up-stack in the call to
ipa_tm_transform_clone.
Perhaps we want something like this:
if (d->irrevocable_blocks_normal
&& bitmap_bit_p (d->irrevocable_blocks_normal,
region->entry_block->index))
- {
- transaction_subcode_ior (region, GTMA_DOES_GO_IRREVOCABLE);
- transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE);
- continue;
- }
+ transaction_subcode_ior (region, GTMA_DOES_GO_IRREVOCABLE);
need_ssa_rename |=
But it's causing: FAIL: gcc.dg/tm/memopt-1.c, which I'm investigating.
[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56108 --- Comment #4 from Aldy Hernandez 2013-02-20 15:43:34 UTC --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00947.html
[Bug c++/56419] [4.8 regression] transactions in for-loops disappear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56419 Aldy Hernandez changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-21 AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Aldy Hernandez 2013-02-21 14:46:37 UTC --- Confirmed. Worked in 4.7. Mine.
[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56108 --- Comment #5 from Aldy Hernandez 2013-02-21 20:16:34 UTC --- Author: aldyh Date: Thu Feb 21 20:16:26 2013 New Revision: 196213 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196213 Log: PR middle-end/56108 * trans-mem.c (execute_tm_mark): Do not expand transactions that are sure to go irrevocable. testsuite/ * gcc.dg/tm/memopt-1.c: Declare functions transaction_safe. Added: trunk/gcc/testsuite/gcc.dg/tm/pr56108.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tm/memopt-1.c trunk/gcc/trans-mem.c
[Bug middle-end/56108] Asm statement in transaction_relaxed crashes compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56108 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Aldy Hernandez 2013-02-21 20:31:28 UTC --- And now closing for real...
[Bug middle-end/56140] GCC inlines incorrect function in __transaction_relaxed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56140 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Aldy Hernandez 2013-02-21 20:35:40 UTC --- With my patch for PR56108, since this transaction is obviously irrevocable, we will no longer instrument the inlined code, thus fixing this PR as well. Fixed in trunk.
[Bug c++/56419] [4.8 regression] transactions in for-loops disappear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56419 --- Comment #3 from Aldy Hernandez 2013-02-22 14:54:32 UTC --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01058.html
[Bug c++/56419] [4.8 regression] transactions in for-loops disappear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56419 --- Comment #4 from Aldy Hernandez 2013-02-26 12:40:36 UTC --- Author: aldyh Date: Tue Feb 26 12:40:27 2013 New Revision: 196282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196282 Log: PR c++/56419 * semantics.c (begin_transaction_stmt): Set TREE_SIDE_EFFECTS. (build_transaction_expr): Same. Added: trunk/gcc/testsuite/g++.dg/tm/pr56419.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/56419] [4.8 regression] transactions in for-loops disappear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56419 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Aldy Hernandez 2013-02-26 12:41:35 UTC --- Fixed in trunk.
[Bug tree-optimization/49234] [4.5/4.7/4.8/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #6 from Aldy Hernandez 2013-02-28 13:51:36 UTC --- I'll take a look.
[Bug tree-optimization/49234] [4.5/4.7/4.8/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #7 from Aldy Hernandez 2013-02-28 15:49:34 UTC --- Created attachment 29555 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29555 proof of concept: untested
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
Aldy Hernandez changed:
What|Removed |Added
CC||dnovillo at gcc dot
||gnu.org, rguenth at gcc dot
||gnu.org
--- Comment #8 from Aldy Hernandez 2013-02-28
16:00:26 UTC ---
As Jakub explained in comment 3, this is a problem in the VRP code.
To avoid bouncing from max to max (or slowly increasing to +INF), we
immediately go to +INF(OVF), even if we have correct ranges.
One alternative that I show in the attached patch (comment 7: proof of concept
hack, untested), is to keep track of how many times we are iterating through an
SSA. If we go past an arbitrary number (say 10), we can then go to +INF.
So basically, keep track of a few states, but if it starts getting ridiculous
step it up to INF. Similarly for the cmp_min code. The relevant part of my
patch is shown below.
Does this seem like an approach worth exploring (this silences the warning), or
does anyone have a better suggestion?
- /* Similarly, if the new maximum is smaller or larger than
- the previous one, go all the way to +INF. */
- if (cmp_max < 0 || cmp_max > 0)
+ /* Adjust to a new maximum if it has changed. For the first few
+ iterations, adjust the maximum accordingly. However, if
+ we're iterating too much, go all the way to +INF to avoid
+ either bouncing around or iterating millions of times to
+ reach +INF. */
+ if ((cmp_max < 0 || cmp_max > 0))
{
- if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
- || !vrp_var_may_overflow (lhs, phi))
-vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
- else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
-vr_result.max =
-positive_overflow_infinity (TREE_TYPE (vr_result.max));
+ lhs_vr->visited++;
+ if (lhs_vr->visited < 10) // Handle the first 10 iterations.
+vr_result.max = lhs_vr->max;
+ else
+{
+ if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
+ || !vrp_var_may_overflow (lhs, phi))
+vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
+ else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
+vr_result.max =
+ positive_overflow_infinity (TREE_TYPE (vr_result.max));
+}
}
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 Aldy Hernandez changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-05 CC||aldyh at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|Compiler ICE when compiling |[4.8 Regression] Compiler |with -mips16|ICE when compiling with ||-mips16 Ever Confirmed|0 |1 --- Comment #1 from Aldy Hernandez 2013-03-05 16:23:34 UTC --- Confirmed.
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #2 from Aldy Hernandez 2013-03-05 16:24:35 UTC --- Created attachment 29588 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29588 reduced testcase
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #16 from Aldy Hernandez 2013-03-05
18:00:12 UTC ---
Created attachment 29590
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29590
WIP: proposed patch special casing constant phi arguments
Ian.
Sure, I can handle SSA_NAME_VAR equality, but then we won't be able to handle
self referential operations like the one in gcc.dg/Wstrict-overflow-12.c. For
example, with your suggested approach (in this attached patch), we fail here:
for (i = 1, bits = 1; i > 0; i += i) /* { dg-warning "assuming signed
overflow does not occur" "correct warning" } */
++bits;
Because we encounter something like this which is perfectly valid with your
approach:
i_1 = PHI <1(2), i_4(3)>
[Bug tree-optimization/49234] [4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #18 from Aldy Hernandez 2013-03-06 16:11:22 UTC --- Created attachment 29599 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29599 do not set overflow on [+-]INF This is Richi's suggestion from comment 10. The problem is that it obviously causes the VRP strict overflow warnings to fail: $ make check-gcc RUNTESTFLAGS=dg.exp=*strict* FAIL: gcc.dg/Wstrict-overflow-12.c correct warning (test for warnings, line 13) FAIL: gcc.dg/Wstrict-overflow-13.c correct warning (test for warnings, line 14) FAIL: gcc.dg/Wstrict-overflow-14.c (test for warnings, line 13) FAIL: gcc.dg/Wstrict-overflow-15.c (test for warnings, line 13) FAIL: gcc.dg/Wstrict-overflow-21.c correct warning (test for warnings, line 8) FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return bits" FAIL: c-c++-common/restrict-1.c -Wc++-compat (test for excess errors) If y'all are willing to work with this patch and XFAIL these tests, I'm more than happy to test and commit this patch, otherwise I may have to drop this for now, as I am not volunteering to fix VRP for SSA cycles as suggested. I am switching gears from 4.8 bugfixing into other duties shortly... Let me know...
[Bug tree-optimization/49234] [4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #20 from Aldy Hernandez 2013-03-06 16:28:12 UTC --- Oh, no worries Ian. I totally agree. I just wanted to put all this out there, since I'm unfortunately about to drop it. We should probably close this as a WONTFIX, or perhaps just drop this in priority. A false positive is not the end of the world, so I don't see how this merits a P2 for the release. Thoughts?
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #3 from Aldy Hernandez 2013-03-06 17:54:41 UTC --- This is ICEing here: /* ?? If this fails, we should temporarily restore the default target first (set_cfun (NULL) ??), do the rest of this function, and then restore it. */ gcc_assert (this_target_optabs == &default_target_optabs); In this case, this_target_optabs is being set in: mips_set_mips16_mode() -> save_target_globals_default_opts() -> save_target_globals() -> restore_target_globals() ... this_target_optabs = g->optabs; We can't do exactly as the comment above the ICE says, since cfun isn't even set at this point (we are being called from the parser).
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #5 from Aldy Hernandez 2013-03-06 23:01:26 UTC --- (In reply to comment #4) > Created attachment 29601 [details] > Tentative patch > > How about this patch? Only lightly tested. It fixes the testcase > and the pr43564.c failure that I'm seeing on MIPS16 runs. Boy, this is getting quite confusing. Do you think perhaps we could document the plethora of target optabs, fn_optabs, base_optabs, etc. And BTW, thanks for the patch Richard.
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 --- Comment #3 from Aldy Hernandez 2012-08-21 17:46:26 UTC --- My bad... I'm on this.
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184
Aldy Hernandez changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Aldy Hernandez 2012-09-05
21:15:52 UTC ---
What I was trying to test here originally was whether the LIM pass kept a flag
of changes to "count" and only if the flag was true, allow the cached version
of "count" to be stored.
Technically, I could get away with only checking the presence of count_lsm_flag
in the dump, though I realize that this also is an imperfect solution if a
previous pass changed things around.
Apart from checking count_lsm_flag, the only thing I can think of is replacing
this test with one within the simulate-thread/ infrastructure that actually
checks that no caching occurs unless p->data > 0.
Richard, which solution do you prefer, or do you recommend something else?
void func()
{
struct obj *p;
for (p = q; p; p = p->next)
if (p->data > 0)
count++;
}
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 --- Comment #6 from Aldy Hernandez 2012-09-05 22:43:03 UTC --- Created attachment 28137 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28137 proposed patch Proposed patch using the simulate-thread harness.
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 --- Comment #9 from Aldy Hernandez 2012-09-07 16:00:18 UTC --- Author: aldyh Date: Fri Sep 7 16:00:07 2012 New Revision: 191079 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191079 Log: PR testsuite/54184 * gcc.dg/pr52558-1.c: Delete. * gcc.dg/simulate-thread/speculative-store-2.c: New. Added: trunk/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-2.c Removed: trunk/gcc/testsuite/gcc.dg/pr52558-1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Aldy Hernandez 2012-09-07 18:23:15 UTC --- (In reply to comment #8) > What about gcc.dg/pr52558-2.c and gcc.dg/tm/reg-promotion.c not handled by the > patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00390.html? I have pending patches for these too: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00485.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00487.html Thanks for reporting this. I will now close this PR, as the original problem reported has been fixed and committed.
[Bug c/54149] write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-07 CC||amacleod at redhat dot com AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Aldy Hernandez 2012-09-07 19:45:29 UTC --- This looks like a data race introduced by LIM. Ughh, I thought I had this pass all fixed... I'll take a look.
[Bug middle-end/54149] write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149 --- Comment #3 from Aldy Hernandez 2012-09-11 12:28:11 UTC --- Author: aldyh Date: Tue Sep 11 12:28:02 2012 New Revision: 191179 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191179 Log: PR middle-end/54149 * tree-ssa-loop-im.c (execute_sm_if_changed_flag_set): Only set flag for writes. Added: trunk/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug middle-end/54149] write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Aldy Hernandez 2012-09-11 12:30:36 UTC --- fixed on trunk
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 --- Comment #6 from Aldy Hernandez 2012-09-12 19:52:55 UTC --- I'll take a look.
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 --- Comment #6 from Aldy Hernandez 2012-09-12 19:52:55 UTC --- I'll take a look. --- Comment #7 from Aldy Hernandez 2012-09-12 19:53:30 UTC --- I'll take a look.
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 --- Comment #8 from Aldy Hernandez 2012-09-14 21:20:23 UTC --- Created attachment 28195 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28195 reduced testcase Further reduced testcase that triggers on either C/C++.
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
||dnovillo at gcc dot
||gnu.org, rguenth at gcc dot
||gnu.org
--- Comment #9 from Aldy Hernandez 2012-09-19
19:44:14 UTC ---
Richi, Diego. Perhaps you can shed light on this.
Here we have a loop unroll that triggers a "virtual def operand missing..." for
a GIMPLE_TRANSACTION:
int vec[500];
void func()
{
__transaction_relaxed
{
vec[123] = 456;
}
}
main()
{
int i;
for(i = 0; i < 10; ++i)
func();
}
The unroller wants to unroll into something like:
:
# .MEM_6 = VDEF <.MEM_13>
__transaction_relaxed<-- PROBLEMATIC INSN (VDEF's)
:
# .MEM_9 = VDEF <.MEM_59>
vec[123] = 456;
# .MEM_2 = VDEF <.MEM_9>
__builtin__ITM_commitTransaction ();
:
ivtmp_14 = 9;
# .MEM_11 = VDEF <.MEM_13>
__transaction_relaxed
:
# .MEM_18 = VDEF <.MEM_59>
vec[123] = 456;
# .MEM_19 = VDEF <.MEM_18>
__builtin__ITM_commitTransaction ();
etc etc etc.
Putting aside how incredibly inefficient this is... (We should be duplicating
the vector store, not the entire transaction)...
The problem here is that, after unrolling, the VDEF of the problematic insn is
.MEM_6, but the DEF_OP of the insn is .MEM_59. So gimple_vdef() !=
gimple_vdef_op() and we trigger a "virtual def operand missing for stmt".
The problem is that the unroller's call to gimple_duplicate_bb() will make a
copy of the problematic instruction, maintaining its gimple_vdef, but changing
all its def_ops from under us, thus making gimple_vdef() != gimple_vdef_op().
Before loop unrolling we have this snippet that is about to be unrolled:
:
# .MEM_13 = PHI <.MEM_8(6), .MEM_3(D)(2)>
# ivtmp_1 = PHI
# .MEM_6 = VDEF <.MEM_13>
__transaction_relaxed
After loop unrolling the above remains unchanged, but the following is inserted
*before* bb 3. [Note, the following is after update_ssa(TODO_update_ssa), but
before cleanup_tree_cfg() for clarity.]
:
# .MEM_12 = PHI <.MEM_3(D)(2)>
# ivtmp_5 = PHI <10(2)>
# .MEM_6 = VDEF <.MEM_13> <-- *** -->
<-- shouldn't this be <.MEM_12> ?
<-- *** -->
__transaction_relaxed
...
...more unrolling
...
:
# .MEM_57 = PHI <.MEM_8(39)>
# ivtmp_58 = PHI
# .MEM_53 = VDEF <.MEM_13><-- ** -->
<-- shouldn't this be <.MEM_57>
<-- ** -->
__transaction_relaxed
...
...
..
Notice that both BB8 and BB40 invalidate MEM_13 in its virtual definition.
Shouldn't the VDEF<.MEM_13> be rewritten as I have indicated above? Especially
since now .MEM_13 is defined much further down in bb 3:
# invalidates VDEF<.MEM_13>
...
# invalidates VDEF<.MEM_13>
..
# define .MEM_13 =
It seems gimple_duplicate_bb() renames all the phis and the operands, but does
not update the VDEF's for the transaction. Gimple_duplicate_bb() says it
doesn't maintain SSA form, so I assume this in on purpose (?). So how is this
supposed to be cleaned up? Or is this even the problem?
[Bug middle-end/53850] [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-21 AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Aldy Hernandez 2012-09-21 20:11:43 UTC --- Mine.
[Bug middle-end/53850] [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 --- Comment #3 from Aldy Hernandez 2012-09-21 20:12:55 UTC --- Created attachment 28245 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28245 proposed patch being tested
[Bug middle-end/53850] [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 --- Comment #4 from Aldy Hernandez 2012-09-25 18:47:40 UTC --- Author: aldyh Date: Tue Sep 25 18:47:35 2012 New Revision: 191742 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191742 Log: PR middle-end/53850 * trans-mem.c (expand_call_tm): Handle late built built-ins. Added: trunk/gcc/testsuite/gcc.dg/tm/pr53850.c Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug middle-end/53850] [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Aldy Hernandez 2012-09-25 18:59:11 UTC --- fixed on mainline
[Bug c/46480] [trans-mem] Uninstrumented code path is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46480 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-25 CC||torvald at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Aldy Hernandez 2012-09-25 19:07:46 UTC --- Mine.
[Bug c++/54893] unable to access volatile variable within relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54893 Aldy Hernandez changed: What|Removed |Added CC||pmarlier at gcc dot gnu.org --- Comment #1 from Aldy Hernandez 2012-10-11 10:40:53 UTC --- Please see bug 46654. This error was added on purpose. Has the specification changed and volatiles are now allowed inside transactions?
[Bug c++/54893] unable to access volatile variable within relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54893 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-11 AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Aldy Hernandez 2012-10-11 20:29:13 UTC --- Created attachment 28427 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28427 untested patch Testing...
[Bug tree-optimization/54900] write introduction incorrect wrt the C11 memory model (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54900 --- Comment #2 from Aldy Hernandez 2012-10-14 12:51:15 UTC --- Created attachment 28444 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28444 reduced testcase
[Bug tree-optimization/54900] write introduction incorrect wrt the C11 memory model (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54900 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-14 Ever Confirmed|0 |1
[Bug rtl-optimization/54900] write introduction incorrect wrt the C11 memory model (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54900 --- Comment #3 from Aldy Hernandez 2012-10-17 20:59:43 UTC --- Author: aldyh Date: Wed Oct 17 20:59:40 2012 New Revision: 192548 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192548 Log: PR rtl-optimization/54900 * ifcvt.c (noce_can_store_speculate_p): Call memory_must_be_modified_in_insn_p. * alias.c (memory_must_be_modified_in_insn_p): New. (set_dest_equal_p): New. * rtl.h (memory_must_be_modified_in_p): Protoize. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/ifcvt.c trunk/gcc/rtl.h
[Bug middle-end/54893] unable to access volatile variable within relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54893 --- Comment #5 from Aldy Hernandez 2012-10-17 21:18:21 UTC --- Author: aldyh Date: Wed Oct 17 21:18:16 2012 New Revision: 192549 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192549 Log: PR middle-end/54893 * trans-mem.c (diagnose_tm_1_op): Allow volatiles inside relaxed transactions. Added: trunk/gcc/testsuite/c-c++-common/tm/pr54893.c Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug middle-end/54893] unable to access volatile variable within relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54893 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Aldy Hernandez 2012-10-17 21:19:29 UTC --- fixed on mainline
[Bug tree-optimization/54906] write introduction incorrect wrt the C++11 memory model (case with atomic accesses)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54906 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED CC||aldyh at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Aldy Hernandez 2012-10-18 23:44:01 UTC --- resolved with patch to 54900.
[Bug rtl-optimization/54900] write introduction incorrect wrt the C11 memory model (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54900 --- Comment #5 from Aldy Hernandez 2012-10-18 23:46:04 UTC --- I am leaving this PR open while I address the corner case presented by Jakub somewhere in this thread: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01763.html ...though technically the testcase in this PR has been fixed :).
[Bug c/46480] [trans-mem] Uninstrumented code path is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46480 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Aldy Hernandez 2012-11-09 18:50:02 UTC --- Implemented on mainline. Yay yay!
[Bug c++/46654] [trans-mem] "volatile" objects must not be allowed in a safe statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46654 Aldy Hernandez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.22 13:51:33 Ever Confirmed|0 |1 --- Comment #2 from Aldy Hernandez 2010-12-22 13:51:33 UTC --- Patrick. I haven't analyzed your patch yet, but it causes the following regressions: FAIL: g++.dg/tm/pr45940-3.C (test for excess errors) FAIL: g++.dg/tm/pr45940-4.C (test for excess errors) FAIL: g++.dg/tm/pr46269.C (internal compiler error) FAIL: g++.dg/tm/pr46269.C (test for excess errors) Try to run the regression suite to test your patch first. It's a good first round of testing. You can run it with "make check" from the toplevel build directory. You can compare results with and without your patch. To run just the TM compiler tests you can do: make check-gcc RUNTESTFLAGS=tm.exp I have a similar patch to yours that I'm playing with, that unfortunately also causes the pr46269.C regression, though not the pr45940-* failures. I am debugging and will report shortly. Thanks.
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941
--- Comment #4 from Aldy Hernandez 2010-12-23
16:19:12 UTC ---
Patrick.
You will find out that when hacking on GCC, everything is intrusive in
non-obvious ways :).
What I had in mind was something simple like this, since push_cp_library_fn()
only gets called when creating delete/new operators.
Index: cp/decl.c
===
--- cp/decl.c (revision 168123)
+++ cp/decl.c (working copy)
@@ -3775,6 +3775,8 @@ push_cp_library_fn (enum tree_code opera
operator_code,
type);
pushdecl (fn);
+ if (flag_tm)
+apply_tm_attr (fn, get_identifier ("transaction_pure"));
return fn;
}
However, this is exhibiting an unrelated bug with inlining that I am
investigating.
Thanks for all your bugreports! They've made my life easier.
