gcc_GAS_FLAGS: Add more gcc_cv_as_flags overrides

Hi!

In a toolchain where GCC has been configured for
--target=i686-pc-linux-gnu, and where an x86_64 multilib has also been
configured, by default GCC will generate code for 32-bit mode, and for
64-bit mode only when -m64 is passed.  Per ASM_SPEC definition, the -m64
option is translated to --64 when invoking the assembler.  This is
working fine.

What however is not working fine is GCC's very own configure testing.
When using said toolchain for building on/for x86_64-linux-gnu by
configuring a native GCC build with CC='gcc -m64' CXX='g++ -m64', I'm
seeing the following happen in [GCC]/gcc/configure:

    configure:23559: checking assembler for thread-local storage support
    configure:23572: [...]/bin/as   --fatal-warnings -o conftest.o conftest.s >&5
    conftest.s: Assembler messages:
    conftest.s:5: Error: bad register name `%rax'
    [...]
    configure: failed program was
    
            .section ".tdata","awT",@progbits
    foo:    .long   25
            .text
            movq    %fs:0, %rax
    [...]
    configure:23586: result: no

In this toolchain, an unadorned invocation of as will default to 32-bit
mode, and enter 64-bit mode only when an explicit --64 is passed -- which
is not done here.

This is, from a quick glance, the "inverse" thing as has once been
discussed in <http://gcc.gnu.org/PR42345>,
<http://news.gmane.org/find-root.php?message_id=%3C20091210175824.GA32242%40lucon.org%3E>.

Wanting to use this toolchain, do I have to configure GCC pointing to an
assembler that defaults to 64-bit mode, or use something like
--with-as='as --64' (not checked whether that works), or should the GCC
configure system deduce from $CXX' -m64 that it needs to pass --64 to the
assembler (à la ASM_SPEC as indicated above), or is the following patch
the way to go, or something else?  H.J., the gnux32 change is just a
guess; please comment if that's not right.  (And, of course, this is not
a problem specific to *-*-linux*, but changing that is for another day.)

gcc/
	* acinclude.m4 (gcc_GAS_FLAGS): Add more gcc_cv_as_flags
	overrides.
	* configure: Regenerate.



Grüße,
 Thomas

On Wed, Sep 11, 2013 at 2:23 PM, Thomas Schwinge
<thomas@codesourcery.com> wrote:
> Hi!
>
> In a toolchain where GCC has been configured for
> --target=i686-pc-linux-gnu, and where an x86_64 multilib has also been
> configured, by default GCC will generate code for 32-bit mode, and for
> 64-bit mode only when -m64 is passed.  Per ASM_SPEC definition, the -m64
> option is translated to --64 when invoking the assembler.  This is
> working fine.
>
> What however is not working fine is GCC's very own configure testing.
> When using said toolchain for building on/for x86_64-linux-gnu by
> configuring a native GCC build with CC='gcc -m64' CXX='g++ -m64', I'm
> seeing the following happen in [GCC]/gcc/configure:
>
>     configure:23559: checking assembler for thread-local storage support
>     configure:23572: [...]/bin/as   --fatal-warnings -o conftest.o conftest.s >&5
>     conftest.s: Assembler messages:
>     conftest.s:5: Error: bad register name `%rax'
>     [...]
>     configure: failed program was
>
>             .section ".tdata","awT",@progbits
>     foo:    .long   25
>             .text
>             movq    %fs:0, %rax
>     [...]
>     configure:23586: result: no
>
> In this toolchain, an unadorned invocation of as will default to 32-bit
> mode, and enter 64-bit mode only when an explicit --64 is passed -- which
> is not done here.
>
> This is, from a quick glance, the "inverse" thing as has once been
> discussed in <http://gcc.gnu.org/PR42345>,
> <http://news.gmane.org/find-root.php?message_id=%3C20091210175824.GA32242%40lucon.org%3E>.
>
> Wanting to use this toolchain, do I have to configure GCC pointing to an
> assembler that defaults to 64-bit mode, or use something like
> --with-as='as --64' (not checked whether that works), or should the GCC
> configure system deduce from $CXX' -m64 that it needs to pass --64 to the
> assembler (à la ASM_SPEC as indicated above), or is the following patch
> the way to go, or something else?  H.J., the gnux32 change is just a
> guess; please comment if that's not right.  (And, of course, this is not
> a problem specific to *-*-linux*, but changing that is for another day.)
>
> gcc/
>         * acinclude.m4 (gcc_GAS_FLAGS): Add more gcc_cv_as_flags
>         overrides.
>         * configure: Regenerate.
>
> --- gcc/acinclude.m4
> +++ gcc/acinclude.m4
> @@ -444,8 +444,16 @@ AC_DEFUN([gcc_GAS_FLAGS],
>  [AC_CACHE_CHECK([assembler flags], gcc_cv_as_flags,
>  [ case "$target" in
>    i[[34567]]86-*-linux*)
> -    dnl Always pass --32 to ia32 Linux assembler.
> -    gcc_cv_as_flags="--32"
> +    dnl Override the default, which may be incompatible.
> +    gcc_cv_as_flags=--32
> +    ;;
> +  x86_64-*-linux-gnux32)
> +    dnl Override the default, which may be incompatible.
> +    gcc_cv_as_flags=--x32

I don't think it is necessary.  I configure x32 gcc with

CC="gcc -mx32" CXX="g++ -mx32" RUNTESTFLAGS=" .../configure
--with-multilib-list=m32,m64,mx32 --with-abi=mx32

There is no difference in as/ld features between x32 and x86-64.

> +    ;;
> +  x86_64-*-linux*)
> +    dnl Override the default, which may be incompatible.
> +    gcc_cv_as_flags=--64
>      ;;
>    powerpc*-*-darwin*)
>      dnl Always pass -arch ppc to assembler.
>
>

