https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822
--- Comment #2 from Andrew Macleod ---
Sorry, I've been out for a few weeks.
This isn't an on-demand issue. All versions of VRP do a full walk and resolve
during the walk. This issue is a combination of lack of iteration and not
optimistic eval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104547
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105597
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105597
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105663
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105663
--- Comment #4 from Andrew Macleod ---
Or perhaps there shouldnt be
set (BIT_NOT_EXPR, op_bitwise_not);
set (BIT_XOR_EXPR, op_bitwise_xor);
operations on pointer values? I see also support
set (BIT_AND_EXPR, op_pointer_and);
set (BIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105763
--- Comment #6 from Andrew Macleod ---
yeah, from times of yore when the small set of callers made sure it was only
invoked on useful cases. There were a lot of development asserts from initial
development.
There is no reason to trap, it can s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105802
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105802
--- Comment #4 from Andrew Macleod ---
The reason for the precision check is because doing a union or intersection
with ranges of different precisions is problematic, and being sure what the
user expects would be a guess
normally in this sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105820
--- Comment #2 from Andrew Macleod ---
Lets see try to remember
it can be ambiguous. The inversion of undefined is not necessarily expected
to be varying in all circumstances.. Likewise, inverting varying is still
varying in some circum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105820
--- Comment #4 from Andrew Macleod ---
Well, thats not really the problem here. We are casting
[irange] gimple_code [2, 2]
to a gimple_code, and getting:
[irange] gimple_code VARYING
Couple of issues.. one, we shouldnt bother casting anythi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106114
--- Comment #7 from Andrew Macleod ---
The routine which tries to fold relations in && or || statements is getting
stale information.
GORI maintains a dependency cache which is mostly use by the temporal mechanism
to decide when statements are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106114
--- Comment #8 from Andrew Macleod ---
Created attachment 53226
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53226&action=edit
proposed patch
Patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106138
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #1)
> So we're seeing
>
> b1_8 = x_7(D) == 4;
> # RANGE [0, 3] NONZERO 3
> _3 = x_7(D) & 3;
> b2_9 = _3 != 0;
> _5 = b1_8 & b2_9;
>
> and fail to optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106234
--- Comment #1 from Andrew Macleod ---
> it looks like range_from_dom walks up immediate dominators but in that loop
> recurses to itself!? isn't that quadratic? shouldn't the recursion stop
> at the next immediate dominator of the recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106234
--- Comment #2 from Andrew Macleod ---
Created attachment 53281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53281&action=edit
proposed patch
we're having some connection issues, but I am in the process of trying to test
the attached p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106234
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106280
--- Comment #1 from Andrew Macleod ---
Created attachment 53300
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53300&action=edit
proposed patch
See if this helps.
All of the lookup routines check to see first is there is an existing re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
--- Comment #2 from Andrew Macleod ---
Created attachment 51082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51082&action=edit
patch
I *think* this is correct. but wrapv and signed stuff sometimes confuses me
:-)
when -fwrapv is on,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
Andrew Macleod changed:
What|Removed |Added
Attachment #51082|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
--- Comment #8 from Andrew Macleod ---
I just never added them... I guess we could fully flesh out the combinations
and results. Note this is also the only non-relational operand that is even
implemented so far.. Haven't gotten to any of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
Andrew Macleod changed:
What|Removed |Added
Attachment #51083|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> Comment on attachment 51084 [details]
> another patch
>
> Except for some consistency (max is in comments lowercase, but MIN is
> uppercase), it looks good t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335
--- Comment #2 from Andrew Macleod ---
yeah, it because we have been treating casts to objects of the same precision
as equivalences.This normally works fine, but in this case we have
c_9 = (int)_2 c_9 == _2
_3 = c_9 - 10 so _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60669
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697
--- Comment #5 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #4)
> (In reply to Jakub Jelinek from comment #2)
> > Shall we do that as a specific matcher or e.g. in the ranger once it gets
> > code for symbolic comparisons? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 93781, which changed state.
Bug 93781 Summary: Optimizer produces suboptimal code related to -ftree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
Andrew Macleod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100299
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 71690, which changed state.
Bug 71690 Summary: some integer conversions defeat memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110
--- Comment #4 from Andrew Macleod ---
Does this still fail? When i look at a cross compiler listing I do not see any
differences from ranger in the listing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100349
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96542, which changed state.
Bug 96542 Summary: Failure to optimize simple code to a constant when storing
part of the operation in a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101496
Andrew Macleod changed:
What|Removed |Added
Last reconfirmed||2021-07-19
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497
--- Comment #5 from Andrew Macleod ---
uc_1.0_1 = uc_1;
_2 = (int) uc_1.0_1;
_3 = 211 - _2;
_3 evaluates as 211 - [-128, 127], or [84, 339]
_4 = _3 > 0;
_5 = (int) _4;
func_12_uli_6 = _5;
i_4.1_6 = i_4;
_7 = i_4.1_6 % 0;
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101511
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101511
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101496
Andrew Macleod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72443
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
Reso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101741
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755
--- Comment #1 from Andrew Macleod ---
What is that suppose to test?
The range ecosystem has gotten smarter and we basically fold that function away
to return 0 now. between EVRP, VRP and threading, you'd have to turn off a lot
of optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101862
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150
--- Comment #19 from Andrew Macleod ---
So what kinds of changes trigger this? That patch added a new --param option.
Will this happen every time a --param option is added?
what about changing a param option? because I am about to tweak the op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76174
--- Comment #4 from Andrew Macleod ---
I would argue that this isn't a range issue.
Looking at the code generated without the c *= 2 I see:
:
goto ; [INV]
:
if (q_1 == r_6(D))
goto ; [INV]
else
goto ; [INV]
:
m ();
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
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
> expansio
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=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 won'
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
> > Discuss
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 ran
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 a
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 consideration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113632
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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&action=edit
proposed patch
Does this solve your problem if there is an active ranger? it bootstraps with
no regressions
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=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 going
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&action=edit
patch
Ok, there were 2 issues with simply invoking range_of_stmt, which this new
patch resolves. IF we aren
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=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 ptrs_comp
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=114151
--- Comment #23 from Andrew Macleod ---
Created attachment 57686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57686&action=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=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=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 m_
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
> > iran
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] M
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&action=edit
potental patch
I've attached Aldy's patch for PR109695 which he had backported to GCC13 back
in May.
This doe
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=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,
> tr
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 &r, tree type,
> const irange &lh,
> const irange
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&action=edit
patch to revert the change
Although the bisection stopped at this change, it does not appear to be the
underl
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=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=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
fold_ran
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=110875
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=110249
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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
now
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 which
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
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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>’ does
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 (l_
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
Andrew Macleod changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
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 ar
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]
401 - 500 of 678 matches
Mail list logo
