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&root=gcc&view=rev
Log:
2018-12-30 Dominique d'Humieres
PR tree-optimiz
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&root=gcc&view=rev
Log:
2018-12-29 Dominique d'Humieres
PR tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
Eric Gallager changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned a
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 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81693
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
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 accommod
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&action=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&action=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, %" S
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 $" S
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 lau
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 compil
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:
>
> % /opt
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 /opt/gcc/work/gcc/testsuite/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 doe
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:
> 0x1
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 testc
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&action=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&action=edit
Assemby for pr25967-1
> Please compile it with -g and provide stack backtrace.
This is what I have done
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' (x86
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
