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).