https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #6 from Aldy Hernandez ---
Can this be re-checked now that the forward threader has been dropped post-VRP?
BTW, please CC me on any compile-time hogs related to the threader, especially
if it's not SPEC related, as I've yet to hunt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #1 from Aldy Hernandez ---
Is this still an issue with the new jump threader?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #3 from Aldy Hernandez ---
*** Bug 102895 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #9 from Aldy Hernandez ---
(In reply to Martin Liška from comment #8)
> Started with Aldy's commit
> r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844.
Hmmm, this commit disables problematic threads we've agreed are detrimental to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #8)
> The 'tree VRP threader' instances are now gone (well, obviously..). There's
> now
>
> backwards jump threading : 15.98 ( 13%)
> TOTAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365
--- Comment #1 from Aldy Hernandez ---
Ok, this is getting ridiculous. I'm tired of these weird finite-math-only
combinations in Vax and rx-elf. I think we should just test -ffinite-math-only
and -fno-finite-math-only in the self tests for all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365
--- Comment #2 from Aldy Hernandez ---
Created attachment 53761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53761&action=edit
untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355
--- Comment #2 from Aldy Hernandez ---
Created attachment 53768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53768&action=edit
untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355
--- Comment #4 from Aldy Hernandez ---
fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394
--- Comment #2 from Aldy Hernandez ---
This is interesting.
quux() was analyzed and a global range was set that included the possibility of
+NAN, but when it was inlined into bar(), the assert making sure no NANs crept
in for -ffinite-math-on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394
--- Comment #3 from Aldy Hernandez ---
Created attachment 53772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53772&action=edit
untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107420
--- Comment #1 from Aldy Hernandez ---
Can this be reproduced on a cross? Could you provide a preprocessed source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107490
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107490
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #5 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #4)
> + // Reflect the mask as a simple range. For example, a mask of
> + // 0xff00 could be represented as [0,0][0x100, 0x].
> + if (TYPE_UNSIGNED (type ())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #7 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #6)
> (In reply to Aldy Hernandez from comment #4)
>
> >
> > The patch below does this, but it does have a 3% penalty for VRP (though no
> > penalty to overall comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #8 from Aldy Hernandez ---
Created attachment 53826
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53826&action=edit
untested
Here's what I tested and we're still around a 3% degradation for VRP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #9 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #7)
> (In reply to Andrew Macleod from comment #6)
> > (In reply to Aldy Hernandez from comment #4)
> > 3) It also seems to me that you then only need to add the zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #10 from Aldy Hernandez ---
Original TYPE_UNSIGNED patch with leading / trailing suggestions: -2.52%
As attached: -3.62%
Moving the code out of set_range_from_nonzero_bits back into set_nonzero_bits:
-3.7%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Aldy Hernandez changed:
What|Removed |Added
Attachment #53826|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
--- Comment #12 from Aldy Hernandez ---
Created attachment 53831
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53831&action=edit
solution improving MULT_EXPR range-ops
Another solution is just improving the MULT_EXPR range-op entry. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
--- Comment #4 from Aldy Hernandez ---
This is an issue with the TRUNC_DIV_EXPR range-op entry optimizing divisions by
powers of 2 into right shifts. We're right shifting the mask by the shift
amount.
operator_div::fold_range():
...
...
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
--- Comment #5 from Aldy Hernandez ---
Created attachment 53841
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53841&action=edit
untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55155
Bug 55155 depends on bug 55157, which changed state.
Bug 55157 Summary: Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Bug ID: 107561
Summary: g++.dg/pr17488.C regression due to -Wstringop-overflow
problem
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #1 from Aldy Hernandez ---
Created attachment 53848
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53848&action=edit
preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Aldy Hernandez changed:
What|Removed |Added
Summary|[13 Regression] |[13 Regression]
|g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> This probably boils down to the object size machinery ignoring [0, 0] (aka
> not picking a convex hull of the range). The range implementation of all
> these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
Bug 68097 depends on bug 24021, which changed state.
Bug 24021 Summary: VRP does not work with floating points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 24021, which changed state.
Bug 24021 Summary: VRP does not work with floating points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646
--- Comment #5 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> It's
>
> edge
> back_threader::maybe_register_path (back_threader_profitability &profit)
> {
> edge taken_edge = find_taken_edge (m_path);
>
> if (taken_e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #11 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > The cdce case is something I've mentioned today:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #12 from Aldy Hernandez ---
It looks like the code reading from the blob in SSA_NAME_RANGE_INFO and
populating an frange is always leaving the NAN bit toggled even if it wasn't in
the stored range.
Does this help?
diff --git a/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #13 from Aldy Hernandez ---
Created attachment 53861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53861&action=edit
preprocessed testcase for comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #1 from Aldy Hernandez ---
pinskia is a god. How does he keep track of all these bugs, plus the cross
reference between them? I knew PR91645 was related, but it was specifically
something on my radar, not the 5 trillion bugs in pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #1)
> > pinskia is a god. How does he keep track of all these bugs, plus the cross
> > reference between them? I knew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps before we try to map MULT_EXPR into some irange/frange op the usual
> way,
> while we still have access to gimple statement check if it is MULT_EXPR wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #19 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #18)
> Ok, just so that I don't just kibbitz/review frange stuff but also try to do
> something, here is my so far untested attempt at normal multiplication
> fold_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #24 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #22)
> Folding statement: _2 = __builtin_pow (1.0e+1, _1);
> Global Exported: _2 = [frange] double [0.0 (0x0.0p+0), +Inf] +NAN
> The +NAN looks suspicious, shouldn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #25 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #23)
> Created attachment 53866 [details]
> gcc13-pr107569.patch
>
> Updated version of the patch I'll test now (if you don't have any nits).
> Besides the thinko I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #27 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Aldy Hernandez from comment #24)
> > If you single step from there on, we run into:
> >
> > if (gimple_stmt_nonnegative_warnv_p (call, &strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #29 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Aldy Hernandez from comment #27)
> > > As for signed zeros in -fsigned-zeros (default) mode, wonder if we e.g.
> > > don't
> > > say sqrt is non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #30 from Aldy Hernandez ---
Created attachment 53869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53869&action=edit
do not set NAN sign in frange::set_nonnegative()
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #32 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #31)
> Created attachment 53873 [details]
> gcc13-pr107569-div.patch
>
> This is what I meant by complete nightmare - division.
Ugh, yeah. That's pretty bad. (No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #33 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #31)
> Created attachment 53873 [details]
> gcc13-pr107569-div.patch
>
> This is what I meant by complete nightmare - division.
We can take this to gcc-patches whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #35 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #34)
> (In reply to Aldy Hernandez from comment #33)
> > what you're looking for is frange::maybe_isinf.
>
> Again, that works on frange, which I don't have here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
--- Comment #10 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #8)
> While the patch passed bootstrap/regtest, I'm afraid it is not correct.
>
> What we have is lhs = op1 * 0.0; with range of lhs [-0.0, 0.0] and range of
> op2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 68097, which changed state.
Bug 68097 Summary: We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-11-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #1 from Aldy Hernandez ---
Created attachment 53920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53920&action=edit
untested
[PR tree-optimization/107732] [range-ops] Handle attempt to abs() negatives.
The threader is creati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #3 from Aldy Hernandez ---
(In reply to Andrey Alekseenko from comment #2)
> @Aldy Hernandez, thank you. Can confirm that your patch fully resolves the
> issue for me.
No problem. Thank your for reporting and for reducing. It make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #2 from Aldy Hernandez ---
(In reply to Zhendong Su from comment #0)
> Compiler Explorer: https://godbolt.org/z/Tc8vbearG
>
> It appears to be a regression from 11.3.
>
> [561] % gcctk -v
> Using built-in specs.
> COLLECT_GCC=gcctk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #4 from Aldy Hernandez ---
(In reply to Martin Liška from comment #3)
> > Isn't there an uninitialized read from "i" here?
>
> Yes ...
>
> > At least on the second
> > time through the outer loop, if (a < h) is true since 1 < 0.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #7 from Aldy Hernandez ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #0)
> > ... but then
> > comes dom2 and happily replaces
> > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #8)
> (In reply to Aldy Hernandez from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > (In reply to Jakub Jelinek from comment #0)
> > > > ... but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985
--- Comment #3 from Aldy Hernandez ---
Another alternative would be to add an is_a/as_a handler for unsupported_type's
in value-range.h and a corresponding entry for unsupported types in
range_operator:
virtual bool fold_range (irange &r, tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #4)
> the gimple_range_op_handler constructor should check the operands for
> supported types as well before setting m_valid.
>
> There is also a ripple effect in g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105432
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844
--- Comment #26 from Aldy Hernandez ---
(In reply to Richard Biener from comment #25)
> I'm not sure about the state of this bug - the issue reproduces on the GCC
> 10 branch with checking enabled and -O[2s] -fdisable-tree-fre4
> -fno-strict-ove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844
--- Comment #28 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #27)
> We're not using the backward threader to replace DOM's threader yet. I've
> got a TODO to push on Aldy's patch, but haven't been able to get to it over
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105820
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106114
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #1 from Aldy Hernandez ---
I wonder if this is the same problem we see on x86-64 on line 198.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106114
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106144
Bug ID: 106144
Summary: wide_int shifted_mask() and mask() do not agree
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106144
--- Comment #3 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 53228 [details]
> gcc13-pr106144.patch
>
> Untested fix.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
--- Comment #1 from Aldy Hernandez ---
Hmmm, this patch shouldn't alter current behavior.
I can't reproduce on current trunk on a cross:
--enable-languages=c --target=cris-sim
abulafia:~/bld/tcris/gcc$ ./cc1 uninit-4.c -O1 -Wuninitialized -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #1 from Aldy Hernandez ---
Silly question...
In the lto1 that ICEs, we have the following in
a.ltrans0.ltrans.094t.fixup_cfg3 (i.e. before DOM even comes into the picture):
// Local variable
struct VideoFrame videoFrame;
...
..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
--- Comment #9 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #8)
> Just glad it's fixed. I hope my bisection didn't waste too much of anyone's
> time.
Heh, not mine. It was unlikely it was the nonzero bit patch as that just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #3 from Aldy Hernandez ---
(In reply to Richard Biener from comment #2)
> the reduction probably ended up removing the initialization as that's not
> needed to reproduce the ICE
Ah.
I'm seeing a whole slew of uses before initializa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #4 from Aldy Hernandez ---
For example, in create():
[local count: 1073741824]:
_15 = MEM[(struct VideoFrame &)&videoFrame].lineSize;
_16 = (long unsigned int) _15;
_17 = MEM[(struct vector *)&videoFrame + 8B].D.4741._M_imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #5 from Aldy Hernandez ---
(In reply to Hans-Peter Nilsson from comment #4)
> The XPASS:es seem to be the same for everyone, with the FAIL only appearing
> on ILP32.
>
> Aldy, how about correcting those xfail markers and adding one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106292
--- Comment #2 from Aldy Hernandez ---
(In reply to Martin Liška from comment #1)
> Fixed with r13-1684-g554b21edb9ec91a8.
Thanks for tracking this down Martin.
Sorry for the pain. It was a silly oversight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314
Bug ID: 106314
Summary: GTY fails on virtual int but not virtual void
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314
--- Comment #2 from Aldy Hernandez ---
The upcoming floating point ranges (frange) are small enough (one or two words)
that I thought we could get away with streaming them as is to GC for global
ranges (SSA_NAME_RANGE_INFO).
We have a mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> GC only supports POD-like data structures, esp. proper inheritance is not
> supported so supporting virtual functions looks useless.
Hmmm, in that case I'll r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
Bug ID: 101671
Summary: pr83510 fails because threader confuses -Warray-bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101673
Bug ID: 101673
Summary: shorter unprofitable jump thread path inhibits
threading of larger path
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
Bug ID: 101674
Summary: gcc.dg/uninit-pred-9_b.c fails after jump threading
rewrite
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101675
Bug ID: 101675
Summary: analyzer/pr94851-2.c marked XFAIL because it fails
with new jump threader
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101667
--- Comment #2 from Aldy Hernandez ---
I was able to reproduce on my Fedora 11.1.1 system compiler, but it seems to
work on trunk:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/notnfs/aldyh/bld/threader/ada/install/bin
501 - 600 of 752 matches
Mail list logo
