https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2021-10-01
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"
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
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
---
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
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
> +++
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=edit
avoid CFG and SSA updates when possible
The VRP threader is updating SSAs and CFG even if nothing changes. This
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
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
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=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=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
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102501
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102511
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102511
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P1
Assignee|unassigned at
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
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
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
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:
>
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101690
Bug ID: 101690
Summary: failure to shrink wrap simple loop with more
aggressive jump threading
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101688
Bug ID: 101688
Summary: g++.dg/warn/Wstringop-overflow-4.C fails on x86-32
with new jump threader
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101675
Bug ID: 101675
Summary: analyzer/pr94851-2.c marked XFAIL because it fails
with new jump threader
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
Bug ID: 101674
Summary: gcc.dg/uninit-pred-9_b.c fails after jump threading
rewrite
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101673
Bug ID: 101673
Summary: shorter unprofitable jump thread path inhibits
threading of larger path
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
Bug ID: 101671
Summary: pr83510 fails because threader confuses -Warray-bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
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
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
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512
Aldy Hernandez changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100636
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
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
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
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
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=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
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
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|---
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:
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
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=97555
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
---
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
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=97538
--- Comment #3 from Aldy Hernandez ---
Created attachment 49434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49434=edit
proposed patch in testing
Ranger was returning undefined, which caused get_size_range() to use an
uninitialized
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
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=edit
proposed patch
We should disable the assert while this PR is fixed, so it doesn't hold anyone
else up.
Patch needs
601 - 700 of 740 matches
Mail list logo
