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
--- Com
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
Resolution|--- |FIXED
Status|NEW
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=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=97359
--- Comment #4 from Aldy Hernandez ---
Created attachment 49340
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49340&action=edit
untested proposed patch
Untested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97359
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97371
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2020-10-12
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97371
--- Comment #3 from Aldy Hernandez ---
Created attachment 49348
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49348&action=edit
proposed patch
untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97371
Aldy Hernandez changed:
What|Removed |Added
Attachment #49348|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Aldy Hernan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97312
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97371
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97378
--- Comment #2 from Aldy Hernandez ---
(In reply to David Binderman from comment #1)
> I have similar for the following C code:
>
> int a, b, c;
> void d() {
> e : {
> long f;
> long *g = &f;
> if ((a != 0) - (b = 0))
> ;
> else
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97381
--- Comment #4 from Aldy Hernandez ---
(In reply to David Binderman from comment #2)
> Reduced C code is:
>
> int a;
> void b() {
> char c = 27;
> for (; c <= 85; c += 1) {
> a /= 148372120 * c;
> if (a)
> for (;;)
> ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97381
Bug 97381 depends on bug 97378, which changed state.
Bug 97378 Summary: [11 Regression] ICE in tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in useless_type_conversion_p, at
gimple-expr.c:87 since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97378
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97381
--- Comment #5 from Aldy Hernandez ---
Created attachment 49354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49354&action=edit
propsed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97381
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97396
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2020-10-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97396
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97379
--- Comment #2 from Aldy Hernandez ---
There's a read of a freed block while accessing the default_slot in
calc_switch_ranges.
default_slot->intersect (def_range);
It seems the default_slot got swiped from under us, and the valgrind
dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97379
--- Comment #3 from Aldy Hernandez ---
Created attachment 49361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49361&action=edit
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97379
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 97379, which changed state.
Bug 97379 Summary: [11 Regression] Invalid read of size 8 at
outgoing_range::calc_switch_ranges(gswitch*) (gimple-range-edge.cc:140) since
r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97396
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96822
Bug 96822 depends on bug 96818, which changed state.
Bug 96818 Summary: [11 Regression] ICE: in decompose, at wide-int.h:984 at -O
since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96813
Bug 96813 depends on bug 96818, which changed state.
Bug 96818 Summary: [11 Regression] ICE: in decompose, at wide-int.h:984 at -O
since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97467
--- Comment #2 from Aldy Hernandez ---
Ranger can figure out that the RHS operand of a shift is a zero and feeds it to
operator_lshift::op1_range, which then uses it to create a swapped [1,0] range.
Testing the following patch:
diff --git a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97467
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97488
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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
--- Com
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
1 - 100 of 752 matches
Mail list logo
