On Wed, Apr 15, 2009 at 7:11 AM, Dave Korn <dave.korn.cyg...@googlemail.com> wrote: > H.J. Lu wrote: >> On Wed, Apr 15, 2009 at 6:49 AM, Dave Korn >> <dave.korn.cyg...@googlemail.com> wrote: >>> Jakub Jelinek wrote: >>>> GCC 4.4.0 release candidate 1 is now available at: >>>> >>>> ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.0-RC-20090414/ >>>> >>>> Please test the tarballs there and report any problems to Bugzilla. CC >>>> me on the bugs if you believe they are regressions from previous >>>> releases severe enough that they should block the 4.4.0 release. >>> My testsuite run is still only part-way through, and I'll file PRs when >>> it's complete, but I just wanted to flag this up: I'm seeing a lot of >>> failures related to stack alignment and vectorisation. >>> >>> All the FAILs that I've examined so far turn out to be misaligned >>> addresses in SSE2 instructions resulting in SIGILL at runtime. >>> >>> For instance: gcc.dg/torture/stackalign/push-1.c compiles to have this >>> line of assembly: >>> >>> 0x004011f6 <foo+59>: movaps %xmm0,0x404024 >>> >>> I tried the same testcase with 4.3.2, and it also fails, but for a >>> different reason. The testcase uses "-mpreferred-stack-boundary=2", and >>> without that option it still fails with 4.4.0rc1 but passes with 4.3.2. >>> >> >> Gcc 4.4 tests are OK on Linux/i686. Gcc should align stack automatically. >> Please include the assembly outputs for any stack alignment related bug >> reports. > > Sure, although in this particular testcase it's not stack alignment but > .data section objects. (I think the stack alignment is probably working; > that's what causes the "fails, but for a different reason" with 4.3.2, it's a > failure in main() where the stack isn't aligned. This doesn't happen with > 4.4.0, but I still get the unaligned access). > > The push-1.c testcase has: > > __m128 r; > > void > __attribute__ ((noinline)) > foo (__m128 x, __m128 y ,__m128 z ,__m128 a, int size) > { > aligned i; > > if (size != 5 || check_int (&i, __alignof__(i)) != i) > abort (); > > r = a; > } > > and it fails on the assignment "r = a;" because r is unaligned (0x404024); in > the assembly source, it is simply defined as > > .comm _r, 16 # 16 > > so maybe the problem is in the Cygwin linker script? Is the COMMON section > supposed to be aligned? In Cygwin, it just gets appended into .bss, like so: > > .bss 0x00404024 0x0 > /gnu/gcc/releases/4.4.0rc1/gcc/libgcc.a(_ctors.o) > .bss 0x00404024 0x0 /gnu/gcc/releases/4.4.0rc1/gcc/crtend.o > *(COMMON) > COMMON 0x00404024 0x10 > /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc86uXzW.o > 0x00404024 _r > COMMON 0x00404034 0x20 > /gnu/gcc/releases/4.4.0rc1/gcc/libgcc.a(_ctors.o) > 0x00404054 __bss_end__ = . > > Does there need to be an alignment specified for COMMON (and/or other > sections)? >
It does look like a Cygwin specific issue. -- H.J.
