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

[SODA Noriyuki <soda%yuruyuru.net@localhost>]

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