https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
Andrew Macleod changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
--- Comment #4 from Andrew Macleod ---
When a range is being calculated for an ssa-name, the propagation process often
goes along back edges. These back edges sometime require other ssa-names which
have not be processed yet. These are flagged as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #4 from Andrew Macleod ---
I just checked a patch in for PR 101014 which I suspect will fix this as well..
want to give it a try off trunk? I plan to port it to gcc 11 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
Andrew Macleod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #6 from Andrew Macleod ---
WE collided making comments :-)
--- or maybe not.. that traceback doesn't look like it would be affected :-(.
The traceback also doesn't look like its in an infinite loop?.. there can be
long chains of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #8 from Andrew Macleod ---
ah. So this is an issue with excessive stack consumption. yeah, we don't really
try to reign that in, so certain patterns can get quite deep.
I am unfamiliar with what mitigations/flags the compiler has fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #10 from Andrew Macleod ---
I would imagine there is some check I should be making that i was unaware of..
but since I'm unaware of it, I don't know what it is :-)
This wouldn't be a "dont use -O2" issue, this would be an "Andrew, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #12 from Andrew Macleod ---
My understanding from a quick check around is we usually expect 8-10 MB of
stack space. I have an idea how to flatten the call stack a bit, so leave this
open for that purpose if nothing else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 101014, which changed state.
Bug 101014 Summary: [12 Regression] Big compile time hog with -O3 since
r12-1268-g9858cd1a6827ee7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110
--- Comment #2 from Andrew Macleod ---
I think the patch for PR 101014 resolves this testcase... Let me know if this
is fixed on trunk now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101148
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
--- Comment #17 from Andrew Macleod ---
Created attachment 51050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51050&action=edit
patch to fix the issue
The gift that keeps on giving eh.
OK, this should solve the infinite loop. Give it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101148
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
Andrew Macleod changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 101014, which changed state.
Bug 101014 Summary: [12 Regression] Big compile time hog with -O3 since
r12-1268-g9858cd1a6827ee7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189
--- Comment #2 from Andrew Macleod ---
We always register relations on outgoing edges from a conditional.
in this case
_2 = -f_6; // f_6 was known to be [4,5]
if (_2 == f_6) // This this was known to fail because _2 was [-5, -4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
--- Comment #7 from Andrew Macleod ---
I think this is our old friend 1-bit signed overflow.
for 1 signed bit values, varying is [-1, 0]
range-op::build_lt checks to see if UB - 1 overflows, and if it does, then the
result is undefined.
wi:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341
--- Comment #5 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #2)
> (In reply to Martin Liška from comment #1)
> > May be an opportunity for Ranger?
>
> Hmmm... I don't think so:
>
> :
> value.0_1 = (unsigned int) va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #21 from Andrew Macleod ---
(In reply to Richard Biener from comment #13)
> Yes, the fact that ranger doesn't operate as a usual propagator with a
> lattice
> makes things very difficult here. Note that my comment referred to code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #1 from Andrew Macleod ---
>From ccp2 :
Simulating block 2
Visiting statement:
c.2_1 = c;
which is likely CONSTANT
Lattice value changed to VARYING. Adding SSA edges to worklist.
Whereas in GCC12 I see:
Simulating block 2
Visi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #3 from Andrew Macleod ---
Hmm. It is not eliminated until VRP1 now. Looks like something in EVRP. lets
see...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #4 from Andrew Macleod ---
The IL is different in VRP2 between GCC12 and GCC13. IN GCC 12 I see:
[local count: 1073741824]:
b.2_1 = b;
_2 = b.2_1 <= 0;
h.0_20 = (unsigned short) _2;
_21 = h.0_20 + 65535;
_22 = (short i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #5 from Andrew Macleod ---
The key change is that condition:
_6 = f.5_5 << 4;
e = _6;
h_23 = (short int) _6;
if (_21 == -1)
goto ; [50.00%]
else
goto ; [50.00%]
On the false edge, we lose the ability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #6 from Andrew Macleod ---
and VRP1 turned that
if (_21 < 0)
into
if (_21 == -1)
So yes, that was a correct transformation in FRE3, but the side effect is we
lose the ability to look back and determine better ranges for _6 and h_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
--- Comment #4 from Andrew Macleod ---
Well, range does know there is a relationship.. or at least could know:
Partial equiv (i_23 pe8 _35)
Partial equiv (k_24 pe8 _35)
It knows they are both 8 bit equivalences of _35. I don't remember if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
--- Comment #5 from Andrew Macleod ---
Created attachment 54240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54240&action=edit
sample implementation
In fact that appears to work... The attached (untested) patch simply does
that at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #7 from Andrew Macleod ---
Created attachment 54269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54269&action=edit
patch in testing
Patch is in testing.
We added relation processing to GORI during stage 1, but its very ligh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108368
--- Comment #2 from Andrew Macleod ---
Not sure why it looks expensive, it is a lot cheaper than the original cache
propagation was, but still gets all the cases.
Regardless, the upcoming fix for 108356 fixes this PR as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #4 from Andrew Macleod ---
Created attachment 54270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54270&action=edit
possible patch
When the on-entry cache is updated for a block, all incoming ranges are unioned
together and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #5 from Andrew Macleod ---
The full comment is the test case is:
/* Verify offsets in an anti-range. */
<...>
/* The initial source range is valid but the final range after the access
has complete cannot be. The value menti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #10 from Andrew Macleod ---
Created attachment 54286
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54286&action=edit
proposed patch
There is a bug in the implementation of range-ops for shifts when the shift is
guaranteed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Andrew Macleod changed:
What|Removed |Added
Attachment #54286|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #3 from Andrew Macleod ---
Those specialized relations are handled within the floating point range-ops
code iirc. We established that none of the other floating point relations
needed to be exposed to non-floating point code.
The f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> I see fold_using_range::relation_fold_and_or
> which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because
> of
> relation_union (relation1, rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #7 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> I'm surprised by rr_union_table content.
> // VREL_VARYING
> { VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
> VREL_VARYING, VREL_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #17 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #15)
> I went through the whole rr_{intersect,union}_table tables and I think just
> --- gcc/value-relation.cc.jj 2023-01-02 09:32:42.088000605 +0100
> +++ gcc/valu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #18 from Andrew Macleod ---
Created attachment 54312
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54312&action=edit
possible patch
The only place I think it matters is in set_one_relation.
THis is the central point where we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
Andrew Macleod changed:
What|Removed |Added
Attachment #54312|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #22 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #21)
> (In reply to Andrew Macleod from comment #19)
> > Created attachment 54313 [details]
> > better patch
> >
> > A more consistent approach.. rather than direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #23 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #21)
> (In reply to Andrew Macleod from comment #19)
> > Created attachment 54313 [details]
> > better patch
> >
> > A more consistent approach.. rather than direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #25 from Andrew Macleod ---
Created attachment 54327
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54327&action=edit
possible patch
There's another infrastructure patch which precedes this one which turns
existing relation_un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 108306, which changed state.
Bug 108306 Summary: [12/13 Regression] false-positive -Warray-bounds warning
emitted with -fsanitize=shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #16 from Andrew Macleod ---
(In reply to Richard Biener from comment #15)
> In GCC 13.
Whups. Didn't even notice that. Same patch ok for GCC12 once testing
completes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 108306, which changed state.
Bug 108306 Summary: [12 Regression] false-positive -Warray-bounds warning
emitted with -fsanitize=shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #10 from Andrew Macleod ---
Fixed in GCC 13, unlikely to be ported to gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #11 from Andrew Macleod ---
To be clear, the reason it is unlikely to be ported to GCC12 is because this
depends on relation support in GORI to recognize the LHS and operand 1 are
equivalent. That support was first added in GCC13, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #5 from Andrew Macleod ---
I do not seem to be able to reproduce this... is it still valid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> Aldy/Andrew, any ideas about this?
patch already in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > (In reply to Jakub Jelinek from comment #3)
> > > Created attachment 54391 [details]
> > > gcc13-pr108639.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #6 from Andrew Macleod ---
This is the first release that we process relations in GORI. Up until recently
it was fairly ad-hoc what got passed in as a relation trio to the op?_range
routines. A couple of days ago I fleshed it out f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately that would mean for the non-equality cases that if
> lhs.undefined_p () we don't return undefined but false (aka VARYING).
> Another option is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > Unfortunately that would mean for the non-equality cases th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
--- Comment #3 from Andrew Macleod ---
OK, its been a while. Why is there a VUSE on the return? this is the IL
right from into-ssa:
int f (int a)
{
int _4;
:
# .MEM_2 = VDEF <.MEM_1(D)>
__asm__(" " : "=X" a_3 : : "memory");
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
--- Comment #6 from Andrew Macleod ---
diff --git a/gcc/tree-ssa-dce.cc b/gcc/tree-ssa-dce.cc
index b2fe9f4f55e..752785541e4 100644
--- a/gcc/tree-ssa-dce.cc
+++ b/gcc/tree-ssa-dce.cc
@@ -2140,6 +2140,7 @@ simple_dce_from_worklist (bitmap workli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108696
--- Comment #1 from Andrew Macleod ---
I think that change will end up missing equivalences and transitives. The
m_relation_set bitmap is only used to track non-equivalence relations
registered with the oracle. Equivalences are handled separate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108696
--- Comment #2 from Andrew Macleod ---
Created attachment 54437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54437&action=edit
possible patch
This patch should successfully short circuit unnecessary checks. untested in
compiler.i
Where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #5 from Andrew Macleod ---
My cross compiler doesn't seem to exhibit this behaviour. It simply compiles
this as a quite short program.
It looks like it in the DOM pass.. could you try it with:
-fdump-tree-all-detail --param=ranger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #5 from Andrew Macleod ---
Whats even odder... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
Thats a s390 bug that is spending forever in one of the DOM passes as well...
and I cannot seem to reproduce it either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #7 from Andrew Macleod ---
(In reply to Stefan Schulze Frielinghaus from comment #6)
> Just to be sure: in the initial commit I missed adding -march=z13 and only
> mentioned it in commit 2
>
> I will come up with those logs and mail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #9 from Andrew Macleod ---
Created attachment 54445
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54445&action=edit
proposed patch
I finally reproduced it, the following patch is in testing.
In the referenced commit, I chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
--- Comment #6 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #5)
> (In reply to Richard Biener from comment #3)
> > But yes, your observation about m_has_cache_entry is correct - if that has
> > any value (it makes reset_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108696
--- Comment #5 from Andrew Macleod ---
(In reply to Richard Biener from comment #4)
>
> That said, not allocating the self-relation bitmaps at query time is
> definitely good (not 100% sure if the patch achieves that).
If it can determine ah
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108520
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #8 from Andrew Macleod ---
This fix I just checked in for 108687 exhibited similar performance
characteristics, also in the same pass.. Perhaps it will fix your problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107972
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> The backwards propagation fixed, but neither:
<...>
> avoids the 4.2e+1 cases in the output, because in neither case we properly
> determine the ranges of res (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #8 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> it's odd that VRP doesn't optimize this though. VRP2 says
>
> Exported global range table:
>
> i_6 : int ~[4, 4]
> bool foo (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #10 from Andrew Macleod ---
I was thinking less about phis and more that its a "return" instead of an "if"
ending the block preventing the threader from doing anything.
_3 = i_6 != 0;
return _3;
Ie, so if a return uses a condit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #4 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #3)
> This isn't the threader but VRP/ranger.
>
> What happens is that the threader isolates the path, making it easier for
> VRP to see the equivalence, and then C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #5 from Andrew Macleod ---
We do have the option of not trying to determine anything about _1 in
situations like this..
I tried removing the op1_range() routine for addr_expr, and we pass all tests
just fine.
we would pick up non-nu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104746
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #6 from Andrew Macleod ---
Created attachment 52564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52564&action=edit
possible patch
Perhaps better would be to not try to propagate NULL-ness.
_1 = this_10(D)->d;
_2 = &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #41 from Andrew Macleod ---
>
> so it's still by far jump-threading/VRP dominating compile-times (I wonder
> if we should separate "old" and "new" [E]VRP timevars). Given that VRP
> shows up as well it's more likely the underlying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #42 from Andrew Macleod ---
(In reply to Richard Biener from comment #37)
> I'm looking at range_def_chain::m_def_chain, it's use is well obfuscated by
> inheritance but comments suggest that we have one such structure either for
> e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #45 from Andrew Macleod ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Macleod from comment #42)
> > (In reply to Richard Biener from comment #37)
> > > I'm looking at range_def_chain::m_def_chain, it's use i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #46 from Andrew Macleod ---
(In reply to Richard Biener from comment #44)
> (In reply to Richard Biener from comment #43)
> > (In reply to Andrew Macleod from comment #42)
> > > (In reply to Richard Biener from comment #37)
> > > > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104746
Andrew Macleod changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #47 from Andrew Macleod ---
Created attachment 52637
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52637&action=edit
new patch
I am working on a alternative cache for GCC 13, but along the way, I have
changes to the ranger_ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #49 from Andrew Macleod ---
Let me clean it up a little and I'll post it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
--- Comment #1 from Andrew Macleod ---
This is all very strange. So its a runtime error on those targets?
The code we produce is slightly different, it happens to expose certain
limitations with picking up ranges via dominators when there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
--- Comment #3 from Andrew Macleod ---
FWIW, if I remove the ifcombine pass, then I get the identical IL on x86_64 in
the .optimized pass, and it executes as expected...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #9 from Andrew Macleod ---
Seems like it may expose a problem in gcc.target/i386/sse2-v1ti-shift-3.c as
well:
for (i=0; i<128; i++) {
<...>
if ((ti)rotr_v1ti(ut,i) != (ti)rotr_ti(x,i))
__builtin_abort();
if ((ti)rotl_v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #5 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> This is peeling leaving us with unreachable code we warn on and somehow
> while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on
> the path to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #7 from Andrew Macleod ---
and I forgot to show to dom3 output which did the transformation:
j.c.195t.dom3:Match-and-simplified (sizetype) nb_66 to 18446744073709551615
j.c.195t.dom3:Optimizing statement _2 = (sizetype) nb_66;
j.c.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105086
--- Comment #2 from Andrew Macleod ---
Ranger VRP doesn't simulate edges the same way VRP does. It looks like VRP
simulates the back edge twice and the second time notes that the MAX value is
greater than it was before and "projects" the max to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105086
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> (In reply to Andrew Macleod from comment #2)
>
> > I have an alternate question. it looks like when we utilize scev to pick up
> > ranges we just give up if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105086
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> Even wrapping multiple times as long as it wraps finite number of times
> should be possible to handle, no?
> for (unsigned int i = ~0U; i != 2; i -= 7)
> ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #13 from Andrew Macleod ---
huh, so even after fixing the testcase, ranger is still tripping over this test
case.
uv1ti ashl_v1ti (uv1ti x, unsigned int i)
{
uv1ti _3;
:
_3 = x_1(D) << i_2(D);
return _3;
we have an ssa_na
101 - 200 of 678 matches
Mail list logo
