This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.4.0-rc1 available
H.J. Lu wrote:
> On Wed, Apr 15, 2009 at 6:49 AM, Dave Korn
> <dave.korn.cygwin@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)?
cheers,
DaveK