Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Blocks: 63426
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114627
--- Comment #3 from Martin Jambor ---
So, should this be marked as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 116370, which changed state.
Bug 116370 Summary: UBSAN issue in fortran/trans-expr.cc in
arrayfunc_assign_needs_temporary - enum value out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116370
What|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116370
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
--- Comment #7 from Martin Jambor ---
Fixed on master, I plan to backport the fix (the first patch) to the affected
release branches next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #25 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6ed6kntue@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87332
Bug 87332 depends on bug 115277, which changed state.
Bug 115277 Summary: [13 regression] ICF needs to match loop bound estimates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #20 from Martin Jambor ---
Indeed, the UBSAN failures I see now look like they are all PR 116370. Thanks!
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: pault at gcc dot gnu.org
Blocks: 63426
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #14 from Martin Jambor ---
This issue is still present and unfortunately it is the kind of bug that either
creates manual periodic work because people need to go over logs to verify that
no new other UBSAN failure has appeared or it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116230
--- Comment #6 from Martin Jambor ---
Right, when I saw the equality test of doubles I thought it must be the test. I
forgot about the discrepancy of representation in memory and in the FPU.
Thanks a lot for taking a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116230
--- Comment #1 from Martin Jambor ---
Created attachment 58830
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58830&action=edit
minimized test-case
I have tried to minimize the testcase with cvise and came up with the
attached file. Howe
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: i586-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
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=58416
Martin Jambor changed:
What|Removed |Added
Attachment #58724|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #19 from Martin Jambor ---
(In reply to Richard Biener from comment #18)
> (In reply to Martin Jambor from comment #15)
> > Created attachment 58724 [details]
> > simple (wip) fix
> >
> > I'm wondering whether just simply something l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #15 from Martin Jambor ---
Created attachment 58724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58724&action=edit
simple (wip) fix
I'm wondering whether just simply something like this would not be enough. I
have looked at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #11 from Martin Jambor ---
Our weekend ubsan bootstrap and test (of revision
r15-2173-ge0d997e913f811) still reported failures when compiling
testcase gfortran.dg/ieee/large_1.f90 (at -O2 and higher).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: law at gcc dot gnu.org
Blocks: 63426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
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 109130, which changed state.
Bug 109130 Summary: [13/14/15 Regression] 464.h264ref regressed by 6.5% on a
Neoverse-N1 CPU with PGO, LTO, -Ofast and -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: linkw at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: sparc-wrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hongyuw at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
The run-time of benchmark
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: ---
Benchmark 416.gamess from SPECINT 2006 recently regressed on
: 14.0
Status: 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
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: ubizjak at gmail dot com
Target Milestone: ---
Compiling the testcase (minimized from grub2):
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310
--- Comment #4 from Martin Jambor ---
(In reply to Sam James from comment #2)
> In such environments, you don't need an explicit
> -Werror=return-type.
I agree I don't need it but it is there.
> So, you're asking presumably about testing with
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Consider:
echo 'main () { return 0; }' > t.c
and then
gcc -S -Werror=re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
--- Comment #2 from Martin Jambor ---
(In reply to Jan Hubicka from comment #1)
> Reproduces on 14 and trunk. GCC 12 is not able to determine the loop bound
> during early optimizations
What about gcc 13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115174
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #32 from Martin Jambor ---
(In reply to Marc Poulhiès from comment #31)
> Hello Martin,
>
> Any chance the fix that fixes the new test for 32bits can be also backported?
>
> 4923ed49b93352bcf9e43cafac38345e4a54c3f8
> https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #20 from Martin Jambor ---
The IL we generate the jump function from is:
_1 = cclauses_2(D) != 0B;
c_parser_omp_all_clauses (_1);
Which translates to the expected jump function:
callsite void c_parser_omp_teams(int**)/3 ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #29 from Martin Jambor ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #19 from Martin Jambor ---
The following minimized testcase ICEs with r15-312-g36e877996936ab
cross-compiler to ppc64le with -O2 nicely:
void omp_clause_elt_check(int *, const char *, const char *);
enum { C_OMP_CLAUSE_SPLIT_COUNT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #16 from Martin Jambor ---
I'll have look, hopefully on Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
The following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935
--- Comment #3 from Martin Jambor ---
This ICE no longer happens with GCC 13, in fact after r13-4240-gfeeb0d68f1c708
(Martin Jambor: ipa-cp: Do not consider useless aggregate constants). From the
patch description, it does not look to be a fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
Martin Jambor changed:
What|Removed |Added
Known to work||13.1.0
Summary|[11/12/13/14/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #5 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> No, I think the issue is that ESRA leaves e.f0 alone:
>
> e$f3_7 = e.f3;
> e$f0$f4_8 = e.f0.f4;
> _1 = e$f0$f4_8;
> _2 = (unsigned char) _1;
> e$f3_9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #6 from Martin Jambor ---
(In reply to Paweł Bylica from comment #5)
> (In reply to Martin Jambor from comment #4)
> > In this testcase all (well, both) functions referenced from the array
> > are semantically equivalent which is rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
--- Comment #5 from Martin Jambor ---
Thanks a lot for taking care of it before I had a chance to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #75 from Martin Jambor ---
The above fixes the testcase from comment #58. I am not sure if any other
testcases discussed here remain unresolved. I am also not sure to what extent
we want to that patch of mine, I guess I'll re-visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #26 from Martin Jambor ---
This should be fixed on master, I'll backport the fix in a few weeks to at
least gcc-13 where it was reported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #9 from Martin Jambor ---
On master this has been fixed by r14-9813-g8cd0d29270d4ed where I
unfortunately copy-pasted a wrong bug number :-/
I assume this needs backporting to at least gcc-13 and gcc-12. I'll do
that in a week or tw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #4 from Martin Jambor ---
Oops. I made a mistake, the commit above fixes PR 114247, sorry :-/
This one is the next in my queue. Sorry again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #7 from Martin Jambor ---
Thanks, I will bootstrap and test the patch on x86_64 and submit it
for review then.
Can I ask you, can you please modify the testcase so that it does not
use printf but simply calls __builtin_abort in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #24 from Martin Jambor ---
(In reply to Jan Hubicka from comment #23)
> I however wonder if we really guarantee to copy the paddings everywhere else
> then the total scalarization part?
> (i.e. in all paths through the RTL expansion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #71 from Martin Jambor ---
I have sent the patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6le5s25kl@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Martin Jambor changed:
What|Removed |Added
Summary|[13/14 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #4 from Martin Jambor ---
I don't seem to be able to get riscv64 qemu running in reasonable
time. Can someone please verify that the following patch fixes
the issue?
diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipu
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #3 from Martin Jambor ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #22 from Martin Jambor ---
Created attachment 57828
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57828&action=edit
Potential fix
I'm testing this patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
Martin Jambor changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #66 from Martin Jambor ---
Created attachment 57750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57750&action=edit
Patch comparing jump functions
I'm testing this patch. (Not sure how to best check that it does not
inadvert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254
Martin Jambor changed:
What|Removed |Added
Summary|[11/12/13/14 regression]|[11/12/13 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
Martin Jambor changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #65 from Martin Jambor ---
I hope to have some jump-function comparison functions ready for testing later
today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #5 from Martin Jambor ---
I'd like to ping this, are there plans to implement this in the near-ish term?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
--- Comment #4 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gbwf7l@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254
--- Comment #1 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #8 from Martin Jambor ---
I have proposed an improved patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: jamborm at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Target Milestone: ---
Created attachment 57634
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57634&action=edit
t
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #7 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6y1bdx3yg@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111573
--- Comment #2 from Martin Jambor ---
I cannot see any difference at -O3 with or without -fno-early-inlining.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112312
--- Comment #4 from Martin Jambor ---
It seems this has been fixed in current master (which is to become gcc 14).
If my bisecting is correct, it has been fixed by r14-5628-g53ba8d669550d3 (Jan
Hubicka: inter-procedural value range propagation).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
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=113359
--- Comment #15 from Martin Jambor ---
Created attachment 57462
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57462&action=edit
Simple testcase (needs disabling early - and only early - SRA)
This is a simpler testcase which exhibits the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #6 from Martin Jambor ---
I have proposed a patch on the mailing list that converts the array of lattices
to a vector:
https://inbox.sourceware.org/gcc-patches/ri6frxoxzpk@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #20 from Martin Jambor ---
I have access to the benchmark and building it with -fprofile-generate
it fails for me (with an ICE in add_symbol_to_partition_1) only when I
use -fno-use-linker-plugin and either -std=c++11 or -std=c++03.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #18 from Martin Jambor ---
(In reply to Filip Kastl from comment #17)
> I've bisected this (using the test from Andrew Pinski) to
> r10-3311-gff6686d2e5f797
That's a coincidence, with -fno-ipa-sra the testcase fails even earlier,
IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
--- Comment #6 from Martin Jambor ---
(In reply to Richard Biener from comment #5)
> CCing also Martin who should know how/why IPA SRA doesn't reconstruct the
> component ref chain here
I have not had a look at this specific case (yet), but IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
--- Comment #4 from Martin Jambor ---
Created attachment 57397
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57397&action=edit
-fopt-info-vec before/after comparison
(In reply to Richard Biener from comment #3)
> A compare before/after t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: fxue at os dot amperecomputing.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
--- Comment #8 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6bk8r5kfi@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #14 from Martin Jambor ---
(In reply to rguent...@suse.de from comment #13)
> Might be also an interaction with IPA ICF in case there's a pointer to
> the pair involved?
Yes, this is exactly what seems to be happening. The problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #9 from Martin Jambor ---
SRA creates the replacements (in GCC 13) during total scalarization,
i.e. the bit that is not driven by pre-existing accesses to
aggregates, but because it sees an aggregate that is small and regular
and so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
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=113646
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
> Did you try with -fprofile-partial-training (is that default on? it
> probably should ...). Can you please try training with the rate data
> instead of train
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: syq at gcc dot gnu.org
Target Milestone: ---
: 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
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux, aarch64
sion: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
--- Comment #4 from Martin Jambor ---
(In reply to Hongtao Liu from comment #2)
> A patch is posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640276.html
>
> Would you give a try to see if it fixes the regression, I don't cur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
Martin Jambor changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
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-linux-gnu
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
--- Comment #3 from Martin Jambor ---
I have re-checked this year again (using master revision
r14-7200-g95440171d0e615) but this time on a high-frequency Zen3 CPU (EPYC
75F3). Run-time of 525.x264_r built with master with PGO and -O2 improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112616
--- Comment #8 from Martin Jambor ---
Fixed on trunk. I did not want to backport this but because this variant does
not require disabling DCE, I will probably do after a few weeks on master, if
there are no issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
--- Comment #22 from Martin Jambor ---
Fixed on trunk. I did not want to backport this but because of PR 112616 I
will probably do after a few weeks on master, if there are no issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113490
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #4 from Martin Jambor ---
The right place where to free stuff in lattices post-IPA would be in
ipa_node_params::~ipa_node_params() where we should iterate over lattices and
deinitialize them or perhaps destruct the array because sinc
1 - 100 of 1259 matches
Mail list logo
