serious libgcc regression added recently

serious libgcc regression added recently

[David Miller]

My sparc-linux-gnu builds with --enable-targets=all is failing with:

../../../../gcc/libgcc/config/sparc/lb1spc.S: Assembler messages:
../../../../gcc/libgcc/config/sparc/lb1spc.S:124: Error: detected global register use not covered by .register pseudo-op
../../../../gcc/libgcc/config/sparc/lb1spc.S:134: Error: detected global register use not covered by .register pseudo-op
...

It looks like it's trying to build 32-bit sparc files during the -m64
64-bit multiarch build or similar.  Or, alternatively, doing the
32-bit multiarch build with 64-bit options.

And others have reported link failures during the testsuite on
other targets.

Rainer it seems it might be your changes?

Re: serious libgcc regression added recently

[Joel Sherrill]

On 11/02/2011 03:36 PM, David Miller wrote:
> My sparc-linux-gnu builds with --enable-targets=all is failing with:
>
> ../../../../gcc/libgcc/config/sparc/lb1spc.S: Assembler messages:
> ../../../../gcc/libgcc/config/sparc/lb1spc.S:124: Error: detected global register use not covered by .register pseudo-op
> ../../../../gcc/libgcc/config/sparc/lb1spc.S:134: Error: detected global register use not covered by .register pseudo-op
> ...
>
> It looks like it's trying to build 32-bit sparc files during the -m64
> 64-bit multiarch build or similar.  Or, alternatively, doing the
> 32-bit multiarch build with 64-bit options.
>
> And others have reported link failures during the testsuite on
> other targets.
>
Is this similar to what I just got for sparc-rtems when compiling
libgcc2 with -mcpu=v8?

/tmp/cczMc4jN.s: Assembler messages:
/tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for 
"smul".
/tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for 
"smul".
/tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for 
"umul".

I can prepare a PR if you think it is different.
> Rainer it seems it might be your changes?


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: serious libgcc regression added recently

[David Miller]

From: Joel Sherrill <joel.sherrill@OARcorp.com>
Date: Wed, 2 Nov 2011 16:29:16 -0500

> Is this similar to what I just got for sparc-rtems when compiling
> libgcc2 with -mcpu=v8?
> 
> /tmp/cczMc4jN.s: Assembler messages:
> /tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
> "smul".
> /tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for
> "smul".
> /tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
> "umul".
> 
> I can prepare a PR if you think it is different.

I don't think so.  The bug I'm hitting seems to be simply that
config/sparc/t-linux64 wasn't migrated up into the libgcc configure
area properly the way that config/sparc/t-linux was.

I'm working on a fix right now.

Re: serious libgcc regression added recently

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Wed, 02 Nov 2011 18:30:56 -0400 (EDT)

> From: Joel Sherrill <joel.sherrill@OARcorp.com>
> Date: Wed, 2 Nov 2011 16:29:16 -0500
> 
>> Is this similar to what I just got for sparc-rtems when compiling
>> libgcc2 with -mcpu=v8?
>> 
>> /tmp/cczMc4jN.s: Assembler messages:
>> /tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
>> "umul".
>> 
>> I can prepare a PR if you think it is different.
> 
> I don't think so.  The bug I'm hitting seems to be simply that
> config/sparc/t-linux64 wasn't migrated up into the libgcc configure
> area properly the way that config/sparc/t-linux was.

Actually the problem is that libgcc/config.host checks ${host}
to decide whether to append config/sparc/t-softmul to the tmake
variable.

But when multilibbing 64-bit libraries on a 32-bit hosted build
configured with --enable-targets=all, the host will be sparc-*-linux
even when building the 64-bit libgcc.

So t-softmul gets appended anyways, and this causes us to try and
build config/sparc/lb1spc.S for the 64-bit libgcc which we should
never do.

And it will do the wrong thing in the opposite case too, when building
a 64-bit hosted sparc gcc, host will be sparc64-*-* when building the
multilib 32-bit libgcc, and in that cast config.host will not append
t-softfp even when it should.

