public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Regarding : gcc emitting "movaps" to unaligned memory
@ 2004-06-01 10:28 Vivek Raheja
2004-06-07 14:58 ` Matthias Drochner
0 siblings, 1 reply; 2+ messages in thread
From: Vivek Raheja @ 2004-06-01 10:28 UTC (permalink / raw)
To: pinskia, M.Drochner; +Cc: gcc-bugs, vivek
Hi,
While porting my 64bit application on opteron amd64,
I am facing issues in "printf/vprintf/ vsprintf calls".
We are using libc-2.3.2.so . Please let me know in case
there are some known rpm/fix/workaround related to this.
On further investigation I realized that it is related
with
[Bug c/14321] New: gcc emitting "movaps" to unaligned memory
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The "movaps" needs 16-byte aligned memory locations, which is not
ensured (only 8-byte, appearently). This leads to occasional GPFs,
sepending on the initial stack pointer.
In my case also the MOVAPS is not 16byte aligned.
+++++++++++++++++++++++++++++++++++++++++++++++++++,
Please let me know in case we have already fixed this issue. Or I need
to open a new bug pcr. Or there is any compiler option which I need to set.
Thanks in advance.
->/etc> cat redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon)
In printf I receive a SIGSEGV, while I use
a formated string as:
printf("\n: double %23.16f", *(float *)abc); or with
printf("\n: double %23.16g", *(double *)abc); or with
Program received signal SIGSEGV, Segmentation fault.
0x0000002a95948d61 in printf () from /lib64/tls/libc.so.6
<printf+0>: sub $0xd8,%rsp
<printf+7>: movzbl %al,%r10d
<printf+11>: mov %rcx,0x38(%rsp,1)
<printf+16>: lea 0xe0(%rsp,1),%rcx
<printf+24>: mov %r8,0x40(%rsp,1)
<printf+29>: mov %rcx,0x8(%rsp,1)
<printf+34>: mov 2018279(%rip),%rcx
<printf+41>: mov %r9,0x48(%rsp,1)
<printf+46>: lea 64(%rip),%r8
<printf+53>: lea 0x0(,%r10,4),%r9
<printf+61>: mov %rsi,0x28(%rsp,1)
<printf+66>: sub %r9,%r8
<printf+69>: lea 0xcf(%rsp,1),%rsi
<printf+77>: mov %rdx,0x30(%rsp,1)
<printf+82>: jmpq *%r8d
<printf+85>: movaps %xmm7,0xfffffffffffffff1(%rsi)
<printf+89>: movaps %xmm6,0xffffffffffffffe1(%rsi)
printf+93>: movaps %xmm5,0xffffffffffffffd1(%rsi)
<printf+97>: movaps %xmm4,0xffffffffffffffc1(%rsi)
<printf+101>: movaps %xmm3,0xffffffffffffffb1(%rsi)
<printf+105>: movaps %xmm2,0xffffffffffffffa1(%rsi)
<printf+109>: movaps %xmm1,0xffffffffffffff91(%rsi)
<printf+113>: movaps %xmm0,0xffffffffffffff81(%rsi) <---- SIGSEGV position
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Regarding : gcc emitting "movaps" to unaligned memory
2004-06-01 10:28 Regarding : gcc emitting "movaps" to unaligned memory Vivek Raheja
@ 2004-06-07 14:58 ` Matthias Drochner
0 siblings, 0 replies; 2+ messages in thread
From: Matthias Drochner @ 2004-06-07 14:58 UTC (permalink / raw)
To: Vivek Raheja; +Cc: pinskia, gcc-bugs, vivek
vivek@cadence.com said:
> While porting my 64bit application on opteron amd64,
> I am facing issues in "printf/vprintf/ vsprintf calls".
Yep - this looks a lot the problem I had.
In my case (NetBSD) the culprit was the OS code which
sets up the stacks during thread creation and signal
handler invocation -- it got it wrong. (One has to think
twice if the user code is jumped to through a fake function
call return...)
> We are using libc-2.3.2.so
Sorry, I don't follow glibc development. Are there threads
involved or other userland scheduling things as setcontext()?
(Btw, there are still alignment issues in gcc-3.4 which show up
with Ada. Was reported by John R. Shannon in the gcc mailing
list.)
best regards
Matthias
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-06-07 14:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-01 10:28 Regarding : gcc emitting "movaps" to unaligned memory Vivek Raheja
2004-06-07 14:58 ` Matthias Drochner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).