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=93621
--- Comment #19 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:7123347c8b44571811c4b58506b06fb09969bccb
commit r10-7760-g7123347c8b44571811c4b58506b06fb09969bccb
Author: Martin Jambor
Date:
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=93621
--- Comment #17 from Martin Jambor ---
Created attachment 48208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48208=edit
WIP patch
This is the current version of my patch to fix this. I think that at
least for the purposes of JIT I need
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #12 from Jan Hubicka ---
> 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 adjusted decl but we
still keep the adjustments and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> The offending commit eventually changed when/how many times
> disable_insertion_hook () is called. So that maybe points to the real cause.
Eventually that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #10 from Richard Biener ---
The offending commit eventually changed when/how many times
disable_insertion_hook () is called. So that maybe points to the real cause.
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=93621
Martin Liška changed:
What|Removed |Added
Known to work|9.2.0 |9.3.0
Known to fail|9.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
Martin Liška changed:
What|Removed |Added
Known to fail||10.0, 9.3.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #5 from Martin Liška ---
Yes, I can confirm it still ICEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
--- Comment #4 from Arseny Solokha ---
(In reply to Jan Hubicka from comment #3)
> The testcase builds for me now
It still ICEs for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
19 matches
Mail list logo
