https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
--- Comment #3 from Aldy Hernandez ---
Probably needs GTY markers, and possibly putting it invalid_range in file
scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
--- Comment #2 from Aldy Hernandez ---
Going up the backtrace we see:
(gdb)
#3 0x01b43aff in irange::intersect (this=0x7fffc8e0,
other=0x3c7aa40 )
at /home/aldyh/src/gcc/gcc/value-range.cc:1514
(gdb)
#4 0x01b3e1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
Attachment #51534|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102561
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
--- Comment #1 from Aldy Hernandez ---
Created attachment 51534
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51534&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
--- Comment #5 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #4)
> On Thu, 30 Sep 2021, aldyh at gcc dot gnu.org wrote:
Thanks for the loop explanation. It's quite helpful.
> So the threading at hand rotates the loop (which is only so-so OK),
> that might be problema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
--- Comment #6 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> I think it's similar to in the other PR, with old EVRP when visiting BB 8
BTW, which is this other PR, so I may see if my work for this PR fixes that
one?
|UNCONFIRMED |NEW
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #5 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> (In reply to Aldy Hernandez from comment #2)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
--- Comment #3 from Aldy Hernandez ---
> What I fail to see is how "a" got removed entirely from the IL, making this
> scenario possible:
>
> if (!(a >= d || f))
> foo();
What I meant to say is that I don't understand how "a" got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
--- Comment #3 from Aldy Hernandez ---
To elide the foo(), _2 must be non-zero on the 2->3 edge dominating the call.
Interestingly, a.0_1 is non-zero on the 2->3 edge, and we have:
_2 = (unsigned int) a.0_1
but somehow we have no knowledge of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #23 from Aldy Hernandez ---
I have built a cross to ppcle on gcc135 (ppc64le) and then bisected the lowest
amount of memory ./cc1 -O2 can compile rlwimi-1.c (via ulimit -v).
Before the VRP threader replacement it could run with 271m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #12 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #11)
> This looks mighty suspicious ;-)
>
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index 69a3ab0ea9d..c24c67f8874 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102501
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #13 from Aldy Hernandez ---
Created attachment 51520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51520&action=edit
avoid CFG and SSA updates when possible
The VRP threader is updating SSAs and CFG even if nothing changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #6 from Aldy Hernandez ---
The attached patch adds a separate TV_* timer to see the actual break down for
VRP and the VRP threader.
Could you incorporate this patch and run the problematic file with ./cc1
-ftime-report -O2? I'd lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #10 from Aldy Hernandez ---
The attached patch adds a separate TV_* timer to see the actual break down for
VRP and the VRP threader.
Could you incorporate this patch and run the problematic file with ./cc1
-ftime-report -O2? I'd li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #9 from Aldy Hernandez ---
Created attachment 51519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51519&action=edit
patch to help diagnose issue with -ftime-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #5 from Aldy Hernandez ---
Created attachment 51518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51518&action=edit
patch to help diagnose issue with -ftime-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #4 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > --- Comment #2 from Aldy Hernandez ---
> > (In reply to David Edelsohn from comment #1)
> >> Confirmed.
> >
> > I don't have access to an i38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #8 from Aldy Hernandez ---
(In reply to David Edelsohn from comment #7)
> Have you tried a native PPC64LE Linux build?
>
> AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to
> affect the memory usage, but I'm men
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #2 from Aldy Hernandez ---
(In reply to David Edelsohn from comment #1)
> Confirmed.
I don't have access to an i386-solaris box.
David, how were you able to reproduce?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Aldy Hernandez from comment #4)
> > Is there any way of reproducing this on a cross? I've been waiting 15
> > minutes for a "git fetch" on gcc111.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #4 from Aldy Hernandez ---
Is there any way of reproducing this on a cross? I've been waiting 15 minutes
for a "git fetch" on gcc111.fsffrance.org or gcc119.fsffrance.org. I'll
continue trying in the background just in case.
FWIW,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102501
--- Comment #2 from Aldy Hernandez ---
Does this fix the problem on your end?
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580411.html
||2021-09-28
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Aldy Hernandez ---
Confirmed. Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102511
--- Comment #10 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Aldy Hernandez from comment #6)
> > Describing the process to get here makes it abundantly clear that we need to
> > improve the process of debugg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102511
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #6 from Aldy Hernandez ---
[Bumping this up to a P1.]
The problem here is that we're incorrectly threading a path in the vrp-thread2
pass. As there is only one registered thread in the dump file
(-fdump-tree-vrp-thread2-details),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463
--- Comment #3 from Aldy Hernandez ---
Could you provide a preprocessed source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100984
--- Comment #2 from Aldy Hernandez ---
Fixed in trunk. Is this still an issue on a branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101938
--- Comment #8 from Aldy Hernandez ---
(In reply to Martin Liška from comment #7)
> > Thank you for reporting and distilling this Martin.
>
> You're welcome, it was pretty fun isolating that!
> Thanks for the hot fix.
That was all Andrew! I j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101938
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101938
--- Comment #4 from Aldy Hernandez ---
This is actually an oversight in the range-ops code. In flag_wrapv
-TYPE_MIN_VALUE = TYPE_MIN_VALUE which is special cased in the ABS folding
routine, but not in operator_abs::op1_range().
Thank you for r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101938
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=101763
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101763
--- Comment #3 from Aldy Hernandez ---
evrp is on the chopping block for this release, and if everything goes
according to plan, so will VRP.
If VRP survives this release, we can go back and fix things like this.
However, if you feel inclined,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746
--- Comment #3 from Aldy Hernandez ---
(In reply to Christophe Lyon from comment #1)
> In addition on arm:
>
>
> FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 (test for excess
> errors)
> Excess errors:
> /gcc/testsuite/g++.dg/warn/Ws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101690
--- Comment #1 from Aldy Hernandez ---
See discussion upstream on this subject:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576390.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101724
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101724
--- Comment #1 from Aldy Hernandez ---
--param threader-iterative is an internal testing construct and not meant for
public consumption. I will submit a patch removing it to avoid further
confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101688
Aldy Hernandez changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101694
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com
Target Milestone: ---
gcc.dg/shrink-wrap-loop.c is failing after the jump threader rewrite. The
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Created attachment 51223
--> https://gcc.gnu.org/bugzilla/attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
--- Comment #2 from Aldy Hernandez ---
(In reply to Martin Sebor from comment #1)
> I can confirm the test fails (despite the xfail):
>
> FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line
> 25)
>
> The xfail target sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81596
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101667
--- Comment #3 from Aldy Hernandez ---
Works on 11.2.1 as well:
tor:~/tmp/tree-vrp-test$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/notnfs/aldyh/bld/threader/ada/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.2.1/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101667
--- Comment #2 from Aldy Hernandez ---
I was able to reproduce on my Fedora 11.1.1 system compiler, but it seems to
work on trunk:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/notnfs/aldyh/bld/threader/ada/install/bin
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
By *.033t.forwprop1, we have the following:
:
# p_9 = PHI
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
The ranger-based jump threader (commit
2e96b5f14e4025691b57d2301d71aa6092ed44bc) shuffles things around in such a way
as to confuse the
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
This is tree-ssa/ranger-threader-5.c which is now failing after the rewrite of
the backwards threader with a ranger based
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
After my rewrite of the backwards threader with the ranger (commit
2e96b5f14e4025691b57d2301d71aa6092ed44bc), gcc.c-torture/compile/pr83510.c is
failing.
Here&#
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=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=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=101186
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
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=100790
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=100984
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=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
--- 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=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
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=100781
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
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=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=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=100636
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
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=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=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=100578
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
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=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=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=100081
--- Comment #6 from Aldy Hernandez ---
BTW, we're looking as to why there are so many calls to varying_p. Something
seems off.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #5 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> Or
>
> bool
> irange::symbolic_p () const
> {
> return (!varying_p ()
> && !undefined_p ()
> && (!is_gimple_min_invariant (min ())
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296
--- Comment #5 from Aldy Hernandez ---
Created attachment 50420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50420&action=edit
proposed patch
As Jakub has mentioned, this is a problem with signed 1-bit precision.
Legacy anti-ranges has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296
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=97767
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
Status|NEW |RESOLVED
Resolution|---
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
--- 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
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
601 - 700 of 1818 matches
Mail list logo
