GCC 4.4.0-rc1 available

GCC 4.4.0-rc1 available

[Jakub Jelinek]

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.

Re: GCC 4.4.0-rc1 available

[Dave Korn]

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.

  I configured using "--with-arch=i686 --with-tune=generic"; was this wrong?

  Does anyone else see this on any other x86 targets?

    cheers,
      DaveK

-- 
Reading specs from /gnu/gcc/releases/4.4.0rc1/gcc/specs
Target: i686-pc-cygwin
Configured with: /gnu/gcc/releases/4.4.0rc1/gcc-4.4.0-RC-20090414/configure
--prefix=/usr --datadir=/usr/share --infodir=/usr/share/info
--mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime-libs --with-slibdir=/usr/bin
--libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc
--disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2
--disable-sjlj-exceptions --disable-symvers --disable-libjava
--program-suffix=-4 --enable-libgomp --enable-libssp --disable-libada
--enable-threads=posix --with-arch=i686 --with-tune=generic CC=gcc-4 CXX=g++-4
CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4
--with-ecj-jar=/usr/share/java/ecj.jar LD=/opt/gcc-tools/bin/ld.exe
LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe AS=/opt/gcc-tools/bin/as.exe
AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe
--enable-languages=c,c++,fortran,objc,obj-c++
Thread model: posix
gcc version 4.4.0 20090414 (prerelease) (GCC)

Re: GCC 4.4.0-rc1 available

[H.J. Lu]

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.

Thanks.

-- 
H.J.

Re: GCC 4.4.0-rc1 available

[Dave Korn]

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

Re: GCC 4.4.0-rc1 available

[Dave Korn]

H.J. Lu wrote:
> On Wed, Apr 15, 2009 at 7:11 AM, Dave Korn

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

  Can you tell me whether Linux treats COMMON as a separate section with its
own alignment, or otherwise takes steps to ensure it has a base alignment that
the compiler can assume?  Otherwise I expect I need to look at the cygwin
definitions of the ASM_OUTPUT_COMMON* macros.

    cheers,
      DaveK

Re: GCC 4.4.0-rc1 available

[H.J. Lu]

On Wed, Apr 15, 2009 at 7:11 AM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> 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)?
>

It does look like a Cygwin specific issue.



-- 
H.J.

Re: GCC 4.4.0-rc1 available

[Jakub Jelinek]

On Wed, Apr 15, 2009 at 03:27:01PM +0100, Dave Korn wrote:
> > It does look like a Cygwin specific issue.
> 
>   Can you tell me whether Linux treats COMMON as a separate section with its
> own alignment, or otherwise takes steps to ensure it has a base alignment that
> the compiler can assume?  Otherwise I expect I need to look at the cygwin
> definitions of the ASM_OUTPUT_COMMON* macros.

In ELF each STT_COMMON symbol has both size (st_size) and alignment
(st_value) and the linker is of course required to lay out all the common
symbols in a way that their alignment requirements are satisfied.

	Jakub

Re: GCC 4.4.0-rc1 available

[Dave Korn]

Jakub Jelinek wrote:
> On Wed, Apr 15, 2009 at 03:27:01PM +0100, Dave Korn wrote:
>>> It does look like a Cygwin specific issue.
>>   Can you tell me whether Linux treats COMMON as a separate section with its
>> own alignment, or otherwise takes steps to ensure it has a base alignment that
>> the compiler can assume?  Otherwise I expect I need to look at the cygwin
>> definitions of the ASM_OUTPUT_COMMON* macros.
> 
> In ELF each STT_COMMON symbol has both size (st_size) and alignment
> (st_value) and the linker is of course required to lay out all the common
> symbols in a way that their alignment requirements are satisfied.

  Ah, thanks.  I think probably PE doesn't support that and will need explicit
.align pseudo-ops inserted in the assembly.  I'm AFK for a few hours now but
will pursue this later tonight.

    cheers,
      DaveK

Re: GCC 4.4.0-rc1 available

[H.J. Lu]

On Wed, Apr 15, 2009 at 7:34 AM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> Jakub Jelinek wrote:
>> On Wed, Apr 15, 2009 at 03:27:01PM +0100, Dave Korn wrote:
>>>> It does look like a Cygwin specific issue.
>>>   Can you tell me whether Linux treats COMMON as a separate section with its
>>> own alignment, or otherwise takes steps to ensure it has a base alignment that
>>> the compiler can assume?  Otherwise I expect I need to look at the cygwin
>>> definitions of the ASM_OUTPUT_COMMON* macros.
>>
>> In ELF each STT_COMMON symbol has both size (st_size) and alignment
>> (st_value) and the linker is of course required to lay out all the common
>> symbols in a way that their alignment requirements are satisfied.
>
>  Ah, thanks.  I think probably PE doesn't support that and will need explicit
> .align pseudo-ops inserted in the assembly.  I'm AFK for a few hours now but
> will pursue this later tonight.
>

If your COMMON doesn't support alignment, you may need to use .bss with
.align.



-- 
H.J.

Re: GCC 4.4.0-rc1 available

[Dave Korn]

H.J. Lu wrote:
> On Wed, Apr 15, 2009 at 7:34 AM, Dave Korn
> <dave.korn.cygwin@googlemail.com> wrote:
>> Jakub Jelinek wrote:
>>> On Wed, Apr 15, 2009 at 03:27:01PM +0100, Dave Korn wrote:
>>>>> It does look like a Cygwin specific issue.
>>>>   Can you tell me whether Linux treats COMMON as a separate section with its
>>>> own alignment, or otherwise takes steps to ensure it has a base alignment that
>>>> the compiler can assume?  Otherwise I expect I need to look at the cygwin
>>>> definitions of the ASM_OUTPUT_COMMON* macros.
>>> In ELF each STT_COMMON symbol has both size (st_size) and alignment
>>> (st_value) and the linker is of course required to lay out all the common
>>> symbols in a way that their alignment requirements are satisfied.
>>  Ah, thanks.  I think probably PE doesn't support that and will need explicit
>> .align pseudo-ops inserted in the assembly.  I'm AFK for a few hours now but
>> will pursue this later tonight.
>>
> 
> If your COMMON doesn't support alignment, you may need to use .bss with
> .align.

  It does indeed look that way.  Only ELF supports COMMON symbol alignment,
and the x86 backend just disregards it: i386_pe_asm_output_aligned_decl_common
from config/i386/winnt.c ignores the alignment parameter altogether.

  That certainly means this is not a regression then.  Thanks for all the
pointers, everyone.

    cheers,
      DaveK