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
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=edit
adjusted patch
(In reply to Richard Biener from comment #13)
> Andrew - this doesn't pick to gcc-13 because of the
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 (
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]
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
> >
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
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=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
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=edit
patch
Ok, there were 2 issues with simply invoking range_of_stmt, which this new
patch resolves. IF we aren't
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
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=edit
proposed patch
Does this solve your problem if there is an active ranger? it bootstraps with
no regressions
ITs
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #5 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #4)
>
> What was definitely missing is consideration of POLY_INT_CSTs (and
> variable polys, as I think there's no range info for those).
>
Ranger doesn't do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately doing the ((682 >> x) & 1) to x & 1 optimization in match.pd
> isn't possible, we can only use global ranges there and we need path
> specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #47 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #46)
> (In reply to Jan Hubicka from comment #43)
> > > // See discussion here:
> > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #46 from Andrew Macleod ---
(In reply to Jan Hubicka from comment #43)
> > // See discussion here:
> > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
> Discussion says:
>
> "Once legacy evrp is removed, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113879
--- Comment #2 from Andrew Macleod ---
Not so much a cycle issue as a backward propagation issue.
:
goto ; [INV]
:
_1 = (long unsigned int) j_10;
<..>
if (j_10 >= -1)
goto ; [INV]
else
goto ; [INV]
:
__builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> To be precise, expand_expr_divmod uses get_range_pos_neg for that during
> expansion (unless we'd e.g. somehow noted it in some very late pass before
>
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=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
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=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=110205
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=110251
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
--- Comment #11 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Anonymous from comment #9)
> > (In reply to Andrew Pinski from comment #1)
> > > dom3 :
> > > ```
> >
> > Could you please explain on how you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
--- Comment #6 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Even then, I wonder why ranger doesn't figure this out.
> > (x+1u) <= 2 ? x : 0
> > must have a range [-1, 1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #3 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #2)
> I Kinda see how to implement this by creating
> operator_min::fold_range/operator_max::fold_range but I am still new on
> using these interfaces so I am not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112843
--- Comment #9 from Andrew Macleod ---
Created attachment 56790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56790=edit
auxially patch to avid the trap
refining a range is fine... the only issue we are really running into here
that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112843
--- Comment #7 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > what do you mean? when a statement is changed, it may generate a different
> > range than it did before,
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112843
--- Comment #5 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > what?! Ick. It definitely shouldn't re-fold anything but only scrap caches
> > _at most_.
>
> So it does
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
--- Comment #2 from Andrew Macleod ---
(In reply to Kewen Lin from comment #1)
>
> ranger makes use of type precision directly instead of something like
> types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #13 from Andrew Macleod ---
Created attachment 56735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56735=edit
patch
(In reply to Sam James from comment #12)
> Is the plan to backport to 11/12/13 or to leave it?
hmm. I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #2 from Andrew Macleod ---
It seems like we set 'e' to 3 immediately at the start:
[local count: 1073741824]:
e = 3;
goto ; [100.00%]
and it is never changed again. However, when we load from 'e' later in the IL
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
>
> I think
> Value_Range vr (operand_type);
> if (TREE_CODE_CLASS (operation) == tcc_unary)
> ipa_vr_operation_and_type_effects (vr,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Well, in this case the user explicitly told compiler not to do that by not
> using a prototype and syntax which doesn't provide one from the definition.
> It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #7 from Andrew Macleod ---
Explicit casts would be no problem as they go through the proper machinery. The
IL for that case has an explicit cast in it.
_1 = (int) x_2(D);
foo (_1);
its when that cast is not present,and we try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112509
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112509
--- Comment #2 from Andrew Macleod ---
the original switch is an unsigned value with precision of 3 bits, so 0..7 just
fits.
It gets translated to an int index during gimplification, but the case labels
are still precision 3 values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511
--- Comment #8 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> VRP could use max_stmt_executions here (note it doesn't properly handle loop
> nests so the name is somewhat misleading)
Do you have to ask for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540
--- Comment #3 from Andrew Macleod ---
EVRP figures out the j value can only be 0 or -9 and removes a few stmts as a
result, and simplifies the PHI, producing
[local count: 114863530]:
# j_12 = PHI <0(2), -9(6)>
[local count:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511
--- Comment #7 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> VRP could use max_stmt_executions here (note it doesn't properly handle loop
> nests so the name is somewhat misleading)
Given some arbitrary statement S,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472
--- Comment #4 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #3)
> I'm not sure that this didn't uncover something elsewhere, possibly ivopts
> since that pass seems to be generating something different and I think there
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472
--- Comment #3 from Andrew Macleod ---
I'm not sure that this didn't uncover something elsewhere, possibly ivopts
since that pass seems to be generating something different and I think there
were some fixes put in there on trunk?.
Regardless,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
--- Comment #3 from Andrew Macleod ---
fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111622
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111622
--- Comment #6 from Andrew Macleod ---
Interesting.
The "fix" turns out to be:
commit 9ea74d235c7e7816b996a17c61288f02ef767985
Author: Richard Biener
Date: Thu Sep 14 09:31:23 2023 +0200
tree-optimization/111294 - better DCE after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Andrew Macleod changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
--- Comment #1 from Andrew Macleod ---
Imports: bb_3(D)
Exports: _2 bb_3(D)
_2 : bb_3(D)(I)
bb_3(D) [irange] int [0, 3] MASK 0x3 VALUE 0x0
:
_2 = bb_3(D) & 1;
if (_2 == 0)
goto ; [INV]
else
goto ; [INV]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #9 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #8)
> (In reply to Alexander Monakov from comment #7)
> > No backport for gcc-13 planned?
>
> mmm, didn't realize were we propagating floating point equivalences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Andrew Macleod changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> Looks like some frange / relation mistake then.
l_3(D) [frange] double [-Inf, +Inf]
Equivalence set : [l_3(D), r_4(D)]
:
_1 = __builtin_signbit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111622
--- Comment #3 from Andrew Macleod ---
(In reply to Richard Biener from comment #1)
> Created attachment 56006 [details]
> preprocessed riscv insn-opinit.cc
I get
i.ii:2203:11: fatal error: definition of ‘class std::initializer_list<_E>’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111599
--- Comment #3 from Andrew Macleod ---
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
--- Comment #11 from Andrew Macleod ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Macleod from comment #7)
> > Created attachment 55591 [details]
> > potental patch
> >
> > I've attached Aldy's patch for PR109695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93917
--- Comment #4 from Andrew Macleod ---
Note a slight change in expectation as a result of commit
r14-4141-gbf6b107e2a342319b3787ec960fc8014ef3aff91 for PR 110080
Due to a memory load in the second case, we do not remove the unreachable call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110080
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110875
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110918
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #10 from Andrew Macleod ---
> At the hazard of stating the obvious: it's a wrong-code when you execute it
> (not a gcc ICE).
>
doh. of course.
test is in progress. Richi was correct. Although the code in range-ops for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #8 from Andrew Macleod ---
Do I need some special target or something? on trunk just
"-fno-strict-overflow -O3" doesnt fail for me on x86_64-pc-linux-gnu...
./cc1 -fno-strict-overflow -O3 009.c -quiet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942
--- Comment #3 from Andrew Macleod ---
The original revision listed, I narrowed down to a single instance where the
new code did something that makes a difference
we determine that in stmt
stmt _8 = (int) i_10;
which originally had a range of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942
--- Comment #1 from Andrew Macleod ---
Created attachment 55743
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55743=edit
patch to revert the change
Although the bisection stopped at this change, it does not appear to be the
underlying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> bool
> operator_addr_expr::fold_range (irange , tree type,
> const irange ,
> const irange ,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
--- Comment #6 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > So I have a VRP patch which gets us to:
>
> /* If the value range is defined by more than one pair,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
--- Comment #7 from Andrew Macleod ---
Created attachment 55591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55591=edit
potental patch
I've attached Aldy's patch for PR109695 which he had backported to GCC13 back
in May.
This does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
--- Comment #6 from Andrew Macleod ---
I think the difference is actually Aldys work to reduce the size of Value_Range
rather than other stack saving changes. I think I can make some adjustments so
that our usage of Value_Range are on leaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
--- Comment #5 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #4)
> (In reply to Richard Biener from comment #2)
> > Confirmed. Not sure whether it's possible to backport any of the stack
> > usage reduction in ranger from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> Confirmed. Not sure whether it's possible to backport any of the stack
> usage reduction in ranger from trunk or whether it's other recursion
> limiting that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
--- Comment #3 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> Confirmed. Not sure whether it's possible to backport any of the stack
> usage reduction in ranger from trunk or whether it's other recursion
> limiting that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
--- Comment #4 from Andrew Macleod ---
If I were to guess, I'd guess that its using the default query which simply
picks up global ranges from the global_range_query.
If enable_range() was called at the start, and disable_ranger() at the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
--- Comment #7 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #6)
> bah.
>
> Ranger hang is resolved with:
>
> commit 4dfeb1cd8dfca234186216d891ec8f46235c3a14
> Date: Thu Jun 22 10:00:12 2023 -0400
>
> Avoid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
--- Comment #6 from Andrew Macleod ---
bah.
Ranger hang is resolved with:
commit 4dfeb1cd8dfca234186216d891ec8f46235c3a14
Date: Thu Jun 22 10:00:12 2023 -0400
Avoid redundant GORI calcualtions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
--- Comment #5 from Andrew Macleod ---
hmm. yeah. its triggering some kind of pathological edge evaluation between
GORI and cache updating.
There is a long sequence of dependent stmts, presumably the unrolled loop, and
a sequential series of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110266
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110205
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #13 from Andrew Macleod ---
Let me know if the buildbot likes that change :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #11 from Andrew Macleod ---
(In reply to Martin Jambor from comment #9)
> A buildbot run which checked out this revision unfortunately still reports
> this problem with UBSAN-bootstrapped compiler.
Actually, I do not think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #10 from Andrew Macleod ---
(In reply to Martin Jambor from comment #9)
> A buildbot run which checked out this revision unfortunately still reports
> this problem with UBSAN-bootstrapped compiler.
Oh, I see.. there's a second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #8 from Andrew Macleod ---
I just checked in:
commit cd9c7f898d6e6313465f78227e566f27dce5e5a3
Author: Andrew MacLeod
Date: Wed May 31 13:10:31 2023 -0400
Provide a new dispatch mechanism for range-ops.
As a side effect it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
--- Comment #13 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #12)
> Aldy or Andrew, why in conv1 we don't get a range for
> SR.4_4 = sD.8798._M_valueD.7665;
>
> Even though the range we have is [-1,1] according to the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #37 from Andrew Macleod ---
(In reply to CVS Commits from comment #36)
> For the curious, a particular hot spot for IPA in this area was:
>
> ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
> {
> ...
1 - 100 of 596 matches
Mail list logo
