https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106057
--- Comment #1 from Jan Hubicka ---
C only testcase (also misoptimized in clang)
#include
int b;
jmp_buf buf;
__attribute__((noinline))
int maybethrow()
{
if (!b)
longjmp (buf,1);
return 2;
}
void
test(int
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
int a;
int b;
__attribute__((const))
int maybethrow()
{
if (!b)
throw(0);
return 0;
}
void
test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105917
Jan Hubicka changed:
What|Removed |Added
Summary|Missed passthru jump|[10/11/12/13 regression]
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
In this testcase:
struct a {int a;};
struct b {int b; struct a a;};
__attribute__ ((noinline))
static int
reta (struct a a)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739
--- Comment #10 from Jan Hubicka ---
I am testing
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index afd9222b5a2..c037668e7d8 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -1112,6 +1112,10 @@ ipa_load_from_parm_agg (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739
--- Comment #9 from Jan Hubicka ---
Indeed volatile checks seems to be missing across ipa-prop code. Here is
smaller testcase:
__attribute__((noinline))
static int
test2(int a)
{
if (__builtin_constant_p (a))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739
--- Comment #8 from Jan Hubicka ---
After inlning I see:
IPA function summary for rcu_tasks_trace_pertask/5350 inlinable
global time: 13.535950
self size: 11
||2022-05-26
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #4 from Jan Hubicka ---
mine. Looks like another case where ipa and local cprop gets out of sync...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727
--- Comment #6 from Jan Hubicka ---
I don't know what clang does, but GCC keeps builtin_constant_p till late
optimization and resolves it then. So here we cross module inline (or constant
propagate) and then it becomes constant.
Outcome of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103818
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #3 from Jan Hubicka ---
mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103680
--- Comment #5 from Jan Hubicka ---
The cfgcleanup logic is consistent assuming that your profile was consistent on
the input (i.e. read from profile feedback). If you
1) read profile
2) do optimization and prove that given if conditional is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103819
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103378
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103818
--- Comment #4 from Jan Hubicka ---
We have access list:
Base 0: alias set 2
Ref 0: alias set 1
access: Parm 0 param offset:0 offset:-4611686018427387936 size:32
max_size:32
access: Parm 0 param offset:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103378
--- Comment #6 from Jan Hubicka ---
I am testing
diff --git a/gcc/cgraphunit.cc b/gcc/cgraphunit.cc
index 01f4e28204e..bc3dc754481 100644
--- a/gcc/cgraphunit.cc
+++ b/gcc/cgraphunit.cc
@@ -621,6 +621,7 @@ cgraph_node::analyze (void)
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #6 from Jan Hubicka ---
OK, tree-ssa-alias is using:
if (ref_may_access_global_memory_p (ref))
to determine if the access to S9b.6_22 may be used by the call. I expected
this to return true because memory pointed to S9b.6_22 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
--- Comment #5 from Jan Hubicka ---
It is indeed missing logic to merge the side_effect and nondeterministic flag
while updating after inlining. I am testing the following
diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
index
at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #4 from Jan Hubicka ---
Mine.
The inliner pass is supposed to update the summary so it seems like a bug
there.
I will take a look tonight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #5 from Jan Hubicka ---
So what modref see on calle is:
void concat5_pkg1.make_failed (struct s)
{
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #4 from Jan Hubicka ---
What happens to the by-value parameter should get merged from
concat5_pkg2.compare (s);
I will take a look now - sorry for not handling this bug earlier.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104320
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #12 from Jan Hubicka ---
Created attachment 52317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52317=edit
WIP patch
This is patch I made while working on this problem. It improves the escape
analysis of the first patch so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187
--- Comment #6 from Jan Hubicka ---
For Gimple representation __builtin_always_inline(foo(x, y))
does not make very good sense since gimple is not nested and foo may return
void so there may not be any link between call and the builtin.
I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100220
Jan Hubicka changed:
What|Removed |Added
Depends on||100314
--- Comment #3 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100314
--- Comment #4 from Jan Hubicka ---
However i is also dead at dse time:
void d (int m)
{
int k;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100314
--- Comment #3 from Jan Hubicka ---
With -O1 i get:
IPA function summary for main/7 inlinable
global time: 72.936364
self size: 6
global size: 19
min size: 16
self stack: 0
global stack:44
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 103903, which changed state.
Bug 103903 Summary: Loops handling r,g,b values are not vectorized to use power
of 2 vectors even if they can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103903
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103903
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This is another textcase comming from Firefox's LightPixel. I am not sure if
this is duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602
--- Comment #3 from Jan Hubicka ---
In addition to Skia, Firefox gfx library now contains more clang specific
vector code:
gfx/wr/swgl/src/vector_type.h
control vector implementation of some shader rountines (seen in the
rasterflood-gradient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
--- Comment #11 from Jan Hubicka ---
Aha, I did not noticed that we need special patterns (I extecpted this is
problem to solve in machine independent code). So I guess we have
1) SLP should vectorize the 3 accesses with -ffast-math to only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Jan Hubicka ---
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Clang vectorises divss in LightPixel while GCC does not (at -O3). This seems
to account for 17% difference in resteflood_svg benchmark of Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103669
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103669
--- Comment #2 from Jan Hubicka ---
Created attachment 52030
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52030=edit
Patch in testing
The problem here is a mixup with do_dataflow flag which prevents the name from
being analyzed. I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103766
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103766
--- Comment #6 from Jan Hubicka ---
This is yet another stupid early exit in the propagation code (next stage1 i
guess I will want to go through them and make it more systematic - those
originate from quite early versions of modref when it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103766
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103746
Jan Hubicka changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #10 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103746
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103746
--- Comment #2 from Jan Hubicka ---
Created attachment 52013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52013=edit
Correct testcase
Oops, uploaded inrrect testcase. This should be current one.
clang accepts it
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #20 from Jan Hubicka ---
I really think with -fdelete-null-pointer-checks we should optimize away the
pointer adjustment relying on the fact that program will segfault.
I was wondering, -fdelete-null-pointer-checks currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103674
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103680
Jan Hubicka changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Hi,
with -fprofile-report is it now again possible to produce quite useful stats on
what passes misupdates profile.
I am attaching preport for FDO+LTO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Currently we disable gather on zen1/2 and enable it for zen3. This was based
on testing I did before Richard's code for open coding
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Compiling:
struct a {int a;};
struct b {int b;};
struct c : a, b {};
int
test(struct c *c)
{
struct b *b=c;
return b->b;
}
with -O2 leads to:
.t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513
--- Comment #7 from Jan Hubicka ---
OK, i suppose we do not really have interface to fold ternary expression? It
could still do useful work merging the value ranges of both arms...
I am testing the following:
gcc/ChangeLog:
2021-12-12 Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #10 from Jan Hubicka ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586644.html
improves modref so it is almost able to remove the unnecesary stores to array
descriptors. Unforutnately to elinate them one needs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
--- Comment #1 from Jan Hubicka ---
With this patch
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586644.html
we misoptimize unmodified testcase with -Os
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The following should work but we fail to name the gcda
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
When we detect load/store of NULL memory we produce:
_9 ={v} MEM[(union tree_node
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
In this testcase we have:
void foo (struct __class__STAR_p & restrict tgt)
{
struct s * ptr1;
integer(ki
: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103454
Jan Hubicka changed:
What|Removed |Added
Depends on||103585
--- Comment #2 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #22 from Jan Hubicka ---
We discussed with Richard the option to biass the IRA spilling heuristics to
spill into blocks containing calls (since they are slow anyway) bypassing some
of the guessed frequencies.
Thinking on it, perhaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #31 from Jan Hubicka ---
With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 I limited inliner to
not produce such a large function, so bumping up --param
max-inline-functions-called-once-insns will be necessary to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #20 from Jan Hubicka ---
With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no longer
need -fno-inline-functions-called-once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103636
--- Comment #4 from Jan Hubicka ---
aha, it was missunderstanding then :)
I wanted you to simply move the hunk to can_early_inline_edge_p. There is no
specific bit to check for einline being finished.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103636
--- Comment #1 from Jan Hubicka ---
I found the email here
http://patches-tcwg.linaro.org/patch/56399/
I have suggested moving the check to einline only path but the v2 version of
patch did not implemented it and later it got in with the
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Buid fails with:
during IPA pass: inline
lto1: internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #9 from Jan Hubicka ---
Hacking around the logic in ipa-sra that disables the transform and adding
-fwhole-program I get down to:
Performance counter stats for './a.out-bad3':
24,946.66 msec task-clock#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #8 from Jan Hubicka ---
Also IRA fails with
! Disqualifying parameter number 0 - Would create a possibly illegal
dereference in a caller.
! Disqualifying parameter number 3 - Would create a possibly illegal
dereference in a caller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #7 from Jan Hubicka ---
Created attachment 51952
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51952=edit
Patch to teach modref about global memory
This patch extends modref so we eliminate the dead part of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #5 from Jan Hubicka ---
Quick counting from gcov data. It is 585898984 calls and from the disassmebly
the call is 101 instructions, so it account 58589898400
The perf reports shows 69059173576 difference so at least instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #4 from Jan Hubicka ---
Created attachment 51940
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51940=edit
gcov report. perdida does have some loops in it but it seems we optimize them
out/make htem relatively cheap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #2 from Jan Hubicka ---
Doing some basic perfing shows that perdida seems to account for about 36% of
runtime of the benchmark and has interesting property that most of time it will
return without looping (and that probbly explains
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
While looking into -fno-inline-functions-called-once difference I noticed that
on zen hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #1
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
fatigue2 regresses by 35% comparing -Ofast -march=native (zen) to -Ofast
-march=native -fno-inline-functions-called once
In generall inlining functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103584
--- Comment #1 from Jan Hubicka ---
This is (probably bit preliminary) optimization in tree-ssa-structalias.c:
/* Create constraints for the builtin call T. Return true if the call
was handled, otherwise false. */
static bool
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
While looking into reasons why modref causes some code size increases I noticed
that we produce unnecessary spill on x86-64 here:
float a;
__attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #10 from Jan Hubicka ---
Thanks for looking into this. I was planning to try to contact Vladimir about
the IRA behaviour here, but there was always something else to work with higher
priority. I wonder if you could possibly attach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 96825, which changed state.
Bug 96825 Summary: [11/12 Regression] Commit r11-2645 degrades CPU2017
548.exchange2_r by 35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
Jan Hubicka changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 103409, which changed state.
Bug 103409 Summary: [12 Regression] 18% SPEC2017 WRF compile-time regression
with -O2 -flto since r12-5228-gb7a23949b0dcc4205fcc2be6b84b91441faa384d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #6 from Jan Hubicka ---
I am sorry for getting back to this again late. This stage1 we spent some time
with Martin improving the ipa-cp profile updating and looked again into the
realism of the profile. Also recently the codegen has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 103227, which changed state.
Bug 103227 Summary: [12 Regression] 58% exchange2 regression with -Ofast
-march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Looking into exchange2 performance I run benchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103432
Jan Hubicka changed:
What|Removed |Added
Summary|[12 regression] libjxl-0.5 |[11 regression] libjxl-0.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #14 from Jan Hubicka ---
Seems the performance is now better than before
https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=21683=286.407.0
Still I think I should implement the logic to stabilize the order of nodes and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103335
Bug 103335 depends on bug 103282, which changed state.
Bug 103282 Summary: New test case gcc.dg/tree-ssa/modref-dse-5.c in r12-5292
fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103282
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103282
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
|---
Keywords|wrong-code |
Known to work|11.2.0 |
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-11-26
Assignee|unassigned at gcc dot gnu.org |hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103425
--- Comment #4 from Jan Hubicka ---
In meanwhile other testers picked the revision and it seems that indeed only
benzen machine reports this (it is AMD EPYC 7702). So it looks
microarchitecture specific issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103052
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
301 - 400 of 3439 matches
Mail list logo
