pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/47906: lang/g95: SEGV occurs when stack address is not aligned 8 bytes at main().



The following reply was made to PR pkg/47906; it has been noted by GNATS.

From: SODA Noriyuki <soda%yuruyuru.net@localhost>
To: gnats-bugs%NetBSD.org@localhost, Joerg Sonnenberger 
<joerg%britannica.bec.de@localhost>
Cc: wennmach%NetBSD.org@localhost,
    gnats-admin%netbsd.org@localhost,
    pkgsrc-bugs%netbsd.org@localhost,
    nonakap%gmail.com@localhost
Subject: Re: pkg/47906: lang/g95: SEGV occurs when stack address is not
 aligned 8 bytes at main().
Date: Wed, 10 Jul 2013 18:41:37 +0900

 >>>>> On Tue,  9 Jul 2013 13:05:01 +0000 (UTC),
       Joerg Sonnenberger <joerg%britannica.bec.de@localhost> said:
 
 >> >  > >Description:
 >> >  > If the stack address is not aligned on 8 bytes, it is adjusted to 8 
 >> > bytes aligned at main().
 >> >  > If stack address is adjusted, to get from the stack address the wrong 
 >> > return address, SEGV occurs.
 >> >
 >> >  What happens if the whole section is dropped, i.e. the stack pointer
 >> >  isn't adjusted in main at all? It shouldn't be needed at nothing on x86
 >> >  requires 64bit alignment.
 >> 
 >> for speed.
 >> 
 >> g95-0.93/libf95.a-0.93/runtime/main.c:
 >> 
 >> 46 int main(int argc, char *argv[]) {
 >> 47
 >> 48 /* Sometimes on x86, the stack isn't aligned to an 8-byte boundary,
 >> 49  * which kills performance associated with doubles.  Align if
 >> 50  * unaligned. */
 >> 51
 >> 52 #if HAVE_REAL_10 == 1 || HAVE_REAL_10 == 2
 >> 53     asm("mov %%esp, %%eax\n"
 >> 54         "and $0x04, %%eax\n"
 >> 55         "sub %%eax, %%esp\n" : : : "%eax");
 >> 56 #endif
  
 >  I don't beliebe that comment is true, I was more asking whether it just
 >  works...
 
 The comment is true, at least at once.
 
 I remember some x86 program which heavily used double significantly
 ran slower occasionally.  And the reason of the slowness was that
 the program was accessing double on its stack, and the stack was not
 always 8 byte aligned.  It ran slowly, when the stack was not 8 byte
 aligned due to some environment variable settings.
 
 That was more than 10 years ago.
 But it's better to keep the optimization, unless you are 100% sure
 that the optimization is really useless on all modern CPUs.
 
 BTW, modern x86 CPUs still require some alignment restriction
 for efficiency about SSE2 and AVX instructions.
 See page 107 of http://www.agner.org/optimize/optimizing_cpp.pdf
 for example.
 16byte or 32byte alignment is better for those instructions, though.
 -- 
 soda
 


Home | Main Index | Thread Index | Old Index