I sure wish these changes got a lot more testing before they were
installed :-/

Re: serious libgcc regression added recently

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Wed, 02 Nov 2011 18:43:52 -0400 (EDT)

> So t-softmul gets appended anyways, and this causes us to try and
> build config/sparc/lb1spc.S for the 64-bit libgcc which we should
> never do.

I tried the patch below but it just results in syntax errors in the
Makefile.

Is this the way differences between multilib cases are going to be
handled now in libgcc, with these backtick shell conditionals that (of
all things) looks at the destination directory?

What if I want to put 64-bit libraries in a different location such as
plain 'lib/' to create a 64-bit pure system or similar?

I definitely prefer how this stuff worked beforehand wherein we would
know the actual "target" we're building for and we bring in the
appropriate "target" makefile fragments based upon that "target".

Now we just seem to look at the host and essentially include every
possible target makefile that could be multilibbed out of that host.

diff --git a/libgcc/config.host b/libgcc/config.host
index 05f084b..47e0e73 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1052,7 +1052,8 @@ sparc64-*-freebsd*|ultrasparc-*-freebsd*)
 	;;
 sparc64-*-linux*)		# 64-bit SPARC's running GNU/Linux
 	extra_parts="$extra_parts crtfastmath.o"
-	tmake_file="${tmake_file} t-crtfm sparc/t-linux sparc/t-linux64"
+	tmake_file="${tmake_file} t-crtfm sparc/t-linux sparc/t-linux64 \
+                    sparc/t-softmul"
 	md_unwind_header=sparc/linux-unwind.h
 	;;
 sparc64-*-netbsd*)
diff --git a/libgcc/config/sparc/t-softmul b/libgcc/config/sparc/t-softmul
index 7142200..5489a37 100644
--- a/libgcc/config/sparc/t-softmul
+++ b/libgcc/config/sparc/t-softmul
@@ -1,2 +1,4 @@
-LIB1ASMSRC = sparc/lb1spc.S
-LIB1ASMFUNCS = _mulsi3 _divsi3 _modsi3
+LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
+			= x../lib64; then echo sparc/lb1spc.S; fi`
+LIB1ASMFUNCS = `if test x$$($(CC) -print-multi-os-directory) \
+			= x../lib64; then echo _mulsi3 _divsi3 _modsi3; fi`

Re: serious libgcc regression added recently

[Andrew Pinski]

On Wed, Nov 2, 2011 at 4:28 PM, David Miller <davem@davemloft.net> wrote:
> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
> +                       = x../lib64; then echo sparc/lb1spc.S; fi`
> +LIB1ASMFUNCS = `if test x$$($(CC) -print-multi-os-directory) \
> +                       = x../lib64; then echo _mulsi3 _divsi3 _modsi3; fi`
>

-print-multi-directory is most likely easier to handle than os-directory.

Thanks,
Andrew Pinski

Re: serious libgcc regression added recently

[David Miller]

From: Andrew Pinski <pinskia@gmail.com>
Date: Wed, 2 Nov 2011 16:40:13 -0700

