Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-18 Thread Roland Stigge 
Hi,

in short: The new patches you proposed work (as attached for the current
versions in unstable and experimental, resp.)! :-)

Now, we can support powerpc, powerpcspe and spev1, even fixing the bsd
specific stuff (t-spe) upstream.

Thanks,

Roland
--- debian/patches/gcc-multiarch.diff.orig	2012-12-15 01:56:47.689469128 +0100
+++ debian/patches/gcc-multiarch.diff	2012-12-15 02:11:14.177493559 +0100
@@ -555,7 +564,7 @@
  			  maltivec/mlittle \
  			  maltivec/mabi=altivec/mlittle
 +
-+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1)
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1)
 +
 --- a/src/gcc/config/rs6000/t-linux64	(revision 182390)
 +++ b/src/gcc/config/rs6000/t-linux64	(working copy)
@@ -570,8 +579,12 @@
  MULTILIB_MATCHES= $(MULTILIB_MATCHES_FLOAT)
 --- a/src/gcc/config/rs6000/t-linux	(revision 0)
 +++ b/src/gcc/config/rs6000/t-linux	(revision 0)
-@@ -0,0 +1 @@
+@@ -0,0 +1,5 @@
++ifneq (,$(findstring spe, $(target)))
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1)
++else
 +MULTIARCH_DIRNAME = powerpc-linux-gnu
++endif
 --- a/src/gcc/config/arm/t-linux-eabi	(revision 182390)
 +++ b/src/gcc/config/arm/t-linux-eabi	(working copy)
 @@ -24,3 +24,6 @@
--- debian/patches/gcc-multiarch-upstream.diff.orig	2012-12-18 10:52:15.0 +0100
+++ debian/patches/gcc-multiarch-upstream.diff	2012-12-18 10:54:23.0 +0100
@@ -347,12 +347,16 @@
 +MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-linux-gnux32)
 --- a/src/gcc/config/rs6000/t-linux	(Revision 0)
 +++ b/src/gcc/config/rs6000/t-linux	(Arbeitskopie)
-@@ -0,0 +1,5 @@
+@@ -0,0 +1,9 @@
 +# do not define the multiarch name if configured for a soft-float cpu
 +# or soft-float.
 +ifeq (,$(filter $(with_cpu),$(SOFT_FLOAT_CPUS))$(findstring soft,$(with_float)))
++ifneq (,$(findstring spe, $(target)))
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1)
++else
 +MULTIARCH_DIRNAME = powerpc-linux-gnu
 +endif
++endif
 --- a/src/gcc/config/rs6000/t-spe	(Revision 193696)
 +++ b/src/gcc/config/rs6000/t-spe	(Arbeitskopie)
 @@ -71,3 +71,7 @@
@@ -361,7 +365,7 @@
  			  maltivec/mabi=altivec/mlittle
 +
 +ifneq (,$(findstring linux, $(target)))
-+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1)
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1)
 +endif
 --- a/src/gcc/config/rs6000/t-fprules	(Revision 193696)
 +++ b/src/gcc/config/rs6000/t-fprules	(Arbeitskopie)

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-17 Thread Matthias Klose 
Am 15.12.2012 14:16, schrieb Roland Stigge:
 Hi Matthias,
 
 On 14/12/12 15:37, Roland Stigge wrote:
 That's what current upstream does in src/gcc/config.gcc: e500-double.h
 is added to the tm_file (list) to make the distinction between v1 and
 default/v2.

 If you don't have another suggestion, I would adjust upstream to do
 actually the same, but do via tm_file_list instead of tm_file (as you
 suggested).
 
 Consider the attached patch: It does the same as the first patch but via
 tm_file_list instead of tm_file as described above. (Applying to the
 version in unstable, and with the experimental version there is
 generally the same issue.)

