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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #15 from Andrew Macleod ---
no... we won't process ranges for anything unless it passes supports_type_p ():
(INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)))
oh oh oh.
Never mind. I see. we are generating a range for i_2, and I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #19 from Andrew Macleod ---
We can use the original testcase as the litmus test for basic support if we
compile it with
-O2 -fno-tree-fre -fno-tree-dominator-opts
The unroller will unroll the loop and the VRP2 pass will be present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #20 from Andrew Macleod ---
That is correct.
tree op1_type = TREE_TYPE (gimple_assign_rhs1 (s));
tree op2_type = TREE_TYPE (gimple_assign_rhs2 (s));
tree l = build_int_cst (op2_type, 0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276
--- Comment #3 from Andrew Macleod ---
Created attachment 52848
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52848&action=edit
proposed patch
When I removed the recursion from range_of_stmt, I neglected to incorporate the
existing known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #2 from Andrew Macleod ---
The problem goes away if we use --param=evrp-mode-legacy. Ranger picks up a
few more things and we eliminate a couple of latter comparisons which in turn
affect threading, etc etc. and we present the restr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #3 from Andrew Macleod ---
Just to bookmark where the analysis is since im out for a few days, in the
restrict pass, with ranger tracing on, the code sequence is:
[local count: 14831835]:
__nleft_49 = (const size_type) _48;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #5 from Andrew Macleod ---
Before inlining, the general code see:
if (_27 <= __s_53(D))
goto ; [INV]
else
goto ; [INV]
_34 = _27 - __s_53(D);
__nleft_64 = (const size_type) _34
THe branch now registers the relatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346
--- Comment #11 from Andrew Macleod ---
(In reply to Richard Biener from comment #6)
>
>:
> bufp_2 = &buf;
> if (&buf != bufp_2)
> goto ; [INV]
> else
> goto ; [INV]
>
>:
> __builtin_free (bufp_2);
>
> and for the stm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474
--- Comment #2 from Andrew Macleod ---
(In reply to Richard Biener from comment #1)
> For the failing case we see
>
>:
> if (c_5(D) == s_6(D))
> goto ; [INV]
> else
> goto ; [INV]
>
>:
> if (c_5(D) != 0)
> goto ; [INV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
--- Comment #1 from Andrew Macleod ---
(In reply to Richard Biener from comment #0)
>
> Part of the sub-optimality is probably the equiv chain becoming very long
> (can we simply limit that?) and clearing bits in all the very many
> bitmaps li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379
--- Comment #4 from Andrew Macleod ---
Ranger actually appears to handle both cases the same. VRP1 gets it whilst
ranger does not. I believe this to be because we are match and simplifying
_1 = ~c_5(D);
_2 = _1 & s_4(D);
with c_5 == s_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106556
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
--- Comment #2 from Andrew Macleod ---
I think this is a duplicate of PR106379 . At the VRP2 stage I see:
[local count: 1073741824]:
if (c_6(D) == s_7(D))
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 365072224]:
_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106621
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 106687, which changed state.
Bug 106687 Summary: [13 Regression] Wrong code with -O2 since
r13-438-gcf2141a0c640fc9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107109
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114
--- Comment #1 from Andrew Macleod ---
Looks like something in the change is causing the loop analysis to not be able
to count the iterations.
> Analyzing # of iterations of loop 1
> exit condition [1, + , 1] != 0
> bounds on difference of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114
--- Comment #3 from Andrew Macleod ---
yeah, we just invoke the loop analyzer and pick up what it tells us. From VRP2
point of view, it is just not getting the info supplied from the loop
optimizer.
I see dom3 removes some code and I see
< f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 102540, which changed state.
Bug 102540 Summary: [12/13 Regression] Dead Code Elimination Regression at -O3
since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102872
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273
--- Comment #9 from Andrew Macleod ---
Working on it.
Looks like an 8 bit value somehow got considered as a 32 bit partial
equivalence.
_8 = -_7;
_9 = (int) _8;
h_30 = (char) _9;
<..>
h_30 is an 8 bit slice of _9, yet :
This is ok:
Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
Andrew Macleod changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103821
--- Comment #3 from Andrew Macleod ---
Interesting. This isn't caused by jump threading, just exposed by it.
We end up unrolling this loop, and the pattern of code creates a set of
cascading multiplies for which we can precisely evaluate them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103821
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103617
--- Comment #6 from Andrew Macleod ---
Is this actually a bug? I don't believe wide_int works either? PP doesn't
work with class instances...
(gdb) p lh.lower_bound(0)
$3 = { = {val = {-2147483648, 18992502, 140737232043872,
140737233406440,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99966
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76174
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 76174, which changed state.
Bug 76174 Summary: Missed VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76174
What|Removed |Added
||amacleod at redhat dot com
Status|NEW |RESOLVED
--- Comment #1 from Andrew Macleod ---
I think this request is subsumed by the ranger work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 68561, which changed state.
Bug 68561 Summary: get_integer_range () that handles symbolical ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68561
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99755
--- Comment #3 from Andrew Macleod ---
we now know the PHI is an equivalence when the other argument is UNDEFINED.:
[local count: 268435456]:
x_12 = i_8(D) + 1;
x_12 : int [3, +INF]
Equivalence set : [x_7, x_12]<<--Equi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707
--- Comment #4 from Andrew Macleod ---
The IL generated is:
_1 = x_2(D) >> y_3(D);
_4 = _1 <= x_2(D);
return _4;
All that should be needed is for the right shift operator in range-ops to
implement lhs_op1_relation() to indicate that if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83541
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103551
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42436
--- Comment #3 from Andrew Macleod ---
What needs to be done here? anything?
Looking at VRP1, there is only a single divide left at that point:
countm1.6_54 = _12 / _13;
and VRP1 is setting the global range of _13 to:
_13: unsigned int [2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #10 from Andrew Macleod ---
We currently get everything except the last tidbit.
a_1(D) int * VARYING
:
x_2 = a_1(D) == 0B;
a_3 = a_1(D) + 40;
return x_2;
When we see
a_3 = a_1(D) + 40;
Are we allowed to assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103617
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103221
--- Comment #7 from Andrew Macleod ---
We probably do need to revisit some pass ordering. I hope to do even less
propagation within the VRPs next release, so I would expect running copyprop
afterwards would be worthwhile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #13 from Andrew Macleod ---
Probably. rangers nonnull processing also invokes infer_nonnull_range () on
the statement, so should also be picking it up.
The latter test case is really about recomputation then
x_2 = a_1(D) == 0B;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909
--- Comment #4 from Andrew Macleod ---
This functionality was added with fc4076752067fb400b43adbd629081df658da246
Commentary here
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583216.html
All one needs is an active ranger via the enab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96707, which changed state.
Bug 96707 Summary: Failure to optimize right shift+unsigned compare of two
variables optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 83072, which changed state.
Bug 83072 Summary: Late VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 83073, which changed state.
Bug 83073 Summary: Range for VR_VARYING | [1, 1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 97909, which changed state.
Bug 97909 Summary: expr_not_equal_to (mainly in match.pd) vs. ranger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
--- Comment #8 from Andrew Macleod ---
The issue is transitive relations are being registered in an unbounded way.
SymCount_369 = SymCount_368 + 1;
SymCount_370 = SymCount_369 + 1;
SymCount_371 = SymCount_370 + 1;
_370 > _369, and _369 is > _3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067
--- Comment #4 from Andrew Macleod ---
(In reply to Martin Liška from comment #2)
> Likely dup of PR103721.
I think so too. It looks eerily familiar. Aldy will be back this week and
will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #16 from Andrew Macleod ---
The only thing I can think of is it is *guaranteed* to be out of range, then
assume that is because those other values were handled elsewhere and don't
report it?
L_3 int [5, +INF]
[local count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #5 from Andrew Macleod ---
> How does equivalence handling in the Ranger world work once you traverse the
> backedge of a loop?
There are 2 aspects. Ranger itself registers equivalence sets by basic block,
not by name. All looku
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #20 from Andrew Macleod ---
I think the anaylsis in comment 5 and onward needs to be redone since it was
using rangers debug output to see something wrong, but the pass isn't even
using ranger.. It is using EVRP as we determined in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> It is not, because it emits a false positive on a fairly common code.
> Anyway, if bb3 jumps to bb4, then bb3 should have in the ranger assertion
> that in bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102650
--- Comment #6 from Andrew Macleod ---
(In reply to Richard Biener from comment #4)
> If it is undefined it should be unreachable, not switch to a random static
> branch ;) (defeating uninit diagnostics, of course)
Well, its not unreachable..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #8 from Andrew Macleod ---
No probably about it :-)
As soon as the path crosses a back edge, we can encounter definitions of
SSA_NAMEs that may have had a use in the path already, so this will then be a
new definition. The relati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #22 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #21)
> On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> >
> > ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104125
--- Comment #1 from Andrew Macleod ---
wow, thats a crazy change to get that kind of difference. All we are doing is
invoking the ::fold_stmt () on statements we can't simplify with ranges.
I wonder if something is being simplified too early a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #10 from Andrew Macleod ---
(In reply to Jeffrey A. Law from comment #9)
>
>
>
>1 2 3
>| \ /
>|4
>| / \
>+->5 6
> / \
> 7 8
>
>
> Note how BB4 does not dominate BB5. If we try to thr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #14 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #11)
> [local count: 1063004409]:
> # j_17 = PHI
> # q_18 = PHI
>
>[local count: 1063004409]:
> # j_2 = PHI
> # prephitmp_16 = PHI <_14(4), &a(3)>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
--- Comment #10 from Andrew Macleod ---
(In reply to Richard Biener from comment #9)
> I think the GCC 12 IL would require tracking equivalences on parts of
> registers,
> in this case that _2 is equal to the low part of a.0_1. That is, one wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102650
--- Comment #8 from Andrew Macleod ---
Aldy had some ideas of how to extend the threaders new path evaluation
capabilities to determine if there are any paths between bbX and bbY which meet
specific range conditions like UNDEFINED, or [0, 0] for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #25 from Andrew Macleod ---
OK, lets reset.
I run it now, and ranger is indeed being used, so somewhere along the way the
conversion was finished I guess.
so.
looking at the trace, I see:
446 range_of_expr(_2) at stmt grp_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #30 from Andrew Macleod ---
(In reply to Martin Sebor from comment #29)
> From memory: At use1 the cache is empty so go and find its definition and
> record the offset at that point, with the pointer addition as the context.
> And a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104125
--- Comment #2 from Andrew Macleod ---
Created attachment 52278
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52278&action=edit
patch which undoes the original change
I'm not suggesting we de-apply the original patch, but it cant be dire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #16 from Andrew Macleod ---
Looking back at this, I explained why its pathological, but I realize I wasn't
clear about a couple of things. So for the record :-)
> > [local count: 28382607]:
> > <...>
> > _571 = _61 >= _593;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026
--- Comment #4 from Andrew Macleod ---
> void f4(signed int i,unsigned int j) {
> if (i > 100) return;
> if (j > i) return;
>
> if (j > 100) link_error();
if i is -2 (0xfffe) and j is 0xff (-1)
then link error cant be remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026
--- Comment #5 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #4)
> > void f4(signed int i,unsigned int j) {
> > if (i > 100) return;
> > if (j > i) return;
> >
> > if (j > 100) link_error();
>
> if i is -2 (0xfffe)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288
--- Comment #5 from Andrew Macleod ---
The issue is that the routine to determine non-nullness is being called to
check for range-on-entry of the current block instead of just the dominators.
The trace shows:
24 range_on_entry (value_1_7(D))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288
--- Comment #7 from Andrew Macleod ---
its a bit more tightly intertwined than that unfortunately. I had plans to
replace the current non-null processing with a range_after_stmt side-effect API
which would work in conjunction with dominator wal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #16 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #13)
> So, I think one way is to punt on these small precision types, like:
> --- range-op.cc.jj1 2022-01-13 22:29:15.345831749 +0100
> +++ range-op.cc 2022-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288
--- Comment #9 from Andrew Macleod ---
risk/churn.
> > At least that is what I'M currently trying. would this be OK?
>
> Let's see what you can come up with.
> (which is why I really did like to have the old EVRP since conceptually
> it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
--- Comment #37 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #35)
> I meant something like:
> return Z / X;
> and there evrp does with -O2 -gnatp optimize away the division.
> Though that is likely the X / boolean_range_Y c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
--- Comment #39 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #38)
> (In reply to Andrew Macleod from comment #37)
> > As for ranger, range-ops will return UNDEFINED for the range if x is known
> > to be [0,0]. This can be pro
401 - 500 of 890 matches
Mail list logo
