can't build x86-32 libc on x86-64 with mainline binutils

can't build x86-32 libc on x86-64 with mainline binutils

[Alexandre Oliva]

Am I the only one having trouble assembling
glibc/sysdeps/i386/fpu/e_atanh.S with -m32 with binutils mainline
toplevel-bootstrapped along with GCC trunk on x86_64?  I've hit this
for several days now, maybe several weeks? (time flies)

The assembler fails the sanity check for carry == 0 on
gas/atof-generic.c:419 on line 40 of the preprocessed asm file.  In
fact, assembling that line by itself produces the same error.

Here's how I configured the toolchain:

../configure   amd64-linux-gnu --enable-languages=all

and here's how I configured glibc:

../src/configure '--prefix=/usr' '--enable-add-ons=nptl' \
  '--without-cvs' '--with-tls' '--with-headers=/usr/include' \
  '--build=i686-pc-linux-gnu' 'CC=gcc -m32 -march=i686 -U__i686' \
  'CXX=g++ -m32 -march=i686 -U__i686'

(the ugly -U__i686 was introduced months ago; IIRC without it we'd
fail to assemble the GOT register set up routines that have __i686 in
their names in such a way that the preprocessor would expand __i686 to
1.  I haven't tried without it, I've only just realized it was still
there)

Using binutils-2.16.91.0.6-2 from the Fedora Core development tree
works.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: can't build x86-32 libc on x86-64 with mainline binutils

[H. J. Lu]

On Thu, Mar 02, 2006 at 03:06:57PM -0300, Alexandre Oliva wrote:
> Am I the only one having trouble assembling
> glibc/sysdeps/i386/fpu/e_atanh.S with -m32 with binutils mainline
> toplevel-bootstrapped along with GCC trunk on x86_64?  I've hit this
> for several days now, maybe several weeks? (time flies)
> 
> The assembler fails the sanity check for carry == 0 on
> gas/atof-generic.c:419 on line 40 of the preprocessed asm file.  In
> fact, assembling that line by itself produces the same error.
> 
> Here's how I configured the toolchain:
> 
> ../configure   amd64-linux-gnu --enable-languages=all
> 
> and here's how I configured glibc:
> 
> ../src/configure '--prefix=/usr' '--enable-add-ons=nptl' \
>   '--without-cvs' '--with-tls' '--with-headers=/usr/include' \
>   '--build=i686-pc-linux-gnu' 'CC=gcc -m32 -march=i686 -U__i686' \
>   'CXX=g++ -m32 -march=i686 -U__i686'
> 
> (the ugly -U__i686 was introduced months ago; IIRC without it we'd
> fail to assemble the GOT register set up routines that have __i686 in
> their names in such a way that the preprocessor would expand __i686 to
> 1.  I haven't tried without it, I've only just realized it was still
> there)

So mainline assembler doesn't work for you. Can you open a bug report
with a small testcase if you haven't done so? I will look into it.


H.J.

Re: can't build x86-32 libc on x86-64 with mainline binutils

[Alexandre Oliva]

On Mar  2, 2006, "H. J. Lu" <hjl@lucon.org> wrote:

> So mainline assembler doesn't work for you. Can you open a bug report
> with a small testcase if you haven't done so? I will look into it.

Doesn't seem to be the assembler's fault.  If I build it with GCC 4.1,
it works just fine.

Anyhow, here's the testcase:

	.tfloat 0.3465735902799726547086160

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: can't build x86-32 libc on x86-64 with mainline binutils

[H. J. Lu]

On Thu, Mar 02, 2006 at 03:44:14PM -0300, Alexandre Oliva wrote:
> On Mar  2, 2006, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > So mainline assembler doesn't work for you. Can you open a bug report
> > with a small testcase if you haven't done so? I will look into it.
> 
> Doesn't seem to be the assembler's fault.  If I build it with GCC 4.1,
> it works just fine.
> 
> Anyhow, here's the testcase:
> 
> 	.tfloat 0.3465735902799726547086160
> 

