https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #43 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Nov 11 17:44:43 2018
New Revision: 266015
URL: https://gcc.gnu.org/viewcvs?rev=266015=gcc=rev
Log:
Backport from mainline
2018-11-04 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #42 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Nov 11 17:36:23 2018
New Revision: 266014
URL: https://gcc.gnu.org/viewcvs?rev=266014=gcc=rev
Log:
Backport from mainline
2018-11-04 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #41 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Nov 4 19:22:50 2018
New Revision: 265776
URL: https://gcc.gnu.org/viewcvs?rev=265776=gcc=rev
Log:
PR middle-end/58372
* cfgexpand.c (pass_expand::execute):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #40 from Uroš Bizjak ---
(In reply to Terry Guo from comment #39)
> (In reply to Uroš Bizjak from comment #38)
> > (In reply to Terry Guo from comment #36)
> >
> > > OK. Do it right now.
> >
> > I think that latest attachment is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #39 from Terry Guo ---
(In reply to Uroš Bizjak from comment #38)
> (In reply to Terry Guo from comment #36)
>
> > OK. Do it right now.
>
> I think that latest attachment is the one that should be tested.
> Functionally it is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #38 from Uroš Bizjak ---
(In reply to Terry Guo from comment #36)
> OK. Do it right now.
I think that latest attachment is the one that should be tested. Functionally
it is the same, but avoids unnecessary variable updates before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Uroš Bizjak changed:
What|Removed |Added
Attachment #44928|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #36 from Terry Guo ---
(In reply to Uroš Bizjak from comment #35)
>
> Actually, we can use crtl->stack_realign_processed to delay DRAP generation.
> The condition in the patch should be changed to:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #35 from Uroš Bizjak ---
(In reply to Terry Guo from comment #31)
> (In reply to Uroš Bizjak from comment #30)
> > (In reply to Jakub Jelinek from comment #29)
> > > > Let's ask Jakub about asan, if it is possible to move generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #34 from Terry Guo ---
(In reply to David Grayson from comment #33)
> Hello, Terry. I'd be happy to help. I hope you have access to a Linux
> computer. I've actually spent a lot of time working on build scripts for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #33 from David Grayson ---
Hello, Terry. I'd be happy to help. I hope you have access to a Linux
computer. I've actually spent a lot of time working on build scripts for
cross-compilers running on Linux and here's what I have come
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #32 from Terry Guo ---
(In reply to David Grayson from comment #27)
> Thanks to everyone who is working on this. I can confirm that the patch in
> comment #20 by Uroš Bizjak applies cleanly to GCC 7.3.0, and I successfully
> used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #31 from Terry Guo ---
(In reply to Uroš Bizjak from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > > Let's ask Jakub about asan, if it is possible to move generation of the
> > > call
> > > after the function is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #30 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #29)
> > Let's ask Jakub about asan, if it is possible to move generation of the call
> > after the function is already expanded to RTL.
>
> I'm afraid no.
Hm...
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #29 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #28)
> Let's ask Jakub about asan, if it is possible to move generation of the call
> after the function is already expanded to RTL.
I'm afraid no.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Uroš Bizjak changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #27 from David Grayson ---
Thanks to everyone who is working on this. I can confirm that the patch in
comment #20 by Uroš Bizjak applies cleanly to GCC 7.3.0, and I successfully
used the resulting toolchain targeting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #26 from Terry Guo ---
Hi Uroš:
I think I found why your proposed patch causes problem in Comment 23. It is all
about timing. The below code from patch is trying to set up DRAP reg in a
rather early stage when the function is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #25 from Terry Guo ---
Debugged the ICE further and found that below line in function
ix86_get_drap_rtx is causing ICE:
12050 insn = emit_insn_before (seq, NEXT_INSN (entry_of_function ()));
It is called when generating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #24 from Terry Guo ---
Created attachment 44934
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44934=edit
case to reproduce problem related to sanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #23 from Terry Guo ---
Hi Uroš:
With your fix, I identified two regressions so far: one is that we should run
the case you provided with c++ standard newer than c++11. The 'noexcept' was
introduced in c++14. Guess we need a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #22 from xuepeng guo ---
(In reply to Uroš Bizjak from comment #20)
> Created attachment 44928 [details]
> Proposed patch
>
> It turned out that functions, called directly through emit_library_call (as
> the above testcase, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #21 from xuepeng guo ---
Thanks for fix. I am glad to help to test it out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
H.J. Lu changed:
What|Removed |Added
CC||xuepeng.guo at intel dot com
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Uroš Bizjak changed:
What|Removed |Added
Target|mingw32-sjlj|x86 sjlj
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #17 from Uroš Bizjak ---
(In reply to Kai Tietz from comment #16)
> > If you want to experiment, try the following patch:
> >
> > Index: config/i386/mingw32.h
> > ===
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #16 from Kai Tietz ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to David Grayson from comment #14)
>
> > Does anyone have an idea of how to fix this bug for real? What values
> > should crtl->preferred_stack_boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #15 from Uroš Bizjak ---
(In reply to David Grayson from comment #14)
> Does anyone have an idea of how to fix this bug for real? What values
> should crtl->preferred_stack_boundary crtl->stack_alignment_needed really
> have on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
David Grayson changed:
What|Removed |Added
CC||davidegrayson at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
martchus at gmx dot net changed:
What|Removed |Added
CC||martchus at gmx dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Bitterblue changed:
What|Removed |Added
CC||cantabile.desu at gmail dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #11 from sonoro at telefonica dot net ---
So it seems you solved the problem in sjlj
Are you going to push it?
Thanks
victor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
My understanding is stack realignment doesn't work on Windows.
There was a attempt to do it at a time. But we didn't know
enough about Windows to do it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org ---
Well, for x64 we can't realign stack due issue about prologue layout enforced
by SEH stuff.
For x86 I see actually no good reason why this shouldn't work. I checked
generated assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #5 from sonoro at telefonica dot net ---
Is there anything else I must provide in order to solve this issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #6 from sonoro at telefonica dot net ---
(In reply to Paolo Carlini from comment #1)
In any case a self contained reproducer is a requirement. Please do your
best to reduce it to a manageable size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com ---
Please, if you really want to see progress on this issue, do your best to
reduce the reproducer to a manageable size, normally less than, say, 100 lines
are more than enough.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #3 from sonoro at telefonica dot net ---
Created attachment 30808
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30808action=edit
ii file compressed with rar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
--- Comment #4 from sonoro at telefonica dot net ---
this are the compiler flags for the project
CXX_FLAGS = -save-temps -msse -msse -mfpmath=sse -msse2 -std=c++11
-mstackrealign -O2 -g -DNDEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||mingw32-sjlj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
44 matches
Mail list logo
