https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Andrew Macleod changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110205
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113440
--- Comment #2 from Andrew Macleod ---
(In reply to Richard Biener from comment #1)
> Yeah, looks like
>
> if (a+a < a)
>
> for unsigned doesn't register the appropriate range on the false edge.
_1 = a_5(D) * 2;
if (_1 < a_5(D))
goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113475
--- Comment #4 from Andrew Macleod ---
yoinks. Not sure how I missed that. thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113716
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> Maybe ranger could figure out that at least one of the multiplication
> operands is zero in this case, because the second one is non-zero only if
> the first on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #3 from Andrew Macleod ---
Seems reasonable to me, adding BBS should be fine throughout. just don't
re-order them :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115951
--- Comment #3 from Andrew Macleod ---
I think I have a handle on it.
The issue is statements like
_80 = _79 == 0
where in ADA a a boolean type is 8 bits and GCC's default boolean type is 1
bit.
All through ranger we use the type of the LHS,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116003
--- Comment #1 from Andrew Macleod ---
When registering an equivalence, the oracle creates an initial equivalence for
an SSA_NAME with itself in the def block. This prevents dominator queries
from searching past the definition block.
In this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117222
--- Comment #6 from Andrew Macleod ---
(In reply to Sam James from comment #3)
> (In reply to Sam James from comment #2)
> > [...]
> > I'm very surprised by this as I was under the impression the prange stuff
> > was an initial stub (new class o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117398
--- Comment #3 from Andrew Macleod ---
(In reply to Sam James from comment #2)
> * With just -O1, 11 works and >=12 fails, bisected to
> r12-2591-g2e96b5f14e4025.
> * With -O2 -fno-thread-jumps, 12 works and >=13 fails. Needs bisection I
> guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588
--- Comment #10 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #9)
> Andrew, do you plan to backport this?
Wasn't planning to. Although the fast VRP pass exists in GCC 14, there is no
way to call it or test it. There were also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117222
--- Comment #8 from Andrew Macleod ---
pointer_diff depends on range_operator::fold_range to do the generic fold,
which invokes wi_fold on subranges. It also in turn invokes
op1_op2_relation_effect.
This worked fine when pointers were implemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #2 from Andrew Macleod ---
It seems that until now, we didn't see an empty block feeding a PHI that
mattered:
_3 = x_2(D) + 4294967292;
if (_3 <= 1)
goto ; [41.00%]
else
goto ; [59.00%]
goto ; [100.00%]
_6 = x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #57 from Andrew Macleod ---
FWIW, on my last run, enabling early VRP sped up my -O1 compilation by a fair
amount. total compilation dropped from 480 seconds to 380 seconds...
It took 2.5 seconds to run, and im going to guess might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 59236 [details]
> gcc15-pr116898.patch
>
> So like this? Will test tonight.
perfect. consider it pre-pproved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> Even if create (n) didn't work (which would be good to debug), the
> x.safe_grow_cleared (n); x.truncate (0); can be just done more efficiently
> with x.reserve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #7 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Even if create (n) didn't work (which would be good to debug), the
> > x.safe_grow_cleared (n); x.truncate (0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> Similarly to the other BB, enable_ranger -> gimple_ranger -> ranger_cache
> does
> 1000m_workback.create (0);
> 1001m_workback.safe_grow_cleared (last_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
--- Comment #3 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #2)
> The bitint lowering pass emits some gimple statements on edges
> (gsi_insert_on_edge) and the edge insertions are (intentionally) committed
> to edges only at t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #10 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 59238 [details]
> gcc15-pr116899.patch
>
> Untested fix in patch form.
Also pre-approved.
thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #55 from Andrew Macleod ---
(In reply to Richard Biener from comment #50)
> (In reply to Richard Biener from comment #4)
> > Trunk at -O1:
> >
> > dominator optimization : 495.14 ( 82%) 0.20 ( 5%) 495.44 (
> > 81%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117088
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116753
--- Comment #5 from Andrew Macleod ---
Theres room for some improvement in relations via PHIs that I will document
here so I don't lose it. in VRP1 I see:
Registering value_relation (x_7 > x_4) (bb5) at x_7 = x_4 + 1;
Registering value_relati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117088
--- Comment #7 from Andrew Macleod ---
(In reply to Jan Hubicka from comment #6)
> > void digits_2.isra (integer(kind=4) ISRA.6607)
> > {
> > integer(kind=4) ISRA.6607_927(D) = ISRA.6607;
> > ...
> > # RANGE [irange] integer(kind=4) [-2147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
--- Comment #6 from Andrew Macleod ---
(In reply to Richard Biener from comment #5)
> I tried get_range_query (cfun)->range_of_expr (vr, niter->niter, stmt) with
> (unsigned int) M_9(D) - (unsigned int) k_24 and an enabled ranger
> but that inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
--- Comment #11 from Andrew Macleod ---
(In reply to Richard Biener from comment #8)
> (In reply to Richard Biener from comment #7)
> > I'm talking about the number of iterations of the second loop (after loop
> > splitting), the niter expressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #9 from Andrew Macleod ---
I believe this is fixed by the same patch as I committed for 88575.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 88575, which changed state.
Bug 88575 Summary: gcc got confused by different comparison operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
Bug 88575 depends on bug 110199, which changed state.
Bug 110199 Summary: [12/13 Regression] Missing VRP transformation with MIN_EXPR
and known relation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
--- Comment #10 from Andrew Macleod ---
It also works if I use
--disable-tree-cunroll
which makes me suspicious of cunroll.
It also works if I use
--fdisable-tree-evrp --fdisable-tree-vrp1
So I thought perhaps VRP is doing something to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
--- Comment #9 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #2)
> 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%]
> els
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119439
Bug 119439 depends on bug 117287, which changed state.
Bug 117287 Summary: [13 Regression] assume attribute related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119471
Andrew Macleod changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
--- Comment #6 from Andrew Macleod ---
(In reply to Sam James from comment #5)
> I suppose it's a job for prange?
I don't think so. I think it related to integral values being bumped by 1, and
pointer values being bumped by 4.
It seems the iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #11 from Andrew Macleod ---
Created attachment 60905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60905&action=edit
potential patch
(In reply to Sam James from comment #10)
> The testcase from https://gcc.gnu.org/bugzilla/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #4 from Andrew Macleod ---
The change tweaks an issue that I haven't seen in the cache before.
When it is propagating values in the cache (the only real iteration ranger has)
the values are always suppose to get "better", and in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #8 from Andrew Macleod ---
Final version of the patch is submitted to the mailing list (
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681252.html ) which
removes adjust_range() and moves the same functionality directly into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
--- Comment #8 from Andrew Macleod ---
IKt seems the root problem is that the ipa_vr class doesn't support UNDEFINED
ranges, and in this case it has a range but when the bitmask is explicitly
applied, we recognize that the range is actualyl UNDE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
--- Comment #9 from Andrew Macleod ---
Created attachment 61274
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61274&action=edit
potential patch
(In reply to Andrew Macleod from comment #8)
>
> Another option is to add a type to UNDEFIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
--- Comment #5 from Andrew Macleod ---
It is trapping when asking for the type() of an UNDEFINED range.
Looking up the call chain:
Breakpoint 2, ipcp_store_vr_results () at /gcc/master/gcc/gcc/ipa-cp.cc:6366
6366 tmp.update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
--- Comment #6 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #5)
> 6358value_range tmp = plats->m_value_range.m_vr;
> 6359tree type = ipa_get_type (info, i);
> 6360i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #7 from Andrew Macleod ---
Bah. almost but not quite.
Rangers cache algorithm must remain as it is... it will always produce a better
result.. but we need to calculate everything properly.
Going back to the original analysis:
FWD v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003
Andrew Macleod changed:
What|Removed |Added
CC||aldy at quesejoda dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003
--- Comment #4 from Andrew Macleod ---
This seems to be the issue?
[local count: 350791453]:
_1 = g (i_3);
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 175395727]:
[local count: 1063004408]:
# iftmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118922
--- Comment #12 from Andrew Macleod ---
Hmm. Going into phiopt2, I see:
[local count: 1014686024]:
if (h_6 != 0)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 114863530]:
# h_6 = PHI <0(4), 1(5)>
[local count: 1073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
Bug 119712 depends on bug 120048, which changed state.
Bug 120048 Summary: [14/15/16 Regression] ICE on valid code at -O{s,2} with
"-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at
value-range.h:982 since r16-244-gce489c870bf28e
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #2 from Andrew Macleod ---
We do not have cast operators between int and float. We are also missing some
dispatch code for them as we haven't actually used some of those patterns yet.
I am going to checked in a patch to trunk short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546
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 116546, which changed state.
Bug 116546 Summary: Missed optimization of redundant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116546
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120277
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
Andrew Macleod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 95801, which changed state.
Bug 95801 Summary: Optimiser does not exploit the fact that an integer divisor
cannot be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95801
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119439
Bug 119439 depends on bug 117287, which changed state.
Bug 117287 Summary: [13 Regression] assume attribute related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588
--- Comment #12 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Andrew, do you plan to backport this?
>
> Wasn't planning to. Although the fast VRP pass exists in GCC 14,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120701
--- Comment #3 from Andrew Macleod ---
Definitely something amok. in dom3 I'm seeing:
range_of_expr(_131) at stmt _134 = _131 * -1101344938;
TRUE : (3439) range_of_expr (_131) [irange] int [-1494798553,
-5][-1, -1][3, 652685091][
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120702
Bug ID: 120702
Summary: Extraneous string constant at -Os
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120701
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Andrew Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120701
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120701
--- Comment #6 from Andrew Macleod ---
Not sure why the commit isn't showing up... regardless:
commit b03e0d69b37f6ea7aef220652635031a89f56a11
Author: Andrew MacLeod
Date: Fri Jun 20 08:50:39 2025 -0400
Fix range wrap check and enhance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #8 from Andrew Macleod ---
(In reply to Filip Kastl from comment #6)
> Removing the 'wrong-code' keyword. Talked about -Ofast SPEC miscompares
> with Richi and now I understand that those aren't really miscompilations:
> With -Ofas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120661
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> This is in main, I only see one create_basic_block there during expansion
> (the one added on edge from ENTRY to ENTRY->succ) and no remove_edge, no
> further e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120661
--- Comment #6 from Andrew Macleod ---
>
> Im not sure the best solution immediately... Let me experiment
btw, that is for the second testcase at -Os. The first one is a similar
situation, with a different calculation... but it is again c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120661
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #4 from Andrew Macleod ---
I'm also having difficulty reproducing. The SPEC 2006 I have access to doesn't
seem to want to work with a modern perl.
I also don't have zen4 or zen5, I was going to see if it reproduced on vanilla
x86-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #5 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #4)
> I'm also having difficulty reproducing. The SPEC 2006 I have access to
> doesn't seem to want to work with a modern perl.
>
> I also don't have zen4 or zen5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #2 from Andrew Macleod ---
Does it still fail with the fix for PR 120701?
Although it was a compile time failure, there are potentially casees we could
end up with an incorrect range if circumstances were correct.
Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #21 from Andrew Macleod ---
In reply to Jakub Jelinek from comment #19)
> Note, we call in that function get_range_pos_neg first on _54
> on the _55 = (sizetype) _54; statement (same block 11), that is the first
> ranger query during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119039
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
601 - 678 of 678 matches
Mail list logo
