https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115221
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
--- Comment #7 from Aldy Hernandez ---
Created attachment 58272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58272=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> Confirmed.
>
> /* After the optimization PHI result can have value
> which it couldn't have previously. */
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
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=115131
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115131
--- Comment #5 from Aldy Hernandez ---
Created attachment 58224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58224=edit
patch in testing
at gcc dot gnu.org |aldyh at gcc dot gnu.org
Last reconfirmed||2024-05-17
Ever confirmed|0 |1
--- Comment #3 from Aldy Hernandez ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115128
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115128
--- Comment #3 from Aldy Hernandez ---
Created attachment 58222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58222=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115128
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #19 from Aldy Hernandez ---
(In reply to Richard Biener from comment #17)
> Handling pointer-vs-pointer in ptrs_compare_unequal isn't enough since we
> have
>
> # PT = nonlocal null
> unsigned int * x_7(D) = x;
> ...
> # PT =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #32 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #31)
> > --- Comment #29 from Aldy Hernandez ---
> [...]
> > Ok, what's the minimum configuration I need to build here?
> >
> > srcdir/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #30 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #29)
> > > gmake[3]: Leaving directory '/home/aldyh/bld/clean'
> > > Comparing stages 2 and 3
> > > Bootstrap comparison failure!
> > > gcc/tree-vect-stmts.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #29 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #28)
> > --- Comment #27 from Aldy Hernandez ---
> > This is in cfarm216.cfarm.et:
> >
> > aldyh@s11-sparc:~/bld/clean$ hostname
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #27 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> > --- Comment #25 from Aldy Hernandez ---
> > prange has been enabled again, after testing on x86-64 and ppc64le linux.
> > Aarch has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #25 from Aldy Hernandez ---
prange has been enabled again, after testing on x86-64 and ppc64le linux.
Aarch has no space to run tests on the compile farm, and sparc bootstrap was
already broken.
The problem in this PR can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #22 from Aldy Hernandez ---
(In reply to Martin Jambor from comment #20)
Thanks for looking into this.
> The IL we generate the jump function from is:
>
> _1 = cclauses_2(D) != 0B;
> c_parser_omp_all_clauses (_1);
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #13 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #10)
> Created attachment 58202 [details]
> proof of concept implementing a range-op entry for builtin_assume_aligned
>
> Something like this (properly coded and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #11 from Aldy Hernandez ---
Just to clarify. prange as well as irange keep a value/mask pair where we can
store alignment info, so every calculation (range-op) along the way can track
this properly.
Now, for pointers we loose this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #10 from Aldy Hernandez ---
Created attachment 58202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58202=edit
proof of concept implementing a range-op entry for builtin_assume_aligned
Something like this (properly coded and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #9 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> The above examples just show misunderstanding what __builtin_assume_aligned
> is and what it is not. You need to use the result of the built-in function
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #18 from Aldy Hernandez ---
Ah, it looks like seurer already beat me to the preprocessed source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #17 from Aldy Hernandez ---
(In reply to Martin Jambor from comment #16)
> I'll have look, hopefully on Monday.
Thanks Martin.
To reproduce the problem:
1. Revert this patch:
commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #8 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #7)
> So what's the magic to re-enable prange? I can do that and spin a fresh
> build.
You could revert this patch:
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Aldy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #4 from Aldy Hernandez ---
Jeff, if you still have your tree around, could you try this patch?
I'll queue it with the rest of patches I will push before enabling prange when
the IPA issues are sorted out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #3 from Aldy Hernandez ---
Created attachment 58169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58169=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #2 from Aldy Hernandez ---
OK, this is embarrassing.
We are incorrectly folding a POINTER_PLUS_EXPR range operation:
Folding statement: x_7 = 2048B + _2;
-Queued stmt for removal. Folds to: 2062B
+Queued stmt for removal. Folds
|1
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
Last reconfirmed||2024-05-10
--- Comment #1 from Aldy Hernandez ---
All mine baby!
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
This is a separate issue reported by Jeff in PR115009. I have reproduced on a
cross compiler.
Copied below is his report:
And on msp430-elf we're
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=edit
proposed patch in testing
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 #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=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
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=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
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=114912
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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:
> >
> >
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=edit
proposed patch in testing
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 @@
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
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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,
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
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
>
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,
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
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
> >
> >
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
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 #10 from Aldy Hernandez ---
Created attachment 57478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57478=edit
Remove GTY support for vrange and friends
Bootstraps. Tests are pending.
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=edit
Remove virtual from int_range destructor.
Bootstraps. Tests are pending.
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()
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
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
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=113735
--- Comment #6 from Aldy Hernandez ---
Created attachment 57336
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57336=edit
Proposed patch #2
Thanks for the suggestion Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #4 from Aldy Hernandez ---
Created attachment 57335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57335=edit
Proposed patch
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #2 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> Slightly tweaked, still -O1:
> char b;
> void bar (void);
>
> void
> foo (_BitInt(6110) j)
> {
> for (;;)
> {
> _BitInt(10) k = b % j;
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958
--- Comment #7 from Aldy Hernandez ---
Created attachment 57016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57016=edit
preprocessed testcase with GCC13
Compile with -O2 -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
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
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.
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
Target Milestone: ---
Created attachment 55930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55930=edit
Failing testcase
It looks like you can't express an UNEQ_EXPR in the GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110875
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
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=110753
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #17 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> Phiopt does this:
> ```
> v_13 == 1 ? 1 : LookupFlags_6
> Matching expression match.pd:1990, gimple-match-5.cc:23
> Matching expression match.pd:1990,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #4 from Aldy Hernandez ---
FWIW, a less intrusive and probably more correct way of seeing what ranger
knows at this point would be to put a breakpoint where you're seeing:
Queued stmt for removal. Folds to: 2147483647
This is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #3 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #2)
> VRP2/DOM3 produces the wrong folding for some reason:
> Folding statement: _27 = b.6_9 * 2;
> Queued stmt for removal. Folds to: 2147483647
>
> I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #38 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #37)
> (In reply to CVS Commits from comment #36)
>
> > For the curious, a particular hot spot for IPA in this area was:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
--- Comment #3 from Aldy Hernandez ---
Created attachment 55140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55140=edit
untested patch in testing
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #2 from Aldy Hernandez ---
Woah...this is a latent bug in irange::invert that seems to have been here for
a very long time.
In the loop unswitching code we do:
false_range = true_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
--- Comment #2 from Aldy Hernandez ---
Created attachment 55137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55137=edit
untested patch
Does this fix the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #4 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #2)
> > If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> > integer/pointer, but if range_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #2 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #1)
> Breakpoint 6, range_cast (r=..., type=) at
> /home/apinski/src/upstream-gcc/gcc/gcc/range-op.cc:4853
> 4853 Value_Range tmp (r);
>
>
> Confirmed.
> The
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 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(10),
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
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) [(void *) + 2B];
> _6 =
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
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
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 #28 from Aldy Hernandez ---
Created attachment 55031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55031=edit
WIP patch for a dynamic int_range<>
Here's my WIP.
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<>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54627
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
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=109711
Aldy Hernandez changed:
What|Removed |Added
Attachment #54980|0 |1
is obsolete|
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=edit
untested
This may fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
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
1 - 100 of 1805 matches
Mail list logo
