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
COLLECT_LTO_WRAPPER=/opt/notnfs/aldyh/bld/threader/ada/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.2.1/l
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=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 sh
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: norm
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=101694
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
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=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=101724
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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=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
--- 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:
> /gcc/testsuite/g++.dg/warn/Ws
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 inclined,
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=101938
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Co
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 r
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 #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 j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
Aldy Hernandez changed:
What|Removed |Added
CC|aldyh at redhat dot com|
--- Comment #3 from Aldy Herna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #7 from Aldy Hernandez ---
Let me see if I can untangle things here. Thanks for chasing
this down, BTW.
Value_Range doesn't need a CTOR because it has an int_range_max which
does have one (courtesy of int_range<>), so things get in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #8 from Aldy Hernandez ---
(In reply to Richard Biener from comment #5)
> (In reply to Martin Jambor from comment #4)
> > The right place where to free stuff in lattices post-IPA would be in
> > ipa_node_params::~ipa_node_params() wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #9 from Aldy Hernandez ---
Created attachment 57477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57477&action=edit
Remove virtual from int_range destructor.
Bootstraps. Tests are pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #10 from Aldy Hernandez ---
Created attachment 57478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57478&action=edit
Remove GTY support for vrange and friends
Bootstraps. Tests are pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #11 from Aldy Hernandez ---
Both patches pass test. Up to the release maintainers to decide if they want
to include them in this release. Otherwise, I'll queue them up for later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #13 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Aldy Hernandez from comment #11)
> > Both patches pass test. Up to the release maintainers to decide if they
> > want to include them in this re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #18 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #17)
> On Wed, 21 Feb 2024, aldyh at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
> >
> > --- Comment #8 from Aldy Hernande
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #5)
> (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 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #13 from Aldy Hernandez ---
I think y'all have it all figured out. Basically,
operator_cast::op1_range() is solving num_5 in the equation:
[111,111] = (short int) num_5
Where lhs is:
(gdb) p debug(lhs)
[irange] short int [111, 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
--- Comment #3 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #2)
> It almost looks like a costing issue. The threaders find opportunities to
> thread all the incoming edges in the key block to the path which avoids the
> call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110753
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110753
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110875
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468
Bug ID: 111468
Summary: cannot express unordered equal in gimple FE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468
--- Comment #6 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> Fixed on trunk.
Sweet. Thanks so much. This really helps.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111458
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> This issue is still latent in the forward threader. The backward threader
> calls this function from back_threader_profitability::profitable_path_p,
> so bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #30 from Aldy Hernandez ---
(In reply to Richard Biener from comment #15)
> We're also doing a lot of redundant stmt simplifications by likely
> quadratically
> exploring jump threading paths. And each hybrid_jt_simplifier::simplif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #22 from Aldy Hernandez ---
Created attachment 59001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59001&action=edit
reduce recursion in forward threader (patch in testing)
As suggested by Richard in PR116166.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #23 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #22)
> Created attachment 59001 [details]
> reduce recursion in forward threader (patch in testing)
>
> As suggested by Richard in PR116166.
Should've been more v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #24 from Aldy Hernandez ---
(In reply to Richard Biener from comment #13)
> Most of the -O1 dom time is spent in threading using path ranger to simplify
> the JT conditions. That in turn does (for each threading from scratch?)
> GOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #25 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #22)
> Created attachment 59001 [details]
> reduce recursion in forward threader (patch in testing)
Avoiding unnecessary recursion in simplify_control_stmt_conditi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #26 from Aldy Hernandez ---
I think there's something fundamentally wrong in the *backwards* threader that
causes us to blow up, even without fully resolving conditions with a global
ranger.
I tried running at -O1 and -fenable-tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #35 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #34)
> Btw, if we simply remove the call to that function, with -O1
> -fenable-tree-thread1 I see:
>
> backwards jump threading : 14.36 ( 3%) 0.39 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #36 from Aldy Hernandez ---
(In reply to Richard Biener from comment #33)
> Can we just sort m_paths after the path entry BB and fix the lookup that way?
This seemed promising, especially because the adjust_paths_after_duplication()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323
--- Comment #7 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #6)
> (In reply to Jakub Jelinek from comment #4)
> > Or the ranger could do it itself, similarly to how it handles .ASSUME, but
> > without actually querying anythin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #8 from Aldy Hernandez ---
(In reply to avieira from comment #5)
> Im slightly confused here, on entry to BB 5 we know the opposite of _1 < 0.0
> no? if we branch to BB 5 we know !(_1 < 0.0) so we can't fold _1 <= 1.0, we
> just know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #10 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #9)
> (In reply to Richard Biener from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > ah, probably it's the missing CSE there:
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233
--- Comment #10 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #8)
> And on the ranger side why we have determined the [0, 5] range rather than
> [0, 4], whether it is related to inaccurate number of iterations estimation,
> or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #13 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Aldy Hernandez from comment #10)
> > BTW, I don't think it helps at all here, but casting from l_10 to a float,
> > we know _1 can't be either -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #9 from Aldy Hernandez ---
It looks like what we want for this test is actually !isgreaterequal() not
isless(), since we want to exclude the possibility of a NAN. Like this:
float test (float x)
{
if (!__builtin_isgreaterequal (x,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
Aldy Hernandez changed:
What|Removed |Added
CC||llvm at rifkin dot dev
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109593
--- Comment #5 from Aldy Hernandez ---
Huh. I'm gonna guess:
commit 10e481b154c5fc63e6ce4b449ce86cecb87a6015
Author: Aldy Hernandez
Date: Thu Jan 26 04:46:54 2023 +0100
Return true from operator== for two identical ranges containing NA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109593
--- Comment #8 from Aldy Hernandez ---
Created attachment 54908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54908&action=edit
untested patch
Patch in testing. Does this fix the problem on the reporter's side?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109593
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109643
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639
Aldy Hernandez changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639
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=109639
--- Comment #13 from Aldy Hernandez ---
Sorry, it wasn't the setter doing the normalization, but the
range_fold_{unary,binary}_expr helpers. Since IPA was the only user of these
deprecated functions, this should be relatively easy to contain.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639
--- Comment #14 from Aldy Hernandez ---
Created attachment 54939
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54939&action=edit
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109639
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
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=109695
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2023-05-02
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #6 from Aldy Hernandez ---
I forgot to add. Running with "ulimit -s unlimited" does not segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #13 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #12)
> Perhaps change int_range to have the wide_ints as auto_vec with reserved
> space for a few (perhaps 3 (times 2))?
Our original implementation was exactly tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
--- Comment #8 from Aldy Hernandez ---
Created attachment 54980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54980&action=edit
untested
This may fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
Aldy Hernandez changed:
What|Removed |Added
Attachment #54980|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54627
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #23 from Aldy Hernandez ---
An update on the int_range_max memory bloat work.
As Andrew mentioned, having int_range<25> solves the problem, but is just
kicking the can down the road. I ran some stats on what we actually need on a
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #24 from Aldy Hernandez ---
FYI. I originally tried new/delete for allocation, which was a tad slower than
ggc_alloc / ggc_free. Not too much, but measurable.
Another idea would be to have a global obstack which auto_int_range<> u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #28 from Aldy Hernandez ---
Created attachment 55031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55031&action=edit
WIP patch for a dynamic int_range<>
Here's my WIP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #30 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #29)
> Comment on attachment 55031 [details]
> WIP patch for a dynamic int_range<>
>
> What I meant is that by using a auto_vec could avoid reimplementing larger
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #34 from Aldy Hernandez ---
Excellent ideas!
For that matter, we may get away with defaulting to 3 sub-ranges and always
resizing as needed (up to MAX). Needing more than 3 sub-ranges is so rare
(less than 0.5% of the time), that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #35 from Aldy Hernandez ---
We could also tweak the number of sub-ranges. 8 (??) also sounds good for a
few percent less in performance drop, if we care.
p.s. I did try the auto_vec thing for a 25% loss in VRP performance, even whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #3 from Aldy Hernandez ---
(In reply to Richard Biener from comment #2)
> Confirmed. This is a missed optimization, we fail to optimize the loop guard
>
> [local count: 329643239]:
> _4 = (unsigned long) &MEM [(void *)&str + 2B];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #4 from Aldy Hernandez ---
BTW, another reason I had to drop the prange work was because IPA was doing
their own thing with ranges outside of the irange API, so it was harder to
separate things out. So really, all this stuff was rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #6 from Aldy Hernandez ---
> but the issue with the PHI node remains unless we sink the &str part
> (but there's many uses of __i_14). I guess it's still the "easiest"
> way to get rangers help. Aka make
>
> # __i_14' = PHI <1(1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #1 from Aldy Hernandez ---
Since this happens while building libgcc during stage1, perhaps this can be
reproduced with a cross? Would it be possible to get the preprocessed file
that's failing?
You could try /var/gcc/reghunt/sigbus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #12 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #10)
> If Aldy does not fix it by Saturday, I will give the union a try then. I
> will also try out the solaris machine on the compile farm if possible.
Sorry, didn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #2 from Aldy Hernandez ---
Yeah, that's mine.
Can you attach a preprocessed file of the offending file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #13 from Aldy Hernandez ---
BTW, I'm waiting for a review, or at least a nod from a C++ savvy person here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #6 from Aldy Hernandez ---
I wonder if something like this would work.
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 5781f50..ea8a685 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1730,6 +1730,8 @@ ipa_value_range_from_jfunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #15 from Aldy Hernandez ---
Created attachment 58136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58136&action=edit
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #16 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > --- Comment #13 from Aldy Hernandez ---
> > BTW, I'm waiting for a review, or at least a nod from a C++ savvy person
> > here:
> >
> > htt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
--- Comment #10 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #7)
> For rl78:
> static scalar_int_mode
> rl78_addr_space_address_mode (addr_space_t addrspace)
> {
> switch (addrspace)
> {
> case ADDR_SPACE_GENERIC:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
--- Comment #11 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #8)
> And on msp430-elf we're getting a codegen correctness issue on msp430-elf.
> gcc.dg/pr66444.c fails in the simulator. The -O2 code difference looks like:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #10 from Aldy Hernandez ---
(In reply to David Edelsohn from comment #9)
> The patch in comment 6 succeeds for me, but it seems more of a heavy-handed
> band-aid that confirms the symptom, but covers up the problem.
>
> Something in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #11 from Aldy Hernandez ---
I have reverted the prange enabling patch until the IPA pass is fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #12 from Aldy Hernandez ---
Created attachment 58168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58168&action=edit
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
Bug ID: 115026
Summary: msp430-elf fails gcc.dg/pr66444.c with prange enabled
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
601 - 700 of 752 matches
Mail list logo
