[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

2020-11-06 Thread law at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED
 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
Should be fixed on trunk now

[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

2020-11-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:659ba632e440280e8d61e1ae870e917765db5ae5

commit r11-4806-g659ba632e440280e8d61e1ae870e917765db5ae5
Author: Jeff Law 
Date:   Fri Nov 6 17:38:00 2020 -0500

Fix stack pointer handling in ms_hook_prologue functions for i386 target.

gcc/
PR target/91489
* config/i386/i386.md (simple_return): Also check
for ms_hook_prologue function attribute.
* config/i386/i386.c (ix86_can_use_return_insn_p):
Also check for ms_hook_prologue function attribute.
* config/i386/i386-protos.h (ix86_function_ms_hook_prologue):
Declare.

gcc/testsuite
PR target/91489
* gcc.target/i386/ms_hook_prologue.c: Expand testcase
to reproduce PR target/91489 issue.

[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

2020-02-10 Thread gofmanp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489

--- Comment #4 from Paul Gofman  ---
I suppose I figured a better way to fix this and sent the patch to the mailing
list: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00554.html

[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

2020-01-29 Thread gofmanp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489

--- Comment #3 from Paul Gofman  ---
(In reply to Martin Liška from comment #2)
> @Paul: Can you please send the patch to GCC patches mailing list?

I think I found later that unfortunately this patch is not quite correct: the
stack was still wrong under certain conditions, IIRC at least (but probably not
only) if __attribute__((optimize("omit-frame-pointer"))) is additionally used
on function. I thought that such sort of fix looks more like a workaround
anyway. Probably a better fix would be to either track stack pointer properly
upon generating ms hook prologue or maybe enforce some function attributes if
ms_hook_prologue is used, but that time I did not dig gcc code deep enough to
find how to do that right.

I am currently away for about 2 weeks, after that I could get back to it and at
least update the test to indicate how it is still wrong with such a patch.

[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

2020-01-29 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
@Paul: Can you please send the patch to GCC patches mailing list?

[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

2019-08-21 Thread gofmanp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489

--- Comment #1 from Paul Gofman  ---
Created attachment 46739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46739&action=edit
Pop frame pointer in function label if it is not needed instead of prologue for
"ms_hook_prologue" functions on i386

The attached patch fixes the issue for me. I am not sure if that is the best
way to fix it though.