https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119039
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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 #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 #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=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=120701
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
--- 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][
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amacleod at redhat dot com
Target Milestone: ---
Target: arm-none-eabi
Created attachment 61660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61660&action=edit
Testcase demonstrating the proble
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=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
--- 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=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=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=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=119712
Andrew Macleod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
-
|--- |FIXED
CC||amacleod at redhat dot com
--- Comment #6 from Andrew Macleod ---
fixed.
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|REOPENED
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=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=120048
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 #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 #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=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=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=120003
Andrew Macleod changed:
What|Removed |Added
CC||aldy at quesejoda dot com
--- Comment
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=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=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=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
||2025-03-26
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot
com
CC||amacleod at redhat dot com
--- Comment #1 from Andrew Macleod ---
Created
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=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=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=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||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
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=110199
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 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
-
|RESOLVED
CC||amacleod at redhat dot com
--- Comment #8 from Andrew Macleod ---
I believe this is fixed now.
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=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=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=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=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=117088
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
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=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=117287
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=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=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 #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=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=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 #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 #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 #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=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=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=116588
--- Comment #3 from Andrew Macleod ---
Its happening in tree-ssa-propagate.cc after the simplification:
/* If this is a control statement the propagator left edges
unexecuted on force the condition in a way consistent with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #34 from Andrew Macleod ---
Btw, if we simply remove the call to that function, with -O1
-fenable-tree-thread1 I see:
backwards jump threading : 14.36 ( 3%) 0.39 ( 5%) 14.68 ( 3%)
238M ( 9%)
which is a notable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #29 from Andrew Macleod ---
Huh. Do we calculate *all* paths ahead of time?
I tried running valgrind, which died, but up to that point it showed 77% of the
time spend in the body of
back_jt_path_registry::adjust_paths_after_duplica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #27 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #26)
>
> With -O1 -fenable-tree-thread1 (no threadfull):
> dominator optimization : 127.76 ( 7%) 0.57 ( 7%) 128.58 (
> 7%) 236M ( 9%)
> back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116003
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #20 from Andrew Macleod ---
I did an -O2 run after those patches.
Highlights:
tree SSA incremental : 117.74 ( 1%) 0.63 ( 3%) 120.37 ( 1%)
1049M ( 24%)
dominator optimization : 680.49 ( 5%) 0.65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #19 from Andrew Macleod ---
(In reply to GCC Commits from comment #17)
> The master branch has been updated by Andrew Macleod :
>
> https://gcc.gnu.org/g:9e4da946c4263a4c89d5fc365b3c97ae244c5018
>
> commit r15-2858-g9e4da946c4263a4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #23 from Andrew Macleod ---
(In reply to Richard Biener from comment #20)
> collected sofar. I've noticed with the backwards threader that path
> ranger isn't very good in the ability to preserve a cache when adding
> blocks. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #7 from Andrew Macleod ---
I think fixing 114855 will probably resolve this one too. Its a more
"managable" test case. I'm trying to have a look, but I am off next week so
it isn't imminent.
Meanwhile the "workaround" might be to
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=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=115241
--- Comment #2 from Andrew Macleod ---
(In reply to sadineniharish8446 from comment #0)
> The scripts in contrib/header-tools/ are breaks with python3.
> These scripts were for python2 and we did update it for python3 and sent the
> patches to g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #6 from Andrew Macleod ---
Created attachment 58287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58287&action=edit
proposed patch
I'm testing this patch, does it resolve your problem?
I forgot to free the gori_nmap object w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #21 from Andrew Macleod ---
(In reply to Martin Jambor from comment #20)
> (I also cannot prevent myself from ranting a little that it would
> really help if all the ranger (helper) classes and functions were
> better documented.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #8 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #7)
> LOoks like the primary culprits now are:
>
> dominator optimization : 666.73 ( 7%) 0.77 ( 2%) 671.76 (
> 7%) 170M ( 4%)
> backwards jump t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #14 from Andrew Macleod ---
Created attachment 58134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58134&action=edit
adjusted patch
(In reply to Richard Biener from comment #13)
> Andrew - this doesn't pick to gcc-13 because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #7 from Andrew Macleod ---
LOoks like the primary culprits now are:
dominator optimization : 666.73 ( 7%) 0.77 ( 2%) 671.76 ( 7%)
170M ( 4%)
backwards jump threading :7848.77 ( 85%) 21.04 ( 65%)7920.05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> I really don't know how GORI etc. works.
> But, if when the switch handling determines that _1 (the switch controlling
> expression) has [irange] [111, 111] M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #8 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Aldy Hernandez from comment #6)
> > You may want to look at:
> >
> > // Return the bitmask inherent in the range.
> >
> > irange_bitmask
> > iran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> Actually, looking at value-range.h, irange_bitmask doesn't have just the
> mask but also value, so I wonder why it isn't able to figure this out.
> I'd think m_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #3 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #2)
> I thought we don't, if the testcase starts with
> void dummy (void);
> short int foo (void);
> int src(void) {
> short int num = foo ();
> switch(num){
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #23 from Andrew Macleod ---
Created attachment 57686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57686&action=edit
another patch
(In reply to Richard Biener from comment #22)
> (In reply to Andrew Macleod from comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #21 from Andrew Macleod ---
(In reply to Richard Biener from comment #19)
>
> While ranger has a range_on_exit API this doesn't work on GENERIC expressions
> as far as I can see but only SSA names but I guess that could be "fixed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #15 from Andrew Macleod ---
(In reply to Richard Biener from comment #13)
> (In reply to Jeffrey A. Law from comment #12)
> > So I think we could solve this with a bit of help from the alias oracle. We
> > have the routine ptrs_comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #15 from Andrew Macleod ---
(In reply to Richard Biener from comment #14)
> (In reply to Andrew Macleod from comment #13)
> >
> > We would have tripped over this earlier if SCEV or one of those other places
> > using range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #13 from Andrew Macleod ---
Created attachment 57638
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57638&action=edit
patch
Ok, there were 2 issues with simply invoking range_of_stmt, which this new
patch resolves. IF we aren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> Just looking at the generated code of #c0 with -O2 on x86_64, this regressed
> with
> r13-3596-ge7310e24b1c0ca67b1bb507c1330b2bf39e59e32
> Andrew, are you going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #12 from Andrew Macleod ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Andrew Macleod from comment #9)
> > > Created attachment 57620 [details]
> > > proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #9 from Andrew Macleod ---
Created attachment 57620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57620&action=edit
proposed patch
Does this solve your problem if there is an active ranger? it bootstraps with
no regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113632
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #7 from Andrew Macleod ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > (In reply to rguent...@suse.de from comment #4)
> >
> > >
> > > What was definitely missing is consideration
1 - 100 of 891 matches
Mail list logo