> On Wed, Nov 2, 2011 at 4:28 PM, David Miller <davem@davemloft.net> wrote:
>> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
>> +                       = x../lib64; then echo sparc/lb1spc.S; fi`
>> +LIB1ASMFUNCS = `if test x$$($(CC) -print-multi-os-directory) \
>> +                       = x../lib64; then echo _mulsi3 _divsi3 _modsi3; fi`
>>
> 
> -print-multi-directory is most likely easier to handle than os-directory.

I was just copying the construct Rainer was already using in
sparc/t-linux64 :-)

Re: serious libgcc regression added recently

[Joseph S. Myers]

On Wed, 2 Nov 2011, David Miller wrote:

> Is this the way differences between multilib cases are going to be
> handled now in libgcc, with these backtick shell conditionals that (of
> all things) looks at the destination directory?
> 
> What if I want to put 64-bit libraries in a different location such as
> plain 'lib/' to create a 64-bit pure system or similar?

See my review <http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02288.html> 
suggesting a followup to improve on the logic that was carried from the 
gcc/ directory.

> I definitely prefer how this stuff worked beforehand wherein we would
> know the actual "target" we're building for and we bring in the
> appropriate "target" makefile fragments based upon that "target".

Previously, makefile variables in the gcc/ directory had to be set just 
once and could not depend on the multilib, only on the target triplet - 
hence the `` code.

Now, because the variables are set in the libgcc directory which is 
configured separately for each multilib, it is possible for the makefile 
fragment selected to depend on the multilib as well as the target triplet, 
in a way it couldn't before.  This is a clear improvement.

Note that all these patches were posted at least two months ago with calls 
for testers, so there was plenty of time for target maintainers to review 
and test them for their targets.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: serious libgcc regression added recently

[Joseph S. Myers]

On Wed, 2 Nov 2011, David Miller wrote:

> Actually the problem is that libgcc/config.host checks ${host}
> to decide whether to append config/sparc/t-softmul to the tmake
> variable.

${host} is the *target* when configuring target libraries.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: serious libgcc regression added recently

[David Miller]

From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Thu, 3 Nov 2011 00:22:49 +0000 (UTC)

> On Wed, 2 Nov 2011, David Miller wrote:
> 
>> Actually the problem is that libgcc/config.host checks ${host}
>> to decide whether to append config/sparc/t-softmul to the tmake
>> variable.
> 
> ${host} is the *target* when configuring target libraries.

It doesn't represent the 'target' we're generating code for in
a multilib instance so we can conditionalize off of it correctly.

The only way sparc/t-softfp can be added to tmake is if the host
matches sparc-*-* and that's what happens even when we're building
the 64-bit libgcc in my case.

It's sparc-*-* for both the 32-bit and 64-bit libgcc builds.

Re: serious libgcc regression added recently

[Joseph S. Myers]

On Wed, 2 Nov 2011, David Miller wrote:

> > ${host} is the *target* when configuring target libraries.
> 
> It doesn't represent the 'target' we're generating code for in
> a multilib instance so we can conditionalize off of it correctly.
> 
> The only way sparc/t-softfp can be added to tmake is if the host
> matches sparc-*-* and that's what happens even when we're building
> the 64-bit libgcc in my case.
> 
> It's sparc-*-* for both the 32-bit and 64-bit libgcc builds.

Yes, there is nothing new there - when this configuration was in the gcc/ 
directory the target name was also the same for both builds.  What is new 
is that you can now put tests in libgcc/configure.ac such as the "Check 
32bit or 64bit for x86." one, and select t-* files based on those tests - 
whereas in the gcc/ directory there is no possibility at all for the 
choice of t-* files to depend on the multilib.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: serious libgcc regression added recently

[David Miller]

From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Thu, 3 Nov 2011 01:21:35 +0000 (UTC)

> What is new is that you can now put tests in libgcc/configure.ac
> such as the "Check 32bit or 64bit for x86." one, and select t-*
> files based on those tests - whereas in the gcc/ directory there is
> no possibility at all for the choice of t-* files to depend on the
> multilib.

That works for me, I'm bootstrapping the following:

--------------------
[PATCH] Fix multilib build of libgcc on Linux/sparc.

	* configure.ac: Set host_address on sparc too.
	* configure: Regenerate.
	* config.host: Add sparc/t-linux64 and sparc/t-softmul conditionally
	based upon host_address.
	* config/sparc/t-linux64: Set CRTSTUFF_T_CFLAGS unconditionally.
---
 libgcc/ChangeLog              |    8 ++++++++
 libgcc/config.host            |   17 ++++++++++++++---
 libgcc/config/sparc/t-linux64 |    3 +--
 libgcc/configure              |    7 ++++---
 libgcc/configure.ac           |    7 ++++---
 5 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 1bbe29a..3944193 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,11 @@
+2011-11-02  David S. Miller  <davem@davemloft.net>
+
+	* configure.ac: Set host_address on sparc too.
+	* configure: Regenerate.
+	* config.host: Add sparc/t-linux64 and sparc/t-softmul conditionally
+	based upon host_address.
+	* config/sparc/t-linux64: Set CRTSTUFF_T_CFLAGS unconditionally.
+
 2011-11-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
 
 	* gthr-single.h, gthr.h: New files.
diff --git a/libgcc/config.host b/libgcc/config.host
index 05f084b..647c6a1 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1008,7 +1008,10 @@ sparc-*-elf*)
 	extra_parts="$extra_parts crti.o crtn.o crtfastmath.o"
 	;;
 sparc-*-linux*)		# SPARC's running GNU/Linux, libc6
-	tmake_file="${tmake_file} t-crtfm sparc/t-linux64"
+	tmake_file="${tmake_file} t-crtfm"
+	if test "${host_address}" = 64; then
+  		tmake_file="$tmake_file sparc/t-linux64"
+	fi
 	case ${host} in
 	*-leon*)
 		tmake_file="${tmake_file} t-fdpbit"
@@ -1021,7 +1024,9 @@ sparc-*-linux*)		# SPARC's running GNU/Linux, libc6
 	*-leon[3-9]*)
 		;;
 	*)
-	  	tmake_file="$tmake_file sparc/t-softmul"
+		if test "${host_address}" = 32; then
+	  		tmake_file="$tmake_file sparc/t-softmul"
+		fi
 	  	;;
 	esac
 	extra_parts="$extra_parts crtfastmath.o"
@@ -1052,7 +1057,13 @@ sparc64-*-freebsd*|ultrasparc-*-freebsd*)
 	;;
 sparc64-*-linux*)		# 64-bit SPARC's running GNU/Linux
 	extra_parts="$extra_parts crtfastmath.o"
-	tmake_file="${tmake_file} t-crtfm sparc/t-linux sparc/t-linux64"
+	tmake_file="${tmake_file} t-crtfm sparc/t-linux"
+	if test "${host_address}" = 64; then
+		tmake_file="${tmake_file} sparc/t-linux64"
+	fi
+	if test "${host_address}" = 32; then
+		tmake_file="${tmake_file} sparc/t-softmul"
+	fi
 	md_unwind_header=sparc/linux-unwind.h
 	;;
 sparc64-*-netbsd*)
diff --git a/libgcc/config/sparc/t-linux64 b/libgcc/config/sparc/t-linux64
index ca4a892..6583fe2 100644
--- a/libgcc/config/sparc/t-linux64
+++ b/libgcc/config/sparc/t-linux64
@@ -1,2 +1 @@
-CRTSTUFF_T_CFLAGS = `if test x$$($(CC) -print-multi-os-directory) \
-			= x../lib64; then echo -mcmodel=medany; fi`
+CRTSTUFF_T_CFLAGS = -mcmodel=medany
diff --git a/libgcc/configure b/libgcc/configure
index 0d91645..0f18037 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4609,11 +4609,12 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcc_cv_cfi" >&5
 $as_echo "$libgcc_cv_cfi" >&6; }
 
-# Check 32bit or 64bit for x86.
+# Check 32bit or 64bit for x86 and sparc.
 case ${host} in
-i?86*-*-* | x86_64*-*-*)
+i?86*-*-* | x86_64*-*-* | sparc*-*-*)
   cat > conftest.c <<EOF
-#ifdef __x86_64__
+#if defined(__x86_64__) || \
+    (defined(__sparc__) && defined(__arch64__))
 host_address=64
 #else
 host_address=32
diff --git a/libgcc/configure.ac b/libgcc/configure.ac
index a505257..5250be3 100644
--- a/libgcc/configure.ac
+++ b/libgcc/configure.ac
@@ -255,11 +255,12 @@ AC_CACHE_CHECK([whether assembler supports CFI directives], [libgcc_cv_cfi],
   [libgcc_cv_cfi=yes],
   [libgcc_cv_cfi=no])])
 
-# Check 32bit or 64bit for x86.
+# Check 32bit or 64bit for x86 and sparc.
 case ${host} in
-i?86*-*-* | x86_64*-*-*)
+i?86*-*-* | x86_64*-*-* | sparc*-*-*)
   cat > conftest.c <<EOF
-#ifdef __x86_64__
+#if defined(__x86_64__) || \
+    (defined(__sparc__) && defined(__arch64__))
 host_address=64
 #else
 host_address=32
-- 
1.7.6.401.g6a319

Re: serious libgcc regression added recently

[Jakub Jelinek]

On Wed, Nov 02, 2011 at 11:41:08PM -0400, David Miller wrote:
> --- a/libgcc/configure.ac
> +++ b/libgcc/configure.ac
> @@ -255,11 +255,12 @@ AC_CACHE_CHECK([whether assembler supports CFI directives], [libgcc_cv_cfi],
>    [libgcc_cv_cfi=yes],
>    [libgcc_cv_cfi=no])])
>  
> -# Check 32bit or 64bit for x86.
> +# Check 32bit or 64bit for x86 and sparc.
>  case ${host} in
> -i?86*-*-* | x86_64*-*-*)
> +i?86*-*-* | x86_64*-*-* | sparc*-*-*)
>    cat > conftest.c <<EOF
> -#ifdef __x86_64__
> +#if defined(__x86_64__) || \
> +    (defined(__sparc__) && defined(__arch64__))
>  host_address=64
>  #else
>  host_address=32

I think much better would be to handle sparc*/s390*/powerpc* differently
here, just using #ifdef __LP64__ test.  i?86/x86_64 is different because
of the third weirdo multilib option.

	Jakub

Re: serious libgcc regression added recently

[David Miller]

From: Jakub Jelinek <jakub@redhat.com>
Date: Thu, 3 Nov 2011 09:22:51 +0100

> On Wed, Nov 02, 2011 at 11:41:08PM -0400, David Miller wrote:
>> --- a/libgcc/configure.ac
>> +++ b/libgcc/configure.ac
>> @@ -255,11 +255,12 @@ AC_CACHE_CHECK([whether assembler supports CFI directives], [libgcc_cv_cfi],
>>    [libgcc_cv_cfi=yes],
>>    [libgcc_cv_cfi=no])])
>>  
>> -# Check 32bit or 64bit for x86.
>> +# Check 32bit or 64bit for x86 and sparc.
>>  case ${host} in
>> -i?86*-*-* | x86_64*-*-*)
>> +i?86*-*-* | x86_64*-*-* | sparc*-*-*)
>>    cat > conftest.c <<EOF
>> -#ifdef __x86_64__
>> +#if defined(__x86_64__) || \
>> +    (defined(__sparc__) && defined(__arch64__))
>>  host_address=64
>>  #else
>>  host_address=32
> 
> I think much better would be to handle sparc*/s390*/powerpc* differently
> here, just using #ifdef __LP64__ test.  i?86/x86_64 is different because
> of the third weirdo multilib option.

Yes, using __LP64__ for non-x86 is much better.  Then we can completely
remove the ${host} conditional and nobody will have to hack on this
piece of configure code ever again.

I'll try to find time ot hack this together if nobody beats me to it.

Re: serious libgcc regression added recently

[David Miller]

From: Jakub Jelinek <jakub@redhat.com>
Date: Thu, 3 Nov 2011 09:22:51 +0100

> I think much better would be to handle sparc*/s390*/powerpc* differently
> here, just using #ifdef __LP64__ test.  i?86/x86_64 is different because
> of the third weirdo multilib option.

I just tested and committed the following, it seemed to make no sense
to keep the case statement there and now the host_address should be
available to anyone who wants to make use of it in config.host

--------------------
[PATCH] Tweak libgcc configure test for 64-bit.

libgcc/

	* configure.ac: Test for 64-bit addresses on !x86 using __LP64__.
	* configure: Rebuild.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181000 138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgcc/ChangeLog    |    5 +++++
 libgcc/configure    |   15 +++++----------
 libgcc/configure.ac |   15 +++++----------
 3 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index ec06a09..d3f091e 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,8 @@
+2011-11-04  David S. Miller  <davem@davemloft.net>
+
+	* configure.ac: Test for 64-bit addresses on !x86 using __LP64__.
+	* configure: Rebuild.
+
 2011-11-04  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>
 
 	* config/s390/t-crtstuff: Add -fPIC to CRTSTUFF_T_CFLAGS_S
diff --git a/libgcc/configure b/libgcc/configure
index 0f18037..1895a76 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4609,21 +4609,16 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcc_cv_cfi" >&5
 $as_echo "$libgcc_cv_cfi" >&6; }
 
-# Check 32bit or 64bit for x86 and sparc.
-case ${host} in
-i?86*-*-* | x86_64*-*-* | sparc*-*-*)
-  cat > conftest.c <<EOF
-#if defined(__x86_64__) || \
-    (defined(__sparc__) && defined(__arch64__))
+# Check 32bit or 64bit
+cat > conftest.c <<EOF
+#if defined(__x86_64__) || (!defined(__i386__) && defined(__LP64__))
 host_address=64
 #else
 host_address=32
 #endif
 EOF
-    eval `${CC-cc} -E conftest.c | grep host_address=`
-    rm -f conftest.c
-    ;;
-esac
+eval `${CC-cc} -E conftest.c | grep host_address=`
+rm -f conftest.c
 
 # Collect host-machine-specific information.
 . ${srcdir}/config.host
diff --git a/libgcc/configure.ac b/libgcc/configure.ac
index 5250be3..308038c 100644
--- a/libgcc/configure.ac
+++ b/libgcc/configure.ac
@@ -255,21 +255,16 @@ AC_CACHE_CHECK([whether assembler supports CFI directives], [libgcc_cv_cfi],
   [libgcc_cv_cfi=yes],
   [libgcc_cv_cfi=no])])
 
-# Check 32bit or 64bit for x86 and sparc.
-case ${host} in
-i?86*-*-* | x86_64*-*-* | sparc*-*-*)
-  cat > conftest.c <<EOF
-#if defined(__x86_64__) || \
-    (defined(__sparc__) && defined(__arch64__))
+# Check 32bit or 64bit
+cat > conftest.c <<EOF
+#if defined(__x86_64__) || (!defined(__i386__) && defined(__LP64__))
 host_address=64
 #else
 host_address=32
 #endif
 EOF
-    eval `${CC-cc} -E conftest.c | grep host_address=`
-    rm -f conftest.c
-    ;;
-esac
+eval `${CC-cc} -E conftest.c | grep host_address=`
+rm -f conftest.c
 
 # Collect host-machine-specific information.
 . ${srcdir}/config.host
-- 
1.7.6.401.g6a319

Re: serious libgcc regression added recently

[Joel Sherrill]

On 11/02/2011 05:30 PM, David Miller wrote:
> From: Joel Sherrill<joel.sherrill@OARcorp.com>
> Date: Wed, 2 Nov 2011 16:29:16 -0500
>
>> Is this similar to what I just got for sparc-rtems when compiling
>> libgcc2 with -mcpu=v8?
>>
>> /tmp/cczMc4jN.s: Assembler messages:
>> /tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
>> "umul".
>>
>> I can prepare a PR if you think it is different.
> I don't think so.  The bug I'm hitting seems to be simply that
> config/sparc/t-linux64 wasn't migrated up into the libgcc configure
> area properly the way that config/sparc/t-linux was.
>
> I'm working on a fix right now.
I filed a PR for this so it doesn't get lost.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979

I am happy to retest whenever something changes.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985