https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
--- Comment #1 from Aldy Hernandez ---
We are calculating ranges for the following:
(gdb) dd stmt
_18 = .UBSAN_CHECK_SUB (_58, _57);
which gets turned into a MINUS_EXPR. Then we call
extract_range_from_binary_expr on the MINUS_EXPR:
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
--- Comment #2 from Aldy Hernandez ---
Created attachment 49411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49411&action=edit
proposed patch
We should disable the assert while this PR is fixed, so it doesn't hold anyone
else up.
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
--- Comment #4 from Aldy Hernandez ---
Looking at vr_values::extract_range_builtin(), I see that every single place
where we use ask for a range, we bail on non-integers (symbolics, etc). That
is, with the exception of the UBSAN builtins.
The U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97538
--- Comment #3 from Aldy Hernandez ---
Created attachment 49434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49434&action=edit
proposed patch in testing
Ranger was returning undefined, which caused get_size_range() to use an
uninitialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97538
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97560
--- Comment #2 from Aldy Hernandez ---
$ ./cc1plus a.c -O2 -fno-tree-forwprop -fnon-call-exc
eptions -quiet
$
Is this still an issue? I can't reproduce on trunk, and I see the PR was
reported against a snapshot from 18-oct. A lot has changed i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97555
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97555
--- Comment #4 from Aldy Hernandez ---
The problem here is we're trying to add 1 to a -1 in a signed 1-bit field.
Signed 1-bits are annoying because you can't really add or subtract one,
because the one is unrepresentable. For invert() we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97555
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97560
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
--- Comment #2 from Aldy Hernandez ---
tl;dr: substitute_and_fold_engine::replace_uses_in() creates invalid gimple, so
when its loop goes on to request a range (value_of_expr), the ranger may see
invalid IL and die an ungraceful death.
The long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
--- Comment #3 from Aldy Hernandez ---
And the reason this was working before is two-fold.
First, value_of_expr() in legacy evrp won't look at broken gimple, so the
request for __keep_12(D) in the following statement actually succeeds:
__to_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #6 from Aldy Hernandez ---
(In reply to Richard Biener from comment #5)
> (In reply to Aldy Hernandez from comment #2)
> Yes, the IL is "correct", just inefficent and possibly confusing to passes.
>
> The OVF flag on INTEGER_CST hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #8 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> when folding some expression. It just doesn't belong into the GIMPLE IL.
> So I'd say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97767
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #2 from Aldy Hernandez ---
evrp and ranger disagree on the singleton range for _3 in the following stmt:
:
if (_3 != 1)
(gdb) ptg evrp_ret
0
(gdb) ptg ranger_ret
1
Which is interesting because BB5 is actually unreachable:
add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #3 from Aldy Hernandez ---
(In reply to Alex Coplan from comment #1)
> Seeing a similar ICE with the following simple C testcase:
>
> int a;
> int b(signed char c, int d) { return c < 0 ? 0 : c >> d; }
> void e(void)
> {
> for (int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
--- Comment #2 from Aldy Hernandez ---
operator_cast::op1_range() is creating a range with swapped operands here:
// And union this with the entire outer types negative range.
int_range_max neg (type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97312
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2020-10-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97337
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97337
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100349
--- Comment #2 from Aldy Hernandez ---
evolution_part_in_loop_num() is returning NULL when evrp asks about the PHI
result here:
(gdb) p debug(stmt)
c.1_4 = PHI
Is this expected?
If it is, we could easily return false if step is null and ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512
--- Comment #4 from Aldy Hernandez ---
After the mentioned commit, e_27(D) is considered undefined, and since
_3 is [0,0], e_26 folds to [0,0] and the PHI is marked for removal:
# e_26 = PHI
However, when propagating to the uses of e_26 (repl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100521
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100578
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512
--- Comment #5 from Aldy Hernandez ---
*** Bug 100578 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100349
--- Comment #4 from Aldy Hernandez ---
Yes, it's a duplicate. There's a patch awaiting review here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570301.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #2 from Aldy Hernandez ---
I cannot reproduce on a cross configured with:
~/src/gcc/configure --target=x86_64-w64-mingw32 --enable-languages=c
--disable-bootstrap
I tried:
./cc1 sha1.i -quiet -mtune=generic -march=x86-64 -g -O2 -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100636
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512
Aldy Hernandez changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #23 from Aldy Hernandez ---
I have an upcoming patchset that implements a range evaluator for tree
expressions (similar to determine_value_range), as well as a gimple_ranger that
evaluates expressions in a higher precision. This com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #24 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #23)
> The above yields overflow for the 16-bit expression in question:
>
> (gdb) p debug(top)
> g_2823_lsm.5_6 * 7854 + 57682
>
> (gdb) p may_overflow_p (top)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100790
--- Comment #2 from Aldy Hernandez ---
There's a patch pending review that fixes this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570289.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787
--- Comment #9 from Aldy Hernandez ---
This temporary fix resolves the bootstrap comparison on i686. Does it also fix
it on sparc-32?
diff --git a/gcc/gimple-ssa-evrp.c b/gcc/gimple-ssa-evrp.c
index 118d10365a0..b40649b6a10 100644
--- a/gcc/gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787
--- Comment #11 from Aldy Hernandez ---
Note, this is still broken so I am leaving the PR open. I will address this
next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100984
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100790
--- Comment #4 from Aldy Hernandez ---
fixed in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100790
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
--- Comment #12 from Aldy Hernandez ---
(In reply to Hongtao.liu from comment #11)
> I'm not sure if it's related but compilation of 527.cam4_r still hangs with
>
> gcc version 12.0.0 20210621 (experimental) (GCC)
Can you verify after which p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
--- Comment #5 from Aldy Hernandez ---
Sorry for the slightly different IL. I had altered g() to avoid depending on
stdio.h:
void g (int a, int b, int x, int y)
{
int c = y;
if (a != 0)
c = x;
while (b < 1000)
// without this loop,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
--- Comment #4 from Aldy Hernandez ---
d is used before being defined. Isn't this entire test bogus?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #5)
> d is not an automatic variable, so is zero initialized.
Whoops. Sorry for the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #12 from Aldy Hernandez ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #0)
> > ... but then
> > comes dom2 and happily replaces
> > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341
--- Comment #2 from Aldy Hernandez ---
(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) value_4(D);
_2 = __builtin_ctz (value.0_1);
r = _2;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281
--- Comment #3 from Aldy Hernandez ---
(In reply to Richard Biener from comment #2)
> GCC 13 got float range tracking but the description isn't clear as what
> transform you are looking after? It seems you are looking for ranges
> of standard m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281
--- Comment #5 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Aldy Hernandez from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > GCC 13 got float range tracking but the description isn't cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341
Aldy Hernandez changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #6 from Aldy H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #15 from Aldy Hernandez ---
(In reply to Richard Biener from comment #13)
> Note that the constant folding routines generally refrain from folding
> when that loses exceptions, it's just ranger when producing singleton
> ranges and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #16 from Aldy Hernandez ---
Created attachment 54224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54224&action=edit
untested patch
Perhaps this would work. It solves the testcase, though I think we should
probably audit the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #22 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Aldy Hernandez from comment #16)
> > Created attachment 54224 [details]
> > untested patch
> >
> > Perhaps this would work. It solves the testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #24 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #21)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Aldy Hernandez changed:
What|Removed |Added
Attachment #54224|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #29 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #27)
> "elide an overflow" should be probably "elide an overflow or division by
> zero" I think,
> because finite / 0.0 returns infinity and raises FE_DIVBYZERO rath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Aldy Hernandez changed:
What|Removed |Added
Attachment #54253|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #36 from Aldy Hernandez ---
Can we close this PR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #8 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> This one started with r13-1933-g24012539ae3410174.
> I think the problem is in:
>
> Folding statement: _3 = cmp1_10 & cmp2_11;
> Not folded
> Folding statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #9 from Aldy Hernandez ---
(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 #11 from Aldy Hernandez ---
Hmmm, I wonder if we could do this all in validate_relation like Andrew had
planned.
If NAN is a possibility in either x or y, then we could disallow any relation
recording right off the bat, and avoid an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #14 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #13)
> On Thu, 19 Jan 2023, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
> >
> > --- Comment #12 from Jakub Jeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108540
--- Comment #7 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 54351 [details]
> gcc13-pr108540.patch
>
> Untested fix.
LGTM. Thanks for looking at this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #6 from Aldy Hernandez ---
Created attachment 54393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54393&action=edit
untested patch for irange::operator==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #7 from Aldy Hernandez ---
Jakub, take a look and see if you agree. I've fired off some tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #12 from Aldy Hernandez ---
Yeah, I've been mulling around the idea of removing the type from storage of
both irange and frange. It seems we need it for setting a type (setting the
endpoints for varying, querying HONOR_NANS, HONOR_I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #5 from Aldy Hernandez ---
> Perhaps just adding if (op2.undefined_p ()) return false; above most of the
> switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2;
> and similarly for op1) for the comparison operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #12 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> So
> --- gcc/range-op.cc.jj2023-02-03 10:51:40.699003658 +0100
> +++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
> @@ -642,7 +642,8 @@ operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #13 from Aldy Hernandez ---
Created attachment 54404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54404&action=edit
frange changes
These are the analogous changes to range-op-float.cc.
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #15 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 54405 [details]
> gcc13-pr108647.patch
>
> Here is what I'm about to test momentarily, though I must say I don't
> understand those operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
--- Comment #1 from Aldy Hernandez ---
Sharing a cache with say the ranger is a no go, because the path_range_query's
cache is specific to the path, but perhaps we could share the path's cache
between constructions providing a constructor that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
--- Comment #4 from Aldy Hernandez ---
Created attachment 54420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54420&action=edit
reuse path_range_query SSA cache for all of back_threader class
Off of the top of my head (i.e. probably very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
--- Comment #5 from Aldy Hernandez ---
(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 "cheap"), then it should be also relied on
> upon
>
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
Running make check -j55 sometimes yields tests that fail to terminate in the
gm2/ directory. For example, coroutine.x5 and testtransfer.x5.
Worst case scenario there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108835
--- Comment #4 from Aldy Hernandez ---
Thank you very much for such a prompt fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #12 from Aldy Hernandez ---
(In reply to Richard Biener from comment #10)
> (In reply to Richard Biener from comment #9)
> > Note I think there's still a bug in value_range (irange) here.
> > get_size_range
> > does
> >
> > if (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #14 from Aldy Hernandez ---
(In reply to Richard Biener from comment #11)
> So I've missed the VR_ANTI_RANGE handling in get_size_range where we run into
>
> wide_int maxsize = wi::to_wide (max_object_size ());
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #27 from Aldy Hernandez ---
(In reply to Richard Biener from comment #21)
> So without messing with real.cc to try exposing 0.5ulp adjustments for GCC
> 13 I'd simply do something like the following:
>
> diff --git a/gcc/range-op-fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #29 from Aldy Hernandez ---
Created attachment 54604
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54604&action=edit
untested patch for NAN state copying
This is what I had in mind.
Notice I haven't touched the fields in fra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #9 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #8)
> (In reply to Richard Biener from comment #3)
> Curious question, if that was an 'if' instead of a return using _3, the
> threader would probably thread the PH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #11 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #10)
> 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_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
--- Comment #2 from Aldy Hernandez ---
BTW, on GCC11, ivopts doesn't even get a whack at it. The whole thing is
optimized away by .fre4:
int main ()
{
long int a;
long int c;
[local count: 44232128]:
if (a_9(D) <= 0)
goto ; [89.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104754
--- Comment #3 from Aldy Hernandez ---
Upon closer inspection, evrp in GCC11 and mainline are generating slightly
different code which keeps FRE from cleaning this up in mainline.
Mainline is transforming the conditional here:
:
# c_3 = PH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #8
1101 - 1200 of 1818 matches
Mail list logo
