https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
Dominique d'Humieres changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #33 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Dec 30 10:51:49 2018
New Revision: 267474
URL: https://gcc.gnu.org/viewcvs?rev=267474=gcc=rev
Log:
2018-12-30 Dominique d'Humieres
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #32 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Dec 29 15:05:55 2018
New Revision: 267462
URL: https://gcc.gnu.org/viewcvs?rev=267462=gcc=rev
Log:
2018-12-29 Dominique d'Humieres
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
Eric Gallager changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #30 from Dominique d'Humieres ---
I have submitted a patch some time ago at
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00939.html
Mike asked for some changes and I got distracted before being able to fulfill
the requests.
I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #29 from H.J. Lu ---
(In reply to Eric Gallager from comment #28)
> (In reply to H.J. Lu from comment #27)
> > By definition of the "naked" attribute, the program is responsible
> > to manage stack. Since simulated interrupt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #27 from H.J. Lu ---
By definition of the "naked" attribute, the program is responsible
to manage stack. Since simulated interrupt functions don't follow
the normal software calling convention and there is no attempt
made to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #26 from H.J. Lu ---
Created attachment 42120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42120=edit
Another testcase to show the issue on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #25 from H.J. Lu ---
Created attachment 42119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42119=edit
A testcase to show the issue on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #24 from Dominique d'Humieres ---
> Does gcc.dg/torture/pr25967-2.c pass for both -m32 and -m64?
Nope!
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-2.c
-g
% lldb ./a.out
(lldb) target create "./a.out"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #23 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #22)
> The test succeeds with -m32 (but fails with -m64) with the following change
>
> + /* Align exception handler stack to 16 bytes. */
> + asm ("and $-8, %"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #22 from Dominique d'Humieres ---
The test succeeds with -m32 (but fails with -m64) with the following change
+ /* Align exception handler stack to 16 bytes. */
+ asm ("and$-8, %" STACK_POINTER ";\
+push $"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #21 from Dominique d'Humieres ---
% /opt/gcc/gcc8w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr25967-1.c
-m32 -g
% lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (i386).
(lldb) run
Process 25578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #20 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #19)
> > Do you know why it fails in 32-bit mode?
>
> Nope! Are you sure that %esp is the stack in 32 bit mode?
Yes, %esp is correct for 32-bit mode. Please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #19 from Dominique d'Humieres ---
> Do you know why it fails in 32-bit mode?
Nope! Are you sure that %esp is the stack in 32 bit mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #18 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #17)
> > I updated it again. If it still doesn't work, please show me what
> > you applied.
>
> The test now pass in 64 bit mode, but not in 32 bit one:
>
> %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #17 from Dominique d'Humieres ---
> I updated it again. If it still doesn't work, please show me what
> you applied.
The test now pass in 64 bit mode, but not in 32 bit one:
% /opt/gcc/gcc8w/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #16 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #14)
> > Please try my new patch.
>
> AFAICT it is not different from the one I have already applied (why the
> duplications?).
I updated it again. If it still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
H.J. Lu changed:
What|Removed |Added
Attachment #42109|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #14 from Dominique d'Humieres ---
> Please try my new patch.
AFAICT it is not different from the one I have already applied (why the
duplications?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #13 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #11)
> > Where is
> >
> > and$0xfff0,%rsp
>
> I cannot find it!-(
>
> > my patch added?
>
> Yes.
Please try my new patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
H.J. Lu changed:
What|Removed |Added
Attachment #41917|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #11 from Dominique d'Humieres ---
> Where is
>
> and$0xfff0,%rsp
I cannot find it!-(
> my patch added?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #10 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #9)
> (lldb) b main
> Breakpoint 2: where = a.out`main at pr25967-1.c:55, address =
> 0x00010f4f
> (lldb) disass -a 0x00010f4f
> a.out`main:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #9 from Dominique d'Humieres ---
(lldb) b main
Breakpoint 2: where = a.out`main at pr25967-1.c:55, address =
0x00010f4f
(lldb) disass -a 0x00010f4f
a.out`main:
0x10f4f <+0>: pushq $0x12345675 ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #8 from H.J. Lu ---
(In reply to Dominique d'Humieres from comment #7)
> > Created attachment 41917 [details]
> > A patch
> >
> > Please try this.
>
> Sorry it does not work:
>
Please compile gcc.dg/torture/pr25967-1.c with -g and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #7 from Dominique d'Humieres ---
> Created attachment 41917 [details]
> A patch
>
> Please try this.
Sorry it does not work:
=== gcc Summary for unix/-m64 ===
# of unexpected failures14
# of unresolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #6 from H.J. Lu ---
Created attachment 41917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41917=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #5 from Uroš Bizjak ---
Just guessing, but maybe _exit doesn't like misaligned stack on MacOS. We may
need to emit some dummy pushes to keep it aligned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #4 from Dominique d'Humieres ---
Created attachment 41915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41915=edit
Assemby for pr25967-1
> Please compile it with -g and provide stack backtrace.
This is what I have done. bt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #3 from H.J. Lu ---
Please compile it with -g and provide stack backtrace.
Please also provide the assembly codes of fn and main.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
--- Comment #2 from Dominique d'Humieres ---
> Please show gdb backtrace as well as disassemble fn/main.
The best I can do without further directive
Current executable set to './a.out' (x86_64).
(lldb) run
Process 25263 launched: './a.out'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
34 matches
Mail list logo
