https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 89430, which changed state.
Bug 89430 Summary: A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
What|Removed |Added
--
||jamborm at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #11 from Martin Jambor ---
(In reply to Jeffrey A. Law from comment #10)
> Fixed on the trunk.
So marking as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #51 from Martin Jambor ---
(In reply to Andrew Pinski from comment #48)
> This should also work too:
> diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
> index ea8594db193..83b1d981439 100644
> --- a/gcc/tree-sra.c
> +++ b/gcc/tree-sra.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435
--- Comment #8 from Martin Jambor ---
The issue actually started with my r8-344-2bba75411e1 and it is
basically a perfect SRA bomb, it makes SRA sub-access propagation
accross assignments create gazillions of accesses and then
replacements, becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435
Martin Jambor changed:
What|Removed |Added
Summary|[8/9/10 Regression] Hang|[8/9 Regression] Hang with
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
Target Milestone
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
SPEC 2017 INTrate benchmark
: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90056, which changed state.
Bug 90056 Summary: 548.exchange2_r regressions on AMD Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90056
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90056
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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: ---
Host: x86_64-linux
: 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
When compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90056
--- Comment #3 from Martin Jambor ---
So replaced with more specific bugs for newer hardware: PR94373 and PR94375.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87528
--- Comment #8 from Martin Jambor ---
Do I understand correctly that this is fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
--- Comment #3 from Martin Jambor ---
(In reply to Hongtao.liu from comment #1)
> Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548
> according to our experience.
I have seen this helping on one system running SLES 15.1
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
Target: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369
--- Comment #3 from Martin Jambor ---
I did not save the reported number of samples but from the raw sample
numbers and percentage points it seems so:
(562770/0.4013)/(518450/0.3953) = 1.069
Nevertheless, I did save separately obtained perf st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234
Martin Jambor changed:
What|Removed |Added
Summary|503.bwaves_r is 6% slower |503.bwaves_r is 6% slower
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: andre.simoesdiasvieira at arm dot com
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #1 from Martin Jambor ---
For the record, the collected profiles both for the traditional
"cycles:u" event and (originally unintended) "ls_stlf:u" event are
below:
-Ofast -march=native -mtune=native
# Samples: 894K of event 'cycles:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #2 from Martin Jambor ---
And for completeness, LNT sees this too and has just managed to catch the
regression:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=276.427.0&plot.1=295.427.0&;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #3 from Martin Jambor ---
One more data point, binary compiled for cascadelake does not run on
Zen2, but one for znver2 runs on Cascade Lake and it makes no
difference in run-time.
If disapling epilogues helps on Intel, the differenc
: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94410
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94360
--- Comment #2 from Martin Jambor ---
PR94410 is another O2 PGO+LTO bug where g:2925cad2151 caused a slowdown.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364
Martin Jambor changed:
What|Removed |Added
Last reconfirmed|2019-05-06 00:00:00 |2020-3-30
Summary|521.wrf_r i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90283
--- Comment #5 from Martin Jambor ---
The numbers from this year are:
- on Intel Cascade Lake server CPU the regression disappeared, if
there ever was one, I don't have Skylake numbers this year.
- On AMD Zen1 CPU, the measured regression is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94410
--- Comment #2 from Martin Jambor ---
For the record, SPEC 2006 453.povray is similarly affected, the commit
makes it run 26% slower.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90151
--- Comment #1 from Martin Jambor ---
This year's numbers:
- on AMD Zen1, we are still 7.2% worse than GCC 7
- on AMD Zen2, the reegression is 4.6%
- in Intel Cascade Lake server CPU, it is 5.4%
This is all -O2, so perhaps not that important fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
--- Comment #4 from Martin Jambor ---
For the record, on AMD Zen2 at least, SPEC 2006 410.bwaves also runs
about 12% faster with --param vect-epilogues-nomask=0 (and otherwise
with -Ofast -march=native -mtune=native).
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: ---
Host: x86_64-linux
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94427
--- Comment #1 from Martin Jambor ---
OK, so it turns out the identified commit only allows us to shoot
ourselves in the foot - and there one too few branches, not too many.
The hottest loop, consuming most of the time is:
Percent Instr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364
--- Comment #2 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
> Huh, looks like this is the (patched by us) memory copying done in
> spec_qsort?
Yes
> I wonder if you can re-measure with our patching undone but then with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
--- Comment #6 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> Do we ever hit the vectorized paths?
What's the best way to find out? If I open the disassembled code in
perf report and search for ymm, some of these (groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364
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 94364, which changed state.
Bug 94364 Summary: 505.mcf_r is 8% faster when compiled with
-mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 94364, which changed state.
Bug 94364 Summary: 505.mcf_r is 8% faster when compiled with
-mprefer-vector-width=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94364
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92676
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
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=93621
--- Comment #9 from Martin Jambor ---
(In reply to Jan Hubicka from comment #3)
> The testcase builds for me now, but this is Martin's code
that's questionable :-) Git blame points correctly to me but before
new IPA-SRA the assert used to be:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #13 from Martin Jambor ---
(In reply to Jan Hubicka from comment #12)
> > Having said that, I am not sure where to best fix this so late in the
> > GCC 10 development cycle.
>
> So the problem is that thunk is expanded on the adjuste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #14 from Martin Jambor ---
Actually, we should be able to simply skip applying adjustments, if
e->caller->former_thunk_p(). I'm playing with a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #15 from Martin Jambor ---
It turns out that no, recursive inlining will happily put an adjusted and not
yet adjusted call into the same function which was formerly a thunk.
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #16 from Martin Jambor ---
The following workaround works for the testcase but would need to be
generalized for a chain of former_decl_of's to be universal, I'm afraid:
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 6b780f80eb3..241b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435
--- Comment #13 from Martin Jambor ---
The problematic behavior of SRA is now fixed on master and both opened
release branches so I consider my work done here.
I'm leaving the bug opened in case Jeff wants to add some DSE limiter
like he wrote i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #17 from Martin Jambor ---
Created attachment 48208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48208&action=edit
WIP patch
This is the current version of my patch to fix this. I think that at
least for the purposes of JIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #21 from Martin Jambor ---
As Richi already found out, the path in sra_modify_expr handling type
incompatible replacement does not work when the replaced expr comes
from within a BIT_FIELD_REF - it does only half of what is necessary.
||2020-04-09
Component|tree-optimization |ipa
Status|UNCONFIRMED |ASSIGNED
CC||jamborm at gcc dot gnu.org,
||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
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=94434
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=94434
Martin Jambor changed:
What|Removed |Added
Attachment #48248|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550
--- Comment #3 from Martin Jambor ---
Almost certainly started with new IPA-SRA (r275982 or as we now call
it gcc-10-3311-gff6686d2e5f). I looked at dumps from a cross-compiler
and the funny bit is, however, that new IPA-SRA simply does nothing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550
Martin Jambor changed:
What|Removed |Added
Component|ipa |target
--- Comment #4 from Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434
--- Comment #3 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543658.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94434
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #18 from Martin Jambor ---
I posted a patch to fix this for review to the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543659.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
--- Comment #2 from Martin Jambor ---
For arrays of size 1, get_ref_base_and_extent knows that the expression can
only access the one element even if the index is a variable. It seems it does
not happen if the ARRAY_REF is within a COMPONENT_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
--- Comment #3 from Martin Jambor ---
I'm going to test the following:
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2357,9 +2357,11 @@ verify_sra_access_forest (struct access *root)
gcc_assert (base == first_base);
gcc_assert (off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
--- Comment #4 from Martin Jambor ---
I proposed the fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543909.html
(Note that the one in comment #3 has a small but important typo.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94598
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #17 from Martin Jambor ---
Created attachment 48302
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48302&action=edit
Untested fix
I'm playing with this - only very mildly tested - fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #22 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #18)
> Comment on attachment 48302 [details]
> Untested fix
>
> + /* IPA-SRA does not analyze other types of statements. */
> + gcc_unreachable ();
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #25 from Martin Jambor ---
(In reply to rguent...@suse.de from comment #21)
> Btw, I'd much prefer to not first copy the stmts and then remove them.
> Instead the DCE "analysis" can be done on the original IL and stmts
> be "marked" t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #30 from Martin Jambor ---
Created attachment 48320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48320&action=edit
Todays WIP patch
This is my todays (still very much) WIP patch.
- It marks statements which should not be cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472
--- Comment #3 from Martin Jambor ---
My benchmarking setup is currently gone so unfortunately no, not easily. I'll
be re-measuring everything on a different computer with a slightly different
CPU model soon, so after that I guess I could. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856
--- Comment #7 from Martin Jambor ---
The "edge points to wrong decl" case is a verifier error. We have a
method which (in the course of IPA-CP) loses its this pointer because
it is unused and the pass then does not clone all the this adjusting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856
--- Comment #8 from Martin Jambor ---
I proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544943.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94856
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68033
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336
--- Comment #6 from Martin Jambor ---
(In reply to Erick Ochoa from comment #0)
[...]
> I did a bisection from
>
> commit f47f687a97260b1a1305cbf2d7ee3d74b2916a74
> Author: Richard Biener
> Date: Thu Apr 25 17:58:56 2019 +
>
> to:
>
>
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Created attachment 48608
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343
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=95343
--- Comment #2 from Martin Jambor ---
(In reply to Martin Jambor from comment #1)
> ...I am testing a patch which can make gdb actually show
> the correct 4.
I meant the correct value 2, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95380
--- Comment #4 from Martin Jambor ---
(In reply to Martin Liška from comment #3)
> Fixed for master, not planning to backport that.
Why not? Are any of the parameters only in GCC 11?
Should I prepare a special GCC 10 patch just to address the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #35 from Martin Jambor ---
I have proposed a patch series that deals with this issue, including proper
adjustments to debug info, on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546702.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
--- Comment #4 from Martin Jambor ---
(In reply to Arseny Solokha from comment #3)
>
> Indeed, -fno-ipa-sra fixes it. So, a duplicate of PR93385?
Similar, but not quite the same. I have proposed a fix on the mailing
list: https://gcc.gnu.org/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343
--- Comment #3 from Martin Jambor ---
I have proposed a patch series on the mailing list to address PR 93385 and the
last patch in it also addresses this issue and allows gdb to print the correct
value of the removed parameter:
https://gcc.gnu.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
--- Comment #7 from Martin Jambor ---
Fixed. Thanks for reporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Bug 93385 depends on bug 95113, which changed state.
Bug 95113 Summary: [10/11 Regression] Wrong code w/ -O2 -fexceptions
-fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95970
Martin Jambor changed:
What|Removed |Added
Last reconfirmed||2020-06-29
Ever confirmed|0
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #4 from Martin Jambor ---
I'll have a look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040
--- Comment #5 from Martin Jambor ---
IPA-split puts the double access to the union in the .part function
and keeps only the long int access in the "original" function.
IPA-SRA thinks it can work with that but the code in "transitive" call
parame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040
--- Comment #7 from Martin Jambor ---
Yes, IPA-SRA identifies accesses by both offset and size, so the situation
would not have happened if the size was different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040
--- Comment #9 from Martin Jambor ---
True. Richi expressed preference for avoiding the transform when there are type
mismatches, so I'm currently bootstrapping that. I guess we can always revisit
the decision if we ever discover it would be rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #2 from Martin Jambor ---
I guess I should take a look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96235
--- Comment #6 from Martin Jambor ---
(In reply to Martin Liška from comment #4)
> It seems to me something related to IPA SRA.
> @Martin: Can you please take a look?
I will but -fno-dce -fno-tree-dce strongly suggest this is a duplicate of PR
9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96291
Martin Jambor changed:
What|Removed |Added
Assignee|jamborm at gcc dot gnu.org |slyfox at inbox dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96235
Martin Jambor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Martin Jambor changed:
What|Removed |Added
CC||suochenyao at 163 dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84481
--- Comment #12 from Martin Jambor ---
I can once again confirm the slowdown on a zen1-based machine (commit
6e1e0decc9e vs gcc 7.5) but it is not present on a zen2-based one. I wonder
whether the bug should me marked as WONTFIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84490
--- Comment #15 from Martin Jambor ---
The problem sometimes is still there, sometimes it isn't:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=37.100.0&plot.1=27.100.0&;
I wonder whether we should keep this bug opened, the benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234
Martin Jambor changed:
What|Removed |Added
Summary|503.bwaves_r is 6% slower |503.bwaves_r is 6% slower
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #2 from Martin Jambor ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730
--- Comment #3 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552488.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 2365 matches
Mail list logo
