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 #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
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=95970
Martin Jambor changed:
What|Removed |Added
Last reconfirmed||2020-06-29
Ever confirmed|0
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=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=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 #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=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=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=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=95343
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
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=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:
>
>
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=94856
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
--- 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=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=94482
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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 #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 #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=93621
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
--- 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 #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=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=94434
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=92550
Martin Jambor changed:
What|Removed |Added
Component|ipa |target
--- Comment #4 from Martin Jambor
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=94434
Martin Jambor changed:
What|Removed |Added
Attachment #48248|0 |1
is obsolete|
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=94482
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
||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
--- 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.
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=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 #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
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 #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.
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 #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 #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
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=92676
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=94364
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
--- 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=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
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=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).
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=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=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=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=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=94410
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
: 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=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
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 #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:
: 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=90234
Martin Jambor changed:
What|Removed |Added
Summary|503.bwaves_r is 6% slower |503.bwaves_r is 6% slower
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
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=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
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=90056
--- Comment #3 from Martin Jambor ---
So replaced with more specific bugs for newer hardware: PR94373 and PR94375.
: 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
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=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|---
: 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
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
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
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
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=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
||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=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
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #46 from Martin Jambor ---
(In reply to Jason Merrill from comment #45)
>
> We SRA a bool field into a QItype variable and then think we need a VCE to
> get back to bool. Could the SRA variable have type bool?
A semi-wild guess, wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84490
--- Comment #13 from Martin Jambor ---
(In reply to Richard Biener from comment #12)
> Wonder if we can have an update on this?
TL;DR: there still seems to be a regression, but smaller and difficult to pin
down.
The benchmark often goes up and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93707
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93707
--- Comment #3 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01321.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776
Bug 93776 depends on bug 93667, which changed state.
Bug 93667 Summary: [10 regression] ICE in esra with nested
[[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711
Bug 93711 depends on bug 93667, which changed state.
Bug 93667 Summary: [10 regression] ICE in esra with nested
[[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776
--- Comment #4 from Martin Jambor ---
I proposed a fix on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01054.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
--- Comment #6 from Martin Jambor ---
I proposed a fix on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01053.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93203
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776
--- Comment #3 from Martin Jambor ---
x86_64 testcase (reproduces at -O1):
struct empty {};
struct s { int i; };
struct z
{
int j;
struct empty e;
struct s s;
};
void bar (struct z);
void foo (void)
{
struct z z, z2;
z2.s.i = 1;
z
601 - 700 of 2265 matches
Mail list logo
