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=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=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=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=104466
--- Comment #1 from Martin Jambor ---
Created attachment 52393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52393&action=edit
Test-case
Forgotten testcase
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
We have
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=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=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=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
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: liuhongt at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #4 from Martin Jambor ---
I'm about to test a patch.
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=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=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=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=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 #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
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: amacleod at redhat dot com
Blocks: 26163
Target Milestone
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
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.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
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=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=98782
--- Comment #29 from Martin Jambor ---
(In reply to Tamar Christina from comment #23)
> I wonder if we can get rid of the final magic parameter too, we run with
> --param ipa-cp-unit-growth=80 too which seems to have no more effect on
> exchange,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103267
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103449
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103267
--- Comment #10 from Martin Jambor ---
I have proposed a patch to address this issue in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585756.html
Well, it prevents the infinite loop testcase from segfaulting when the
function infini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103449
--- Comment #6 from Martin Jambor ---
In my defense, even in my old code, in the call
m_dead_ssa_debug_equiv.put (dead_ssa, *d)
I would expect the load *d to be evaluated before the inline template
function put is invoked and it feels strang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103449
--- Comment #5 from Martin Jambor ---
(In reply to Martin Liška from comment #3)
> What likely happens is that 'tree *d' is a pointer to the hash_map. Then you
> want to put another item in the same hash_map (m_dead_ssa_debug_equiv.put),
> it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103449
--- Comment #4 from Martin Jambor ---
Making the hash_map big enough not to reallocate makes the valgrind complaint
go away (of course, this is an experiment, not a suggested fix):
diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103449
--- Comment #2 from Martin Jambor ---
The second "Invalid read of size 8" can be avoided with the following
(untested but correct):
diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
index 479c20b3871..ff65dad0971 100644
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #6 from Martin Jambor ---
Created attachment 51884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51884&action=edit
Untested fix
I am testing this fix
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #4 from Martin Jambor ---
Oops, I knew I forgot some peculiarity about the transformation phase TODOs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #12 from Martin Jambor ---
Some testing is still underway, but I have proposed the patch (with one minor
testsuite change) on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585337.html
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #11 from Martin Jambor ---
Created attachment 51863
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51863&action=edit
Untested fix
I am testing the attached patch.
I would like to file a new bug for the testcase in com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #7 from Martin Jambor ---
(In reply to hubicka from comment #5)
> > I like the idea of transformation phases better than putting
> > everything into tree-inline (and by extension ipa-param-manipulation)
> > but perhaps we have to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #4 from Martin Jambor ---
Still, the interaction between IPA-CP and IPA-SRA is bad here. Just
looking at the optimized dump, one of the "specialized functions"
starts with:
[local count: 62767467]:
# DEBUG D#203 s=> row
# DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #7 from Martin Jambor ---
I have to leave the office for today. The problematic option seems to be
-fdump-ipa-inline. With it, 28 out of 124 partitions are different in their
ccp2 dumps but so far I only found UID differences.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103246
--- Comment #6 from Martin Jambor ---
Fun fact, for me the benchmark passes (test) verification when built with:
-O2 -g -flto=16 -fno-ipa-sra
but fails when built with:
-O2 -g -flto=16 -fno-ipa-sra -fdump-ipa-all
Consistently so. On revis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
--- Comment #6 from Martin Jambor ---
(In reply to Martin Sebor from comment #5)
> I replied earlier on gcc-patches: I've always intended the access attribute
> to eventually benefit optimization so please feel free (and encouraged :) to
> use i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
--- Comment #4 from Martin Jambor ---
(In reply to Jan Hubicka from comment #0)
> Hi,
> ipa-fnsummary sets can_change_signature flag which determines whether we can
> manipulate parameters of a given function. It tests:
>
>/* Type attr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #5 from Martin Jambor ---
On one of my machines I can see the ICE with an LTO
profiledbootstrapped compiler but neither with a normally bootstrapped
compiler nor with an LTO-bootstrapped compiler, without PGO. I have
not yet tried w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97403
--- Comment #3 from Martin Jambor ---
(In reply to Jan Hubicka from comment #2)
> Martin,
> I think we can close this (possibly adding the testcase)
Depends. ANCESTOR got generalized a bit but the propagation at IPA-CP level
still does not take
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103155
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103132
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103132
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103107
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103099
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103107
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=103099
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=103099
--- Comment #2 from Martin Jambor ---
I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
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=102505
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102886
--- Comment #2 from Martin Jambor ---
I posted a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582380.html
||2021-10-22
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #1 from Martin Jambor ---
Oh, stupid me... mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102505
--- Comment #5 from Martin Jambor ---
I proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582249.html
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
--- Comment #10 from Martin Jambor ---
Looking at the LNT graph, I guess this bug should be either closed or suspended
(not sure what the suspended state means for the blocked metabug, so probably
closed).
Yeah, it's weird.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #4 from Martin Jambor ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102388
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
--- Comment #10 from Martin Jambor ---
(In reply to Hongtao.liu from comment #6)
> Does it means cycles?
Basically yes, AFAIK. Basically I ran both versions under perf record
and then processed the output (so that is not so wide) of perf repo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102388
--- Comment #2 from Martin Jambor ---
I proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580183.html
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: crazylht at gmail dot com
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #1 from Martin Jambor ---
Mine, looks like a lot of fun.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #4 from Martin Jambor ---
(In reply to Martin Jambor from comment #3)
> ...I'll have a very brief look at what is actually happening just so that I
> have more reasons to believe this is not a code placement issue again.
The hot fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
> Martin, maybe you can try moving late sink to before the last phiopt pass.
If you mean the following then unfortunately that has not helped.
diff --git a/gcc/
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
When
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
When compiling the following
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linix
Target: x86_64-linux
LNT has detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
--- Comment #11 from Martin Jambor ---
(In reply to Andrew Pinski from comment #10)
> Even LLVM does this same thing.
What do you mean by "does this same thing?" Does it copy the structure
element-wise or does it copy it is a block like GCC does
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
All three LNT x86_64 testers have experienced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80735
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101654
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101654
Martin Jambor changed:
What|Removed |Added
Last reconfirmed||2021-07-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101626
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101560
--- Comment #3 from Martin Jambor ---
(In reply to H.J. Lu from comment #2)
> Please try
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575829.html
I can confirm the patch avoids the ICE.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101398
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242
--- Comment #3 from Martin Jambor ---
Profiled LTO bootstrap also fails with a segfault with the same backtrace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Martin Jambor changed:
What|Removed |Added
Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242
--- Comment #1 from Martin Jambor ---
For the reference, this is the backtrace:
mjambor@virgil:/tmp/bbb$ ~/gcc/trunk/inst/bin/gcc -S -Ofast test.i
during GIMPLE pass: slp
test.i: In function ‘check_su3’:
test.i:11:5: internal compiler error: S
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Since commit 2ad71efb5de (fix BB reduc permute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
--- Comment #3 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573338.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90404
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
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=100453
--- Comment #13 from Martin Jambor ---
Another attempt to fix this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572814.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100597
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Martin Jambor changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
--- Comment #4 from Martin Jambor ---
I proposed a patch to address this on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570267.html
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #3 from Martin Jambor ---
Mine.
401 - 500 of 2265 matches
Mail list logo