Hi!

On Wed, 11 Sep 2013 14:53:58 -0700, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Wed, Sep 11, 2013 at 2:23 PM, Thomas Schwinge
> <thomas@codesourcery.com> wrote:
> > --- gcc/acinclude.m4
> > +++ gcc/acinclude.m4
> > @@ -444,8 +444,16 @@ AC_DEFUN([gcc_GAS_FLAGS],
> >  [AC_CACHE_CHECK([assembler flags], gcc_cv_as_flags,
> >  [ case "$target" in
> >    i[[34567]]86-*-linux*)
> > -    dnl Always pass --32 to ia32 Linux assembler.
> > -    gcc_cv_as_flags="--32"
> > +    dnl Override the default, which may be incompatible.
> > +    gcc_cv_as_flags=--32
> > +    ;;
> > +  x86_64-*-linux-gnux32)
> > +    dnl Override the default, which may be incompatible.
> > +    gcc_cv_as_flags=--x32
> 
> I don't think it is necessary.  I configure x32 gcc with
> 
> CC="gcc -mx32" CXX="g++ -mx32" RUNTESTFLAGS=" .../configure
> --with-multilib-list=m32,m64,mx32 --with-abi=mx32
> 
> There is no difference in as/ld features between x32 and x86-64.

Ah, OK, I thought there was because of the --x32 option being available.
However, if the x86_64 change is approved, I'd suggest to add it anyway,
both for documentation purposes (so that nobody wonders why it is not
handled here), and for consistency (because ASM_SPEC is also handling it
separately).

> > +    ;;
> > +  x86_64-*-linux*)
> > +    dnl Override the default, which may be incompatible.
> > +    gcc_cv_as_flags=--64
> >      ;;


Grüße,
 Thomas

On Wed, 11 Sep 2013, Thomas Schwinge wrote:

>     configure:23559: checking assembler for thread-local storage support

I don't expect anyone to work on this, but such a configure test is silly 
- it's a test where a failure is more likely to indicate the test is buggy 
than that the feature tested for is actually missing.  I think each GCC 
version should have a minimum version of GNU binutils, to be used except 
for a whitelist of targets where some other assembler/linker are known to 
be supported, and should check the binutils version number (unless 
configured for one of the special targets not to use GNU binutils) and 
fail if it's too old, but not check for assembler or linker features in 
cases where the binutils version requirement means they can be assumed.  
(If the relevant conditional code in GCC wouldn't be used anyway for the 
proprietary Unix targets with non-GNU system assembler/linker, it can be 
made unconditional.)

So only targets where TLS support was a recent addition to the GNU 
assembler, or those supporting a non-GNU assembler where TLS may or may 
not be supported, would need such a test at all.