https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108444
Bug ID: 108444
Summary: ICE: invalid address operand in mem_ref when LTO
building 523.xalancbmk_r
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108444
--- Comment #2 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
> dup of PR108445?
Looks like it is, Bugzilla search has failed me again (but I've never been good
at it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108444
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108445
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 108444, which changed state.
Bug 108444 Summary: ICE: invalid address operand in mem_ref when LTO building
523.xalancbmk_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108444
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108445
--- Comment #7 from Martin Jambor ---
I can confirm that xalancbmk_r is LTO-buildable again too. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94360
--- Comment #3 from Martin Jambor ---
LNT can still see this, on the zen2 and zen3 machine at least:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=700.337.0&plot.1=711.337.0&plot.2=740.337.0&plot.3=694.337.0&;
https://lnt.opensuse.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94369, which changed state.
Bug 94369 Summary: 505.mcf_r is 6-7% slower at -Ofast -march=native with
PGO+LTO than with just LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104125
--- Comment #5 from Martin Jambor ---
This still exists but it is a zen2 oddity. The zen3, zen4 and cascade-lake
machines I looked at this month don't exhibit this behavior (or at least I
don't see an obvious regression).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94373, which changed state.
Bug 94373 Summary: 548.exchange2_r run time is 16-35% worse than GCC 9 at -O2
and generic march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90128, which changed state.
Bug 90128 Summary: 507.cactuBSSN_r is 9-11% slower at -Ofast and native
march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 104122, which changed state.
Bug 104122 Summary: On Zen3, 510.parest_r (built with -Ofast) is faster with
generic than with native ISA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94410
--- Comment #3 from Martin Jambor ---
This is still the case, as can be seen on LNT (GCC 9 is the dot in the left
bottom corner):
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=690.467.0&plot.1=745.467.0&plot.2=777.467.0&plot.3=687.467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94360
--- Comment #5 from Martin Jambor ---
Well, if the current behavior is a good one (I have not looked at how
size/performance trade-off works out) then I am also fine declaring this bug
invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #14 from Martin Jambor ---
Honza, what remains to be done here (if anything)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469
--- Comment #19 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #16)
> Martin, is that a real fix for this or it just went latent?
Not a fix, the bug mst be latent. But it is surprising so I'll have a look
what happened too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158
--- Comment #4 from Martin Jambor ---
(In reply to Richard Biener from comment #3)
> it looks like the testcase no longer shows the issue(?) but the code in IPA
> SRA didn't really change here
I have fixed quadratic behavior in ipa-param-manipu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90151
--- Comment #3 from Martin Jambor ---
In January 2022 I see 9% regression on zen2, 8% regression on zen3 and
CascadeLake and 7% on zen4 (compared to gcc 7). I no longer track
zen1. LNT largely confirms these observations although it tracks -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84481
--- Comment #17 from Martin Jambor ---
Looking LNT (and excluding machines which are no longer active), the worst
regression is now 4% and that only at -O2 -Ofast. Probably not a very high
priority then (do we want to close this?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 101296, which changed state.
Bug 101296 Summary: Addition of x86 addsub SLP patterned slowed down 433.milc
by 12% on znver2 with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
What|Remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108629
Bug ID: 108629
Summary: 549.fotonik3d_r regresses 15-24% at -O2 -flto
-march=x86-64-v3 since r13-1203-g038b077689bb53
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #13 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611194.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
--- Comment #3 from Martin Jambor ---
What happens is that ipa_param_body_adjustments::modify_call_stmt
is confused by the IPA-CP produced scalar constant where it expects a
structure containing just one field of the corresponding type.
It is e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
--- Comment #4 from Martin Jambor ---
I have proposed the fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611978.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108800
Bug ID: 108800
Summary: Missed optimization: IPA-SRA keeps a single-field
structure formal parameter even when IPA-CP knows its
contents
Product: gcc
Version: 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
--- Comment #5 from Martin Jambor ---
If you rename main to something else, like bar, and so the calls to f
outside of the loop are not considered cold, you get the GCC 12
behavior. Is this reduced from a real-world problem?
Because on the tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108226
--- Comment #2 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
>
> so somehow the restrict qualification pessimizes IPA-CP?! Martin?
>
Well, funny thing. Without restrict, IPA-CP sees (from release_ssa dump):
void Func3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #7 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612506.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #7 from Martin Jambor ---
The situation is that in func_61 we have an unused parameter which
IPA-SRA wants to remove. It's caller constructs the unused parameter
with the following sequence (shortened):
int func_43 (int * p_44)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
Bug ID: 109130
Summary: 464.h264ref regressed by 6.5% on a Neoverse-N1 CPU
with PGO, LTO, -Ofast and -march=native
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #10 from Martin Jambor ---
Fixed on trunk so far, I plan to backport it to GCC 12 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96059
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96059
--- Comment #4 from Martin Jambor ---
...and Honza correctly guessed that it is ICF that merges the two functions
(virtual and non-virtual) and that is how we ended up in the situation that the
devirtualizing machinery returns a non-virtual funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104762
Bug ID: 104762
Summary: x86_64 538.imagick_r 8%-28% regressions after
r12-7319-g90d693bdc9d718
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104762
Martin Jambor changed:
What|Removed |Added
Summary|x86_64 538.imagick_r 8%-28% |x86_64 538.imagick_r 8%-28%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813
--- Comment #4 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591423.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #5 from Martin Jambor ---
(In reply to Richard Biener from comment #4)
> Does this still happen after the last fiddling?
Unfortunately yes, the run-time is still 27% worse than when compiled with the
commit previous to the one ident
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071
--- Comment #3 from Martin Jambor ---
(In reply to Martin Liška from comment #2)
> Fixed on master with r10-3311-gff6686d2e5f797d6, if I add -fno-ipa-sra for
> the revision, it's still correct.
But it also works if you add -fno-inline ! ;-)
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071
--- Comment #4 from Martin Jambor ---
I have asked for permission to backport the fix in
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592520.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105071
Martin Jambor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
Martin Jambor changed:
What|Removed |Added
CC||dlong at cadence dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
Martin Jambor changed:
What|Removed |Added
Assignee|jamborm at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
--- Comment #4 from Martin Jambor ---
I expected that the only call of bar in the testcase to be always
inlined everywhere but apparently it is not at least on i?86-*-* with
-mno-sse (and I expect the problem to be the same on the other
reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
--- Comment #5 from Martin Jambor ---
I proposed to increase the parameter specification in the test in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592994.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #8 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #7)
> Or find out why SRA doesn't optimize this (remove the useless union, replace
> all the un.value occurrences with a var with Foo type.
IIUC, it just isn't profit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
--- Comment #16 from Martin Jambor ---
I tend to think Honza kept the bug open as a reminder to look into things
listed in comment #8. Those should probably be tracked in another bug,
alternatively this one should be adjusted to reflect that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Bug ID: 105275
Summary: 525.x264_r and 538.imagick_r regressed on x86_64 at
-O2 with PGO after r12-7319-g90d693bdc9d718
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100413
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100413
--- Comment #7 from Martin Jambor ---
I proposed the aforementioned fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593732.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100413
--- Comment #9 from Martin Jambor ---
Now fixed in trunk, I'll backport to 12 and 11 after 12.1 is released.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107206
--- Comment #5 from Martin Jambor ---
I believe this is fallout from the fix to PR 92706 where we started
propagating accesses across assignments also from LHS to RHS and
because everything is totally flow-insensitive, we have an access
represen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
--- Comment #9 from Martin Jambor ---
(In reply to Roger Sayle from comment #7)
> A default expansion for MULT_HIGHPART_EXPR was proposed as part of
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551316.html
> I'll split off just that pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100491
--- Comment #8 from Martin Jambor ---
I believe this has been fixed in November by r12-5223-gecdf414bd89e6b.
(At some point I'll verify it, unless someone is faster, for which I
would be grateful).
Unfortunately, I do not expect the commit to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103990
Bug ID: 103990
Summary: 541.leela_r slower by 4.5-6% with PGO+LTO -Ofast
-march=native in the first week of January 2022
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103990
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
>
> should fix that
I can confirm that it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
Bug ID: 104122
Summary: On Zen3, 510.parest_r (built with -Ofast) is faster
with generic than with native tuning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104125
Bug ID: 104125
Summary: 531.deepsjeng_r regressed on Zen2 CPUs at -Ofast
-march=native (without LTO) during GCC 12 development
Product: gcc
Version: 12.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
--- Comment #1 from Martin Jambor ---
On the said EPYC machine, I could see 6% regression at -O2 as well and then
confirmed it on the Ryzen. Again, historical data suggests generic improved
more than native and we already had a 4% regression wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> It's ISA, not tuning.
You are of course correct, unfortunately I am too accustomed to
using the wrong term.
> I suppose -march=native -mtune=generic is still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
--- Comment #4 from Martin Jambor ---
(In reply to Martin Jambor from comment #3)
> (In reply to Richard Biener from comment #2)
>
> > I suppose -march=native -mtune=generic is still bad?
>
> I don't know, I'd have to manually check.
>
It tur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90151
--- Comment #2 from Martin Jambor ---
Reconfirmed in 2021 too, also on LNT. The best way to see current
status is probably to go to
https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch?sorting=gcc-7%2Cgcc-8%2Cgcc-9%2Cgcc-10%2Cgcc-11%2C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
--- Comment #10 from Martin Jambor ---
We still regress, according to LNT 8% on zen2:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=335.437.0&plot.1=309.437.0&plot.2=346.437.0&plot.3=276.437.0&plot.4=398.437.0&plot.5=417.437.0&plot.6=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104125
--- Comment #3 from Martin Jambor ---
The patch did not change the run-time (by more than could be attributed to
noise). I will take a *quick* look at what happened in October.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
Bug ID: 104271
Summary: 538.imagick_r run-time at -Ofast -march=native
regressed by 26% on Intel Cascade Lake server CPU
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171
--- Comment #5 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589429.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
Martin Jambor changed:
What|Removed |Added
Summary|[10/11/12 Regression] Wrong |[10/11/12 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104125
--- Comment #4 from Martin Jambor ---
Despite spending much more time on this than I wanted I was not able
to find out anything really interesting.
The functions that slowed down significantly is feval (FWIW, perf
annotation points down to a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #2 from Martin Jambor ---
(In reply to Hongtao.liu from comment #1)
> I think this patch has already been reverted by
> r12-3011-g1db70e61a92978377a648bbd90e383859fc0126b.
Unfortunately that revision does not help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104466
Bug ID: 104466
Summary: Inlining functions with restrict parameters can
inhibit lim (e.g. in 554.roms_r)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104466
--- Comment #1 from Martin Jambor ---
Created attachment 52393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52393&action=edit
Test-case
Forgotten testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104377
--- Comment #2 from Martin Jambor ---
(In reply to Feng Xue from comment #1)
>
> OK. I does missed something. Here we could not hold assumption that
> ipcp_decision_stage() only sees raw cgraph node, since sometime in the
> future some new ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104377
--- Comment #3 from Martin Jambor ---
By the way, it would be good to invent some (slightly?) more intuitive API for
ipa_param_adjustments adjustments, merging and similar operations. I simply
left it for later when I hoped I would have a bette
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104457
--- Comment #2 from Martin Jambor ---
I have made some substantial changes to how profile_counts are updated in
IPA-CP, so trying the current master is definitely a good idea. It might just
work and even if it does not, fixing it there would pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #8 from Martin Jambor ---
I am about to thest the following patch. In longer-run, it would be better to
never generate lattice values outside of the value_range but there is an
ordering problem, we need the complete VR info before w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
--- Comment #5 from Martin Jambor ---
I have changed the patch a bit and re-submitted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590341.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #11 from Martin Jambor ---
I am very well aware that my patch was just a mitigation, not
something that would avoid the problem under all circumstances. We
can attempt to look at array access indices during the summary
creation phas
101 - 200 of 684 matches
Mail list logo
