https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #13 from Martin Jambor ---
I think that you want to disable inlining in the case when the callee has a
formal parameter which is a VLA (as opposed to a VLA actual argument of a
call), probably in inline_forbidden_p. When just the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #6 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #5)
> That could perhaps work for the #c0 testcase where the function actually has
> a non-VL parameter and so garbage in garbage out.
> But would that work also for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #4 from Martin Jambor ---
With the patch from comment #3, the following sequence with the problematic
call:
x.1_26 = __builtin_alloca_with_align (_24, 8);
g (WITH_SIZE_EXPR <*x.1_26, _22>, WITH_SIZE_EXPR <*x.1_26, _22>);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #3 from Martin Jambor ---
Looking at how expr.c deals with WITH_SIZE_EXPR, perhaps we should do something
like the following:
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index a710fa59027..cdabeb6bafd 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #9 from Martin Jambor ---
I will benchmark the patch later this week, just so that we know, but I agree
that reverting the patch and applying it again at the beginning of stage1 is
probably the best.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: ubizjak at gmail dot com
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
On AMD Zen2 CPUs, 519.lbm_r is 62.12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90234, which changed state.
Bug 90234 Summary: 503.bwaves_r is 6% slower on Zen1/Zen2 CPUs at -Ofast with
native march/mtune than with generic ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94375, which changed state.
Bug 94375 Summary: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast
-march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 94375, which changed state.
Bug 94375 Summary: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast
-march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94400, which changed state.
Bug 94400 Summary: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97588
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #10 from Martin Jambor ---
OK, adding an additional check whether tree_could_trap_p is of course easy.
I'll wait a little while if the discussion about get_ref_base_and_extent
perhaps leads to a different solution but if not, I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #7 from Martin Jambor ---
Even our constant folding thinks the unsigned expression wraps around. If I
tell SRA to fold the expression if the base is a string_cst, the invalid
dereference is avoided. My experiment was (I am not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #5 from Martin Jambor ---
Right, the issue is that SRA depends on get_ref_base_and_extent to figure out
what is being accessed (and so whether it is safe) and that function believes
the load is safely from within the array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #3 from Martin Jambor ---
So SRA sees statements:
n[0][2] = "\t\x02\b";
and later
_11 = n[0][3][4294967294];
The latter loads a scalar sitting inside what the store above
initialized (according to get_ref_base_and_extent) and so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
--- Comment #4 from Martin Jambor ---
Actually no, that would be papering over a bigger problem. After looking at
the issue a bit more, I proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563962.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
Martin Jambor changed:
What|Removed |Added
Component|ipa |c++
--- Comment #3 from Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
--- Comment #2 from Martin Jambor ---
That cannot be the problem. IPA-SRA re-creates the call statements
and builds them with gimple_build_call_vec (callee_decl, vargs); where
calle_decl is the new function which has had its type adjusted and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98690
--- Comment #3 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563790.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
--- Comment #3 from Martin Jambor ---
Here is what happens. An IPA-CP clone for a particular
devirtualziation context is created but all devirtualziations based on
it are speculative. Then the clone is inlined at one of its call
sites and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98222
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'll have a look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58243
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jamborm at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Bug 45375 depends on bug 45791, which changed state.
Bug 45791 Summary: Missed devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50430
--- Comment #5 from Martin Jambor ---
Am I correct thinking that this has been addressed (long time ago)?
The entire optimized dump of the testcase from comment #3 is now the
following, so no missed devirtualization there:
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79966
Martin Jambor changed:
What|Removed |Added
Summary|[9/10/11 Regression] run|[9/10/11 Regression] Test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79966
--- Comment #13 from Martin Jambor ---
I can confirm this, even on current trunk.
The reason is that runtptests/3 -> tp_sum/5 is not inlined because it
exceeds max-inline-insns-auto. I have to set the param to 43 - the
default is 15 - for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 97816, which changed state.
Bug 97816 Summary: [11 Regression] ICE in good_cloning_opportunity_p, at
ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94406, which changed state.
Bug 94406 Summary: 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with
-Ofast -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #38 from Martin Jambor ---
*** Bug 97980 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97980
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816
--- Comment #5 from Martin Jambor ---
As noted in the commit message above, the ICE will go away but the underlying
issue stays so please keep this opened until I fix it, hopefully no later than
next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816
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=97695
--- Comment #7 from Martin Jambor ---
(In reply to Jan Hubicka from comment #5)
> I see you have patch, too :)
> However we do not want to copy clone info to every inline clone (since
> the body is materialized just once). The problem is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97695
--- Comment #4 from Martin Jambor ---
And the reason is not copying tree_map in cgraph_node::create_clone
(when called from clone_inlined_nodes). The following should fix it.
In theory we need a mechanism for create_virtual_clone to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97695
--- Comment #3 from Martin Jambor ---
It is a clone materialization problem. IPA-CP clones f.part.0 twice and the
second time tree_function_versioning receives NULL tree_map.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
Martin Jambor changed:
What|Removed |Added
Component|ipa |tree-optimization
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
--- Comment #6 from Martin Jambor ---
I have posted the patch to the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556399.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
--- Comment #5 from Martin Jambor ---
And indeed the following avoids the issue:
diff --git a/gcc/tree-complex.c b/gcc/tree-complex.c
index 2e54bbb917c..71ad7c18523 100644
--- a/gcc/tree-complex.c
+++ b/gcc/tree-complex.c
@@ -570,8 +570,10 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
--- Comment #4 from Martin Jambor ---
Looking at Martin's reduced testcase
(In reply to Richard Biener from comment #2)
> Confirmed with -fwhole-program -O3 IPA SRA messes things up here cloning
> wrong
> and producing the strange
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
--- Comment #10 from Martin Jambor ---
Is this bug still "WAITING" for something?
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #18 from Martin Jambor ---
I proposed the patch on the mailing list (I guess I should put Martin's name at
least to the testsuite ChangeLog and probably to both):
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555284.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #15 from Martin Jambor ---
so after Martin asked some good questions, it turns out this should probably be
avoided in ipa-prop, after all, as with, for example (untested):
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #14 from Martin Jambor ---
I can confirm the analysis, except that I see the edge we're trying to
add to the heap as already inlined (as a speculative edge it got
inlined even its caller was). Also just not adding an edge with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96820
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #6 from Martin Jambor ---
I proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552900.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96820
--- Comment #5 from Martin Jambor ---
(In reply to Chengnian Sun from comment #1)
> Not sure if this is a dup to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730
No, this time it's build_user_friendly_ref_for_offset turning a nonsensical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96730
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
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=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=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=27.100.0;
I wonder whether we should keep this bug opened, the benchmark seems
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=93385
Martin Jambor changed:
What|Removed |Added
CC||suochenyao at 163 dot com
--- Comment
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=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
--- 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
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=96040
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
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
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
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.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/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=edit
Todays WIP patch
This is my todays (still very much) WIP patch.
- It marks statements which should not be copied
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"
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 ();
501 - 600 of 2240 matches
Mail list logo
