https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99755
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #8 from Andrew Macleod ---
OMG. Don't bother reducing. I can see the problem.
EVRP is fine, but when wrestrict runs, its quite late, and the CFG has
[local count: 28382607]:
<...>
_571 = _61 >= _593;
_3583 = &arr_724 + _399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #12 from Andrew Macleod ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Macleod from comment #8)
> > OMG. Don't bother reducing. I can see the problem.
> >
> > EVRP is fine, but when wrestrict runs, its quit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97359
--- Comment #7 from Andrew Macleod ---
There is no need to cache non-logical operands. Processing a relational such as
<,>,<=,>= is a linear process, and therefore we never needed to cache them.
&& and || is exponential as we have to evaluate
o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97378
--- Comment #6 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #2)
> (In reply to David Binderman from comment #1)
>
>
>
> The division by zero was product of various transformations. Basically we
> know that a.0_1 is 0, so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97381
--- Comment #8 from Andrew Macleod ---
in particular:
_2 = (int) c_8;
_3 = _2 * 148372120;
_4 = a.0_1 / _3;
if (_4 != 0)
we do not wind back thru divides at the moment (unless they are exact divides)
so when processing the false edge t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #11 from Andrew Macleod ---
(In reply to Alan Modra from comment #10)
> Here's elf32-arc.i creduced.
>
> a;
> b();
> c() {
> void *d;
> if (d == b && e())
is that actually allowed?
if (d == b) is
void * == (void * ())
I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #13 from Andrew Macleod ---
Created attachment 49386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49386&action=edit
Patch to create integral MAX and MiN
Joy. I'll try it and see what happens.
And back to the first problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #15 from Andrew Macleod ---
Well it seems far more incorrect that types_compatible_p () is FALSE for a type
and its MIN/MAX value?
Whats the point of MIN/MAX if you cant count on them being the right types, or
at least conmpatible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #17 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #16)
> On Fri, 16 Oct 2020, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> >
> > --- Comment #15 from Andrew Macle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #19 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #18)
> On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com
>
> >
> >Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the
> >p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97462
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #21 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #20)
> >
> >Is this your preferred solution?
>
> The backen should use more lowlevel functions to build this type rather than
> copying from a type that isn't a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #25 from Andrew Macleod ---
(In reply to Peter Bergner from comment #24)
> (In reply to Richard Biener from comment #22)
> >tree oi_uns_type = make_unsigned_type (256);
> > - vector_pair_type_node = build_distinct_type_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #30 from Andrew Macleod ---
On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
> --- Comment #28 from Peter Bergner ---
> (In reply to Andrew Macleod from comment #25)
>> Won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
--- Comment #5 from Andrew Macleod ---
Just to further annotate why this is the correct fix for posterity..
evrp/vrp calls adjust_range_with_scev:
/* Start with the input range... */
tree vrmin = vr->min ();
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97520
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #2 from Andrew Macleod ---
Created attachment 49417
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49417&action=edit
check for undefined before not returning a constant value
The ranger deals with UNDEFINED slightly differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #4 from Andrew Macleod ---
Furthermore, this PR is also a good example of a case where we want to inject
updated values into the Ranger's iterator.
:
goto ; [INV]
:
ui_8 = ~xe_3;
if (ui_8 == 0)
goto ; [INV]
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97555
--- Comment #2 from Andrew Macleod ---
:
f.0_1 = f;
_2 = 1 % f.0_1;
h_24 = (char) _2;
_3 = _2;
c = _3;
_4 = b.a;
_5 = (int) _4;
_6 = ~_5;
f = _6;
if (_4 != -1)
goto ; [INV]
else
goto ; [INV]
when calculating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
--- Comment #2 from Andrew Macleod ---
Created attachment 49441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49441&action=edit
combine OR operands with union, not intersect
Fundamentally, this boils down to a bug in logical-combine.
cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
--- Comment #5 from Andrew Macleod ---
Created attachment 49448
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49448&action=edit
Adjust test case for 32 bit
change the testcase type to long long to avoid issues on 32 bit targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596
--- Comment #2 from Andrew Macleod ---
This should be fixed with:
commit 279a9ce9d545f65a0bb1bc4564abafabfc25f82d
Author: Jakub Jelinek
Date: Wed Oct 28 10:24:20 2020 +0100
wide-int: Fix up set_bit_large
> >> wide_int new_lb = wi::s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
--- Comment #4 from Andrew Macleod ---
This worked OK because the code does:
/* Replace real uses in the statement. */
did_replace |= substitute_and_fold_engine->replace_uses_in (stmt);
gimple_stmt_iterator prev_gsi = i;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609
--- Comment #5 from Andrew Macleod ---
Created attachment 49460
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49460&action=edit
call infer_non_null directly
Looking closer at the non-null deref calls, the problem was deep in
stmt_ends_bb_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596
--- Comment #5 from Andrew Macleod ---
sorry, yeah.
done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97725
--- Comment #3 from Andrew Macleod ---
Created attachment 49512
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49512&action=edit
Use a multirange value in value_query::value_of_*
This was triggered by a new call into range_of_stmt to reeva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97725
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741
--- Comment #2 from Andrew Macleod ---
Created attachment 49517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49517&action=edit
don't lose info already in the global range
The problem here is the IL being changed by propagation under to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97737
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741
Andrew Macleod changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741
--- Comment #4 from Andrew Macleod ---
btw, the resulting code for this function is cleaned up a lot:
:
a = 6;
goto ; [INV]
:
c = 0;
:
a.0_2 = a;
if (a.0_2 != 0)
goto ; [INV]
else
goto ; [INV]
:
# e_5 = PHI <0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97737
Andrew Macleod changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #6 from Andrew Macleo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97741
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789
--- Comment #5 from Andrew Macleod ---
Ranger made it in, but relations have not been implemented for this release.
GCC 12 for sure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
--- Comment #7 from Andrew Macleod ---
The original fix was incorrect. It papered over a problem by reducing
opportunities it could find. Given
if (c_2 || c_3)
If the FALSE edge is taken, this is ! (c_2 || c_3) which is equivalent to !c_2
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
--- Comment #7 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #6)
> Ranger knows the range of m_3 on entry to BB3 is:
> [0, 2][4294967296, 18446744069414584322]
> we cant enumerate all the ranges that have [0,2] in the lower wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072
--- Comment #8 from Andrew Macleod ---
I've adjusted range-ops so that EVRP will recognize that
c |= 1
is a non-zero range, and I've added a test case to check it.
The rest of this PR involves exposing ranges in a better way to fold-const.
N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85375
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86707
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 91029, which changed state.
Bug 91029 Summary: missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
--- Comment #5 from Andrew Macleod ---
Doh, yeah. Patch looks good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #12 from Andrew Macleod ---
Maybe I'm a little dense.
if we are presuming that
&x + (a + b)
implies a + b == 0, then we also should assume that
&x + a implies a == 0
and if we can make those assumptions, then
&x + 1 is garb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #10 from Andrew Macleod ---
Created attachment 49597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49597&action=edit
op2_range implementation
I think this does what you want for op2_range.
I tried it with:
void f1 (int i, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #16 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Andrew Macleod from comment #12)
> > Maybe I'm a little dense.
> >
> > if we are presuming that
> > &x + (a + b)
> > implies a + b == 0, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909
--- Comment #1 from Andrew Macleod ---
Yeah, I'm planning as one of the next steps to replace the
SSA_NAME_RANGE_INFO/get_range_info interface with the new range_query interface
from value-query.h
Then we can wire that into the Ranger instance t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93781
Andrew Macleod changed:
What|Removed |Added
Attachment #48008|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93917
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97909
--- Comment #3 from Andrew Macleod ---
It should be able to access the currently known global values that have been
computed, or if there isn't one, it could still go and calculate a global
range. Which is what the default condition would be (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97515
--- Comment #7 from Andrew Macleod ---
Created attachment 49607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49607&action=edit
tweak testcase
The fix for PR 93781 changed the order of some evaluations in the testcase.
the problem is tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96351
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97434
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #6 from Andrew Macleod ---
and when the precision is different what? assume 0's for the missing bits?
If we allow and want that behaviour, we should change the documentation to
reflect that...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #13 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #12)
> So, for start I think we should do:
> 1) query->range_of_expr (m_index_range, m_index_expr, swtch)
>where query is address of gimple_ranger passed down fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97750
--- Comment #7 from Andrew Macleod ---
The op1-range expression solving for the RHS of a cast of the form
low_precision_var = (low_precision) high_precision_var
doesnt support pointers properly.
It fills in possible bit/ranges in high_precisio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97750
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #7 from Andrew Macleod ---
OK, there are a couple of things at play in this PR.
The original problem isn't actually unreachable code. well, sort of.
The pass determines something is unreachable and changes the condition, which
me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #8 from Andrew Macleod ---
(In reply to David Binderman from comment #6)
> I get something similar with this test case:
>
> int a;
> void b() {
> if (a >= 2147483647)
> c(a + 1);
> }
This one is slightly different.
Still trig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
Andrew Macleod changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325
Andrew Macleod changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #2)
> Looking at the evrp dump, I see
> EVRP:hybrid: RVRP found singleton 0
> EVRP:hybrid: RVRP found singleton 0
> EVRP:hybrid: RVRP found singleton 0
>
> Value rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
--- Comment #3 from Andrew Macleod ---
Created attachment 49331
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49331&action=edit
patch to calculate negative side properly
This is actually due to not handling a cast very well when the preci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
--- Comment #6 from Andrew Macleod ---
Thanks, yeah this is the same issue and the patch should fix it..?
the precision difference of one this time is 1 bit (bool) and a 2 bit object...
_5;
bool _6;
<..>
_6 = (bool) _5;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #18 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to Martin Liška from comment #16)
> >
> > EVRP knows the proper range:
> > 2->4 (F) x_6(D) : unsigned int [0, 1][4, 4]
>
> EVRP ATM invokes both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
--- Comment #7 from Andrew Macleod ---
PR 98174 has that patch applied btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #22 from Andrew Macleod ---
(In reply to Martin Liška from comment #21)
> > See my comment above. It isn't any integration of VRP, just asking the
> > ranger about the range, and it isn't useless because to be able to optimize
> > pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707
--- Comment #3 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #2)
> I think another case for ranger symbolic ranges?
indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697
--- Comment #4 from Andrew Macleod ---
(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 mean, for signed t = x % y note that t is
> in [-y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #6)
> CCing Andrew and Aldy to see what the ranger does or can do, talking about
> I mean, if we have:
> h_1 = x_2 / 3600;
> if (x_2 <= -3599 && x_2 <= 8)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513
--- Comment #7 from Andrew Macleod ---
This is in the legacy intersection code
we have
[-INF, minus_1_29(D) + 2] intersect [ -INF + 1, -INF + 2]
it falls into this block:
else if ((operand_less_p (vr1min, *vr0max) == 1
|| ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98028
--- Comment #2 from Andrew Macleod ---
I see
=== BB 2
:
if (j_3(D) > i_4(D))
goto ; [INV]
else
goto ; [INV]
=== BB 3
:
__builtin_unreachable ();
=== BB 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866
--- Comment #1 from Andrew Macleod ---
Very large function (16000+ basic blocks) with a lot of exception regions, and
a pattern whereby about 300 pointers are live to all the regions. We spend a
lot of time propagating an unchanging non-zero prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98866
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98028
--- Comment #4 from Andrew Macleod ---
I would expect in gcc 12 we'll be handling it differently than that.
I have equivalences/relations up and running and will eventually get to
applying those to general statements... which I haven't gotten to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98357
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #8 from Andrew Macleod ---
(In reply to Jeffrey A. Law from comment #7)
> If you're V_C_E-ing to a narrower type, you just ignore the bits outside the
> target type, it's a lot like a narrowing subreg in the RTL world.
>
> I don't kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512
--- Comment #7 from Andrew Macleod ---
# e_25 = PHI
_3 = e_25 + 1;
if (_3 != 0)
goto ; [INV]
else
goto ; [INV]
<...>
:
# e_26 = PHI
in order to take the edge 3->9, _3 must be [0,0]. _27 is used before defined,
so we now use U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Andrew Macleod changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #21 from Andrew Macleod ---
> >
> > Would this be useful? and would it solve this problem? I'm sure there are
> > other details to work out related to the increased precision, but it seems
> > like it might work?
>
> Hmm, so t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #28 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #27)
> On Wed, 26 May 2021, aldyh at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
> >
> > --- Comment #26 from Aldy Hernande
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774
--- Comment #2 from Andrew Macleod ---
I have a fix for this...
Do we add -fcompare-debug tests into the testsuite? I don't see any other
tests with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781
--- Comment #6 from Andrew Macleod ---
So the new code base provides a more complete/consistent export list, and makes
use of imports now. An import is the incoming value which can change an
outgoing value.
In this particular case we see:
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100299
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 638 matches
Mail list logo