Works for me:

[hjl@gnu-13 gas]$ cat foo.s
        .data
        .tfloat 0.3465735902799726547086160
[hjl@gnu-13 gas]$ ./as-new --version
GNU assembler 2.16.91 20060302
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
This assembler was configured for a target of
`x86_64-unknown-linux-gnu'.
[hjl@gnu-13 gas]$ ./as-new -o x.o foo.s
[hjl@gnu-13 gas]$ ./as-new -o x.o foo.s -32


H.J.

Re: can't build x86-32 libc on x86-64 with mainline binutils

[Alexandre Oliva]

On Mar  2, 2006, "H. J. Lu" <hjl@lucon.org> wrote:

> On Thu, Mar 02, 2006 at 03:44:14PM -0300, Alexandre Oliva wrote:
>> On Mar  2, 2006, "H. J. Lu" <hjl@lucon.org> wrote:
>> 
>> > So mainline assembler doesn't work for you. Can you open a bug report
>> > with a small testcase if you haven't done so? I will look into it.
>> 
>> Doesn't seem to be the assembler's fault.  If I build it with GCC 4.1,
>> it works just fine.
>> 
>> Anyhow, here's the testcase:
>> 
>> .tfloat 0.3465735902799726547086160
>> 

> Works for me:

Which compiler did you use to compile gas?  As I wrote before, with
GCC 4.1, it works; with GCC trunk, it doesn't.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: can't build x86-32 libc on x86-64 with mainline binutils

[H. J. Lu]

On Thu, Mar 02, 2006 at 03:56:15PM -0300, Alexandre Oliva wrote:
> On Mar  2, 2006, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > On Thu, Mar 02, 2006 at 03:44:14PM -0300, Alexandre Oliva wrote:
> >> On Mar  2, 2006, "H. J. Lu" <hjl@lucon.org> wrote:
> >> 
> >> > So mainline assembler doesn't work for you. Can you open a bug report
> >> > with a small testcase if you haven't done so? I will look into it.
> >> 
> >> Doesn't seem to be the assembler's fault.  If I build it with GCC 4.1,
> >> it works just fine.
> >> 
> >> Anyhow, here's the testcase:
> >> 
> >> .tfloat 0.3465735902799726547086160
> >> 
> 
> > Works for me:
> 
> Which compiler did you use to compile gas?  As I wrote before, with

Gcc 3.4.

> GCC 4.1, it works; with GCC trunk, it doesn't.

Are you saying gcc trunk miscompiles assembler?  It sounds like a
gcc bug to me.


H.J.

Re: can't build x86-32 libc on x86-64 with mainline binutils

[Nick Clifton]

Hi Alex,

> Anyhow, here's the testcase:
> 
> 	.tfloat 0.3465735902799726547086160

Ah ha - difficult to reproduce but yes I now get:

   foo.s: Assembler messages:
   foo.s:1: Fatal error: failed sanity check

Note - this bug does not seem to have stopped me from building gcc with 
the mainline sources, but then I am not configuring with glibc in the 
same way as you and there are probably some other differences in our 
build environments as well.

I assume however that this must be a gcc bug - ie it has miscompiled 
gas.  Have you investigated further yet ?

Cheers
   Nick

Re: can't build x86-32 libc on x86-64 with mainline binutils

[R Hill]

Nick Clifton wrote:

>> Anyhow, here's the testcase:
>>
>>     .tfloat 0.3465735902799726547086160
> 
> Ah ha - difficult to reproduce but yes I now get:
> 
>   foo.s: Assembler messages:
>   foo.s:1: Fatal error: failed sanity check
> 
> Note - this bug does not seem to have stopped me from building gcc with 
> the mainline sources, but then I am not configuring with glibc in the 
> same way as you and there are probably some other differences in our 
> build environments as well.
> 
> I assume however that this must be a gcc bug - ie it has miscompiled 
> gas.  Have you investigated further yet ?


We've hit this as well on x86 and x86_64, but in a different spot.

x86_64-pc-linux-gnu-gcc ../sysdeps/x86_64/fpu/s_expm1l.S -c -D__NO_MATH_INLINES 
-D__LIBC_INTERNAL_MATH_INLINES -I../include 
-I/var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math 
-I/var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl 
-I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 
-I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 
-I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux 
-I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux 
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman 
-I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv 
-I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../ports/sysdeps/unix 
-I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix 
-I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 
-I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 
-I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl  -I.. 
-I../libio -I. -nostdinc -isystem 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0-pre20060421/include -isystem /usr/include 
-D_LIBC_REENTRANT -include ../include/libc-symbols.h   -DNOT_IN_libc=1 
-DIS_IN_libm=1    -DASSEMBLER   -Wa,--noexecstack -Wa,--noexecstack  -o 
/var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/s_expm1l.o 
-MD -MP -MF 
/var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/s_expm1l.o.dt 
-MT 
/var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/s_expm1l.o
../sysdeps/x86_64/fpu/s_expm1l.S: Assembler messages:
../sysdeps/x86_64/fpu/s_expm1l.S:40: Fatal error: failed sanity check


Testcase is:

.tfloat 1.442695040888963407359924681002


Glibc is 2.4, configured with:

configure --disable-nls
     --disable-stackguard-randomization
     --enable-old-ssp-compat
     --enable-omitfp
     --with-tls
     --with-__thread
     --enable-add-ons=ports,nptl,c_stubs,libidn
     --enable-kernel=2.6.11
     --without-selinux
     --without-cvs
     --enable-bind-now
     --build=x86_64-pc-linux-gnu
     --host=x86_64-pc-linux-gnu
     --disable-profile
     --without-gd
     --with-headers=/usr/include
     --prefix=/usr
     --libdir=/usr/lib64
     --mandir=/usr/share/man
     --infodir=/usr/share/info
     --libexecdir=/usr/lib64/misc/glibc


Binutils is 2.16.92, configured with:

configure --prefix=/usr
     --host=x86_64-pc-linux-gnu
     --target=x86_64-pc-linux-gnu
     --datadir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.92
     --infodir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.92/info
     --mandir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.92/man
     --bindir=/usr/x86_64-pc-linux-gnu/binutils-bin/2.16.92
     --libdir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.16.92
     --libexecdir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.16.92
     --includedir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.16.92/include
     --enable-64-bit-bfd
     --enable-shared
     --disable-werror
     --disable-nls
     --build=x86_64-pc-linux-gnu


and GCC is 20060428 svn:

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: 
/var/tmp/portage/gcc-4.2.0_pre20060428/work/gcc-4.2.0-20060428/configure 
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.2.0-pre20060428 
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0-pre20060428/include 
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.0-pre20060428 
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.0-pre20060428/man 
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.0-pre20060428/info 
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0-pre20060428/include/g++-v4 
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec 
--disable-nls --with-system-zlib --disable-checking --disable-werror 
--disable-libunwind-exceptions --disable-multilib --disable-libmudflap 
--disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared 
--enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.2.0-pre20060428  (experimental)


Has there been any progress on this or has there been a PR opened against GCC?


--de.

Re: can't build x86-32 libc on x86-64 with mainline binutils

[H. J. Lu]

On Sat, Apr 29, 2006 at 12:14:03AM -0600, R Hill wrote:
> 
> Testcase is:
> 
> .tfloat 1.442695040888963407359924681002
> 
> Binutils is 2.16.92, configured with:
> 

It works for me with binutils in CVS and the Linux binutils
2.16.91.0.7. Does the Linux binutils 2.16.91.0.7 work for you?


H.J.

Re: can't build x86-32 libc on x86-64 with mainline binutils

[Alexandre Oliva]

On Apr 29, 2006, "H. J. Lu" <hjl@lucon.org> wrote:

> On Sat, Apr 29, 2006 at 12:14:03AM -0600, R Hill wrote:
>> 
>> Testcase is:
>> 
>> .tfloat 1.442695040888963407359924681002
>> 
>> Binutils is 2.16.92, configured with:
>> 

> It works for me with binutils in CVS and the Linux binutils
> 2.16.91.0.7. Does the Linux binutils 2.16.91.0.7 work for you?

H.J., we've gone through this before.  You didn't use GCC trunk to
build binutils, which is what triggers the bug.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Gcc 4.2 miscompiles binutils on x86 and x86-64

[H. J. Lu]

On Sat, Apr 29, 2006 at 03:49:42PM -0300, Alexandre Oliva wrote:
> On Apr 29, 2006, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > On Sat, Apr 29, 2006 at 12:14:03AM -0600, R Hill wrote:
> >> 
> >> Testcase is:
> >> 
> >> .tfloat 1.442695040888963407359924681002
> >> 
> >> Binutils is 2.16.92, configured with:
> >> 
> 
> > It works for me with binutils in CVS and the Linux binutils
> > 2.16.91.0.7. Does the Linux binutils 2.16.91.0.7 work for you?
> 
> H.J., we've gone through this before.  You didn't use GCC trunk to
> build binutils, which is what triggers the bug.
> 

It looks like a gcc bug to me. Gcc 4.2 miscompiles:

     more_than_enough_bits_for_digits
        = (number_of_digits_to_use * 3321928 / 1000000 + 1);

in atof_generic. When number_of_digits_to_use == 1, gcc 4.2 -O2 gets
more_than_enough_bits_for_digits as 4. The correct value is 37. I
am checking in this patch to warn users.


H.J.
----
2006-04-29  H.J. Lu  <hongjiu.lu@intel.com>

	* gas/i386/fp.d: New file.
	* gas/i386/fp.s: Likewise.

	* gas/i386/i386.exp: Run "fp".

--- gas/testsuite/gas/i386/fp.d.fp	2006-04-29 15:39:27.000000000 -0700
+++ gas/testsuite/gas/i386/fp.d	2006-04-29 15:55:50.000000000 -0700
@@ -0,0 +1,8 @@
+#objdump: -s -j .data
+#name: i386 fp
+
+.*:     file format .*
+
+Contents of section .data:
+ 0000 00881bcd 4b789ad4 004071a3 79094f93  ....Kx...@q.y.O.
+ 0010 0a40789a 5440789a 54400000 00000000  .@x.T@x.T@......
--- gas/testsuite/gas/i386/fp.s.fp	2006-04-29 15:39:23.000000000 -0700
+++ gas/testsuite/gas/i386/fp.s	2006-04-29 15:59:52.000000000 -0700
@@ -0,0 +1,13 @@
+	.data
+# .tfloat is 80-bit floating point format.
+	.tfloat 3.32192809488736218171e0
+#	.byte 0x0, 0x88, 0x1b, 0xcd, 0x4b, 0x78, 0x9a, 0xd4, 0x0, 0x40
+# .double is 64-bit floating point format.
+	.double 3.32192809488736218171e0
+#	.byte 0x71, 0xa3, 0x79, 0x09, 0x4f, 0x93, 0x0a, 0x40
+# The next two are 32-bit floating point format.
+	.float 3.32192809488736218171e0
+#	.byte 0x78, 0x9a, 0x54, 0x40, 0, 0, 0, 0
+	.single 3.32192809488736218171e0
+#	.byte 0x78, 0x9a, 0x54, 0x40, 0, 0, 0, 0
+	.byte 0, 0, 0, 0, 0, 0
--- gas/testsuite/gas/i386/i386.exp.fp	2006-03-07 15:40:19.000000000 -0800
+++ gas/testsuite/gas/i386/i386.exp	2006-04-29 15:40:01.000000000 -0700
@@ -71,6 +71,7 @@ if [expr ([istarget "i*86-*-*"] ||  [ist
     run_dump_test "merom"
     run_dump_test "rep"
     run_dump_test "rep-suffix"
+    run_dump_test "fp"
 
     # These tests require support for 8 and 16 bit relocs,
     # so we only run them for ELF and COFF targets.