https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #12 from Andrew Macleod ---
My understanding from a quick check around is we usually expect 8-10 MB of
stack space. I have an idea how to flatten the call stack a bit, so leave this
open for that purpose if nothing else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #10 from Andrew Macleod ---
I would imagine there is some check I should be making that i was unaware of..
but since I'm unaware of it, I don't know what it is :-)
This wouldn't be a "dont use -O2" issue, this would be an "Andrew, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #8 from Andrew Macleod ---
ah. So this is an issue with excessive stack consumption. yeah, we don't really
try to reign that in, so certain patterns can get quite deep.
I am unfamiliar with what mitigations/flags the compiler has fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #6 from Andrew Macleod ---
WE collided making comments :-)
--- or maybe not.. that traceback doesn't look like it would be affected :-(.
The traceback also doesn't look like its in an infinite loop?.. there can be
long chains of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
Andrew Macleod changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494
--- Comment #4 from Andrew Macleod ---
I just checked a patch in for PR 101014 which I suspect will fix this as well..
want to give it a try off trunk? I plan to port it to gcc 11 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
--- Comment #4 from Andrew Macleod ---
When a range is being calculated for an ssa-name, the propagation process often
goes along back edges. These back edges sometime require other ssa-names which
have not be processed yet. These are flagged as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014
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=100299
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=100774
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=100781
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=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=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=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
Andrew Macleod changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
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=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=100081
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=99755
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=98357
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
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=98866
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
--- 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=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=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=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=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=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=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=98144
--- Comment #7 from Andrew Macleod ---
PR 98174 has that patch applied btw.
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=97750
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=98144
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=97434
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=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=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=93917
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=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=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=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 #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=97888
--- Comment #5 from Andrew Macleod ---
Doh, yeah. Patch looks good.
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=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=91029
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
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=85375
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=83073
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=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=79191
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=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=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=97741
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
--- 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=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=97737
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=97725
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=71690
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=97515
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=97596
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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=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=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=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=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=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=97520
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=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=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 #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=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 #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=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 #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 #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 #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=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
501 - 600 of 609 matches
Mail list logo