the chunk for config.gcc is wrong. You have to use tm_file here.

 Unfortunately, upon build, this also didn't work: Both tm_file and
 tm_file_list don't get passed to t-linux (and the other makefile snippets).
 
 My conclusion is that the tm_file (_list) passing doesn't work as
 intended (including upstream), and considering that all
 powerpc-linux-gnuspe(-v1) specific stuff in src/gcc/config/rs6000 is
 Debian specific (only in a debian/patch/*) and not working anyway as
 described previously, I guess -v1 support is negligible. (Also, can't
 test it.)

strange, seems to work on other architectures.

 For which reason does Debian need to explicitely port to gnuspev1 (when
 upstream's port is only bsd specific and obviously not working anyway)?

Sure, but then don't define a wrong multiarch name for that case.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-17 Thread Roland Stigge 
On 12/17/2012 01:58 PM, Matthias Klose wrote:
 Consider the attached patch: It does the same as the first patch but via
 tm_file_list instead of tm_file as described above. (Applying to the
 version in unstable, and with the experimental version there is
 generally the same issue.)
 
 the chunk for config.gcc is wrong. You have to use tm_file here.

You mean adding the file via tm_file and assume it is passed to the
Makefile via tm_file_list?

Will test and report back.

 Unfortunately, upon build, this also didn't work: Both tm_file and
 tm_file_list don't get passed to t-linux (and the other makefile snippets).

 My conclusion is that the tm_file (_list) passing doesn't work as
 intended (including upstream), and considering that all
 powerpc-linux-gnuspe(-v1) specific stuff in src/gcc/config/rs6000 is
 Debian specific (only in a debian/patch/*) and not working anyway as
 described previously, I guess -v1 support is negligible. (Also, can't
 test it.)
 
 strange, seems to work on other architectures.
 
 For which reason does Debian need to explicitely port to gnuspev1 (when
 upstream's port is only bsd specific and obviously not working anyway)?
 
 Sure, but then don't define a wrong multiarch name for that case.

My stand is that (as described) there is no working support for gnuspev1
currently (neither upstream nor in Debian). Even worse, the (broken)
support for it stands in the way of gnuspe/powerpcspe.

Anyway, will test tm_file/tm_file_list as described above and report back.

Roland


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-15 Thread Roland Stigge 
Hi Matthias,

On 14/12/12 15:37, Roland Stigge wrote:
 That's what current upstream does in src/gcc/config.gcc: e500-double.h
 is added to the tm_file (list) to make the distinction between v1 and
 default/v2.
 
 If you don't have another suggestion, I would adjust upstream to do
 actually the same, but do via tm_file_list instead of tm_file (as you
 suggested).

Consider the attached patch: It does the same as the first patch but via
tm_file_list instead of tm_file as described above. (Applying to the
version in unstable, and with the experimental version there is
generally the same issue.)

Unfortunately, upon build, this also didn't work: Both tm_file and
tm_file_list don't get passed to t-linux (and the other makefile snippets).

My conclusion is that the tm_file (_list) passing doesn't work as
intended (including upstream), and considering that all
powerpc-linux-gnuspe(-v1) specific stuff in src/gcc/config/rs6000 is
Debian specific (only in a debian/patch/*) and not working anyway as
described previously, I guess -v1 support is negligible. (Also, can't
test it.)

For which reason does Debian need to explicitely port to gnuspev1 (when
upstream's port is only bsd specific and obviously not working anyway)?

So still proposing the very first patches in this report. (Considering
v1 as an issue to be solved selarately.)

Thanks in advance,

Roland
--- debian/patches/gcc-multiarch.diff.orig	2012-12-15 01:56:47.689469128 +0100
+++ debian/patches/gcc-multiarch.diff	2012-12-15 02:11:14.177493559 +0100
@@ -445,6 +445,15 @@
  	i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
  		;;
  	i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
+@@ -3586,7 +3586,7 @@
+ 
+ if test x$enable_e500_double = xyes
+ then
+-tm_file=$tm_file rs6000/e500-double.h
++tm_file_list=$tm_file_list rs6000/e500-double.h
+ fi
+ 		;;
+ 
 --- a/src/gcc/Makefile.in	(revision 182390)
 +++ b/src/gcc/Makefile.in	(working copy)
 @@ -352,6 +352,17 @@
@@ -555,7 +564,7 @@
  			  maltivec/mlittle \
  			  maltivec/mabi=altivec/mlittle
 +
-+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1)
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1)
 +
 --- a/src/gcc/config/rs6000/t-linux64	(revision 182390)
 +++ b/src/gcc/config/rs6000/t-linux64	(working copy)
@@ -570,8 +579,12 @@
  MULTILIB_MATCHES= $(MULTILIB_MATCHES_FLOAT)
 --- a/src/gcc/config/rs6000/t-linux	(revision 0)
 +++ b/src/gcc/config/rs6000/t-linux	(revision 0)
-@@ -0,0 +1 @@
+@@ -0,0 +1,5 @@
++ifneq (,$(findstring spe, $(target)))
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1)
++else
 +MULTIARCH_DIRNAME = powerpc-linux-gnu
++endif
 --- a/src/gcc/config/arm/t-linux-eabi	(revision 182390)
 +++ b/src/gcc/config/arm/t-linux-eabi	(working copy)
 @@ -24,3 +24,6 @@

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-14 Thread Matthias Klose 
Am 12.12.2012 13:26, schrieb Roland Stigge:
 Hi,
 
 regarding your request to use t-spe, I'm attaching two patches, for the
 unstable and experimental versions of gcc-4.7, respectively.
 
 As written before, in Debian, t-spe wasn't included properly (only on
 some bsd variant). So doing it instead of t-linux in the powerpcspe
 case, when spe is present.
 
 Further, the Debian specific patch (gcc-multiarch...) contained:
 
 +MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring
 rs6000/e500-double.h, $(tm_file)),,v1)
 
 But unfortunately, tm_file isn't passed from the config script to the
 Makefile, resulting in MULTIARCH_DIRNAME = powerpc-linux-gnuspev1
 always. (I tested that tm_file is set correctly w/ e500-double.h, but
 not passed to the Makefile.)
 
 Since we are only supporting powerpcspe (not powerpcspev1), I removed
 the respective $(if ...) also. It was the only reference to tm_file in
 the Makefiles (and broken anyway). In the unlikely event that someone
 needs a powerpcspev1 port, we can add it again (and need to pass tm_file
 to the Makefile also which wasn't done before).

that's wrong, using tm_file_list now.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-14 Thread Matthias Klose 
Am 12.12.2012 13:26, schrieb Roland Stigge:
 Hi,
 
 regarding your request to use t-spe, I'm attaching two patches, for the
 unstable and experimental versions of gcc-4.7, respectively.
 
 As written before, in Debian, t-spe wasn't included properly (only on
 some bsd variant). So doing it instead of t-linux in the powerpcspe
 case, when spe is present.

is this wanted, e.g. defining all the MULTILIB macros? then better add the t-spe
bits to the t-linux file.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-14 Thread Roland Stigge 
On 14/12/12 14:10, Matthias Klose wrote:
 Am 12.12.2012 13:26, schrieb Roland Stigge:
 regarding your request to use t-spe, I'm attaching two patches, for the
 unstable and experimental versions of gcc-4.7, respectively.

 As written before, in Debian, t-spe wasn't included properly (only on
 some bsd variant). So doing it instead of t-linux in the powerpcspe
 case, when spe is present.
 
 is this wanted, e.g. defining all the MULTILIB macros?

No, not necessary.

 then better add the t-spe bits to the t-linux file.

Fine with that. That's actually what my very first patch did that I
submitted with this report. So please take it. :-)

(t-spe contains only multilib stuff that we don't need anyway for
powerpcspe.)

Thanks,

Roland


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-14 Thread Matthias Klose 
Am 14.12.2012 14:34, schrieb Roland Stigge:
 On 14/12/12 14:10, Matthias Klose wrote:
 Am 12.12.2012 13:26, schrieb Roland Stigge:
 regarding your request to use t-spe, I'm attaching two patches, for the
 unstable and experimental versions of gcc-4.7, respectively.

 As written before, in Debian, t-spe wasn't included properly (only on
 some bsd variant). So doing it instead of t-linux in the powerpcspe
 case, when spe is present.

 is this wanted, e.g. defining all the MULTILIB macros?
 
 No, not necessary.
 
 then better add the t-spe bits to the t-linux file.
 
 Fine with that. That's actually what my very first patch did that I
 submitted with this report. So please take it. :-)

but this one doesn't look for the v1/v0 distinction and uses the same multiarch
tuple for both. Please bring it in a form which can go upstream.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-14 Thread Roland Stigge 
On 14/12/12 14:49, Matthias Klose wrote:
 Am 14.12.2012 14:34, schrieb Roland Stigge:
 On 14/12/12 14:10, Matthias Klose wrote:
 Am 12.12.2012 13:26, schrieb Roland Stigge:
 regarding your request to use t-spe, I'm attaching two patches, for the
 unstable and experimental versions of gcc-4.7, respectively.

 As written before, in Debian, t-spe wasn't included properly (only on
 some bsd variant). So doing it instead of t-linux in the powerpcspe
 case, when spe is present.

 is this wanted, e.g. defining all the MULTILIB macros?

 No, not necessary.

 then better add the t-spe bits to the t-linux file.

 Fine with that. That's actually what my very first patch did that I
 submitted with this report. So please take it. :-)
 
 but this one doesn't look for the v1/v0 distinction and uses the same 
 multiarch
 tuple for both. Please bring it in a form which can go upstream.

In your other mail you wrote about tm_file being replaced by
tm_file_list. Should I assume that tm_file (which includes e500-double.h
by which the distinction of v1 is made) is included into tm_file_list
somehow (what I currently can't see), or should we patch
src/gcc/config.gcc to include e500-double.h into tm_file_list instead of
tm_file?

Thanks in advance,

Roland


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-14 Thread Matthias Klose 
Am 14.12.2012 15:19, schrieb Roland Stigge:
 but this one doesn't look for the v1/v0 distinction and uses the same 
 multiarch
 tuple for both. Please bring it in a form which can go upstream.
 
 In your other mail you wrote about tm_file being replaced by
 tm_file_list. Should I assume that tm_file (which includes e500-double.h
 by which the distinction of v1 is made) is included into tm_file_list
 somehow (what I currently can't see), or should we patch
 src/gcc/config.gcc to include e500-double.h into tm_file_list instead of
 tm_file?

I don't know the powerpcspe target that well. Adding a header looks wrong.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-14 Thread Roland Stigge 
On 14/12/12 15:31, Matthias Klose wrote:
 Am 14.12.2012 15:19, schrieb Roland Stigge:
 but this one doesn't look for the v1/v0 distinction and uses the same 
 multiarch
 tuple for both. Please bring it in a form which can go upstream.

 In your other mail you wrote about tm_file being replaced by
 tm_file_list. Should I assume that tm_file (which includes e500-double.h
 by which the distinction of v1 is made) is included into tm_file_list
 somehow (what I currently can't see), or should we patch
 src/gcc/config.gcc to include e500-double.h into tm_file_list instead of
 tm_file?
 
 I don't know the powerpcspe target that well. Adding a header looks wrong.

That's what current upstream does in src/gcc/config.gcc: e500-double.h
is added to the tm_file (list) to make the distinction between v1 and
default/v2.

If you don't have another suggestion, I would adjust upstream to do
actually the same, but do via tm_file_list instead of tm_file (as you
suggested).

Would this be OK for you (i.e. Debian and forwarding upstream)?

Thanks in advance,

Roland


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695661: #695661: gcc-4.7: Please fix build on powerpcspe

2012-12-12 Thread Roland Stigge 
Hi,

regarding your request to use t-spe, I'm attaching two patches, for the
unstable and experimental versions of gcc-4.7, respectively.

As written before, in Debian, t-spe wasn't included properly (only on
some bsd variant). So doing it instead of t-linux in the powerpcspe
case, when spe is present.

Further, the Debian specific patch (gcc-multiarch...) contained:

+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring
rs6000/e500-double.h, $(tm_file)),,v1)

But unfortunately, tm_file isn't passed from the config script to the
Makefile, resulting in MULTIARCH_DIRNAME = powerpc-linux-gnuspev1
always. (I tested that tm_file is set correctly w/ e500-double.h, but
not passed to the Makefile.)

Since we are only supporting powerpcspe (not powerpcspev1), I removed
the respective $(if ...) also. It was the only reference to tm_file in
the Makefiles (and broken anyway). In the unlikely event that someone
needs a powerpcspev1 port, we can add it again (and need to pass tm_file
to the Makefile also which wasn't done before).

Thanks in advance,

Roland
--- debian/patches/gcc-multiarch.diff.orig	2012-12-11 21:49:03.494351993 +0100
+++ debian/patches/gcc-multiarch.diff	2012-12-11 21:49:49.890363523 +0100
@@ -419,11 +419,18 @@
  	target_cpu_default=MASK_GNU_AS|MASK_GNU_LD
  	;;
  ia64*-*-hpux*)
-@@ -2012,6 +2012,7 @@
+@@ -2012,6 +2012,14 @@
  		;;
  	*)
  		tm_file=${tm_file} rs6000/linux.h glibc-stdint.h
-+		tmake_file=$tmake_file rs6000/t-linux
++		case ${target} in
++		*spe*)
++			tmake_file=$tmake_file rs6000/t-spe
++			;;
++		*)
++			tmake_file=$tmake_file rs6000/t-linux
++			;;
++		esac
  		;;
  	esac
  	case ${target} in
@@ -555,7 +562,7 @@
  			  maltivec/mlittle \
  			  maltivec/mabi=altivec/mlittle
 +
-+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1)
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe
 +
 --- a/src/gcc/config/rs6000/t-linux64	(revision 182390)
 +++ b/src/gcc/config/rs6000/t-linux64	(working copy)
--- debian/patches/gcc-multiarch-upstream.diff.orig	2012-12-12 12:00:35.0 +0100
+++ debian/patches/gcc-multiarch-upstream.diff	2012-12-12 13:06:40.0 +0100
@@ -361,7 +361,7 @@
  			  maltivec/mabi=altivec/mlittle
 +
 +ifneq (,$(findstring linux, $(target)))
-+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1)
++MULTIARCH_DIRNAME = powerpc-linux-gnuspe
 +endif
 --- a/src/gcc/config/rs6000/t-fprules	(Revision 193696)
 +++ b/src/gcc/config/rs6000/t-fprules	(Arbeitskopie)
@@ -533,11 +533,18 @@
  	target_cpu_default=MASK_GNU_AS|MASK_GNU_LD
  	;;
  ia64*-*-hpux*)
-@@ -2075,6 +2078,7 @@
+@@ -2075,6 +2078,14 @@
  		;;
  	*)
  		tm_file=${tm_file} rs6000/linux.h glibc-stdint.h
-+		tmake_file=$tmake_file rs6000/t-linux
++		case ${target} in
++		*spe*)
++			tmake_file=$tmake_file rs6000/t-spe
++			;;
++		*)
++			tmake_file=$tmake_file rs6000/t-linux
++			;;
++		esac
  		;;
  	esac
  	case ${target} in