[commit] note non-building architectures

[commit] note non-building architectures

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

As part of getting ready for GCC 4, I've found that a number of arches 
don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to 
stop me and presumably others from going round in circles, I've updated 
the MAINTAINERS file to both reflect current reality note the problem.

I look forward to seeing real fixes (which are hopefully both simple and 
obvious and can be committed as such).

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1999 bytes --]

2005-05-01  Andrew Cagney  <cagney@gnu.org>

	* MAINTAINERS: Note that cris, m68k, mn10300, sh64, sparc and vax
	do not build.

Index: gdb/MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.313
diff -p -u -r1.313 MAINTAINERS
--- gdb/MAINTAINERS	29 Apr 2005 14:21:21 -0000	1.313
+++ gdb/MAINTAINERS	1 May 2005 23:06:55 -0000
@@ -67,13 +67,14 @@ the native maintainer when resolving ABI
 	avr		--target=avr ,-Werror
 			Theodore A. Roth	troth@openavr.org
 
-	cris		--target=cris-elf ,-Werror
+	cris		--target=cris-elf broken
+			(sim/cris/modelv10.c:4181 crisv10f_engine_run_full?)
 
 	d10v		OBSOLETE
 
 	frv		--target=frv-elf ,-Werror
 
-	h8300		--target=h8300-elf, -Werror
+	h8300		--target=h8300-elf ,-Werror
 
 	i386		--target=i386-elf ,-Werror
 			Mark Kettenis           kettenis@gnu.org
@@ -87,7 +88,8 @@ the native maintainer when resolving ABI
 	m68hc11		--target=m68hc11-elf ,-Werror ,
 			Stephane Carrez		stcarrez@nerim.fr
 
-	m68k		--target=m68k-elf ,-Werror
+	m68k		--target=m68k-elf broken
+			(opcodes/m68k-dis.c:338 longjmp clober)
 
 	m88k		--target=m88k-openbsd ,-Werror
 			Mark Kettenis		kettenis@gnu.org
@@ -96,7 +98,8 @@ the native maintainer when resolving ABI
 
 	mips		--target=mips-elf ,-Werror
 
-	mn10300		--target=mn10300-elf
+	mn10300		--target=mn10300-elf broken
+			(sim/ dies with make -j)
 			Michael Snyder		msnyder@redhat.com
 
 	ns32k		Deleted
@@ -108,13 +111,16 @@ the native maintainer when resolving ABI
 	s390		--target=s390-linux-gnu ,-Werror
 
 	sh		--target=sh-elf ,-Werror
-			--target=sh64-elf ,-Werror
+			--target=sh64-elf broken
+			(sim/ dies)
 
-	sparc		--target=sparc-elf ,-Werror
+	sparc		--target=sparc-elf broken
+			(bfd/elfxx-sparc:512 bfd_elf64_swap_reloca_out undef)
 
 	v850		Deleted
 
-	vax		--target=vax-netbsd ,-Werror
+	vax		--target=vax-netbsd broken
+			(opcodes/vax-dis.c:224 longjmp clober)
 
 	x86-64		--target=x86_64-linux-gnu ,-Werror
 

Re: [commit] note non-building architectures

[Mark Kettenis]

   Date: Sun, 01 May 2005 19:11:47 -0400
   From: Andrew Cagney <cagney@gnu.org>

   As part of getting ready for GCC 4, I've found that a number of arches 
   don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to 
   stop me and presumably others from going round in circles, I've updated 
   the MAINTAINERS file to both reflect current reality note the problem.

I think your GCC 3.4 is busted.  I must admit that I don't really
understand that longjmp clobber warning message is warning about
exactly, but returning -1 immediately after a setjmp() call when that
has been jumped to, seems entirely safe to me.

   -	m68k		--target=m68k-elf ,-Werror
   +	m68k		--target=m68k-elf broken
   +			(opcodes/m68k-dis.c:338 longjmp clober)

   -	vax		--target=vax-netbsd ,-Werror
   +	vax		--target=vax-netbsd broken
   +			(opcodes/vax-dis.c:224 longjmp clober)

Mark

Re: [commit] note non-building architectures

[Andreas Schwab]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:

>    Date: Sun, 01 May 2005 19:11:47 -0400
>    From: Andrew Cagney <cagney@gnu.org>
>
>    As part of getting ready for GCC 4, I've found that a number of arches 
>    don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to 
>    stop me and presumably others from going round in circles, I've updated 
>    the MAINTAINERS file to both reflect current reality note the problem.
>
> I think your GCC 3.4 is busted.  I must admit that I don't really
> understand that longjmp clobber warning message is warning about
> exactly, but returning -1 immediately after a setjmp() call when that
> has been jumped to, seems entirely safe to me.

This is GCC PR21059.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [commit] note non-building architectures

[Andrew Cagney]

Mark Kettenis wrote:
>    Date: Sun, 01 May 2005 19:11:47 -0400
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    As part of getting ready for GCC 4, I've found that a number of arches 
>    don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to 
>    stop me and presumably others from going round in circles, I've updated 
>    the MAINTAINERS file to both reflect current reality note the problem.
> 
> I think your GCC 3.4 is busted.

My GCC?  What a strange turn of expression.  I'm pretty sure the warning 
will also happen with your gcc.

Anyway, given that these problems are occuring in binutils directories 
and hence cause binutils builds to also fail,  and the thing to do is 
persue the problem there.

Andrew


 > I must admit that I don't really
> understand that longjmp clobber warning message is warning about
> exactly, but returning -1 immediately after a setjmp() call when that
> has been jumped to, seems entirely safe to me.
> 
>    -	m68k		--target=m68k-elf ,-Werror
>    +	m68k		--target=m68k-elf broken
>    +			(opcodes/m68k-dis.c:338 longjmp clober)
> 
>    -	vax		--target=vax-netbsd ,-Werror
>    +	vax		--target=vax-netbsd broken
>    +			(opcodes/vax-dis.c:224 longjmp clober)
> 
> Mark
> 

Re: [commit] note non-building architectures

[Mark Kettenis]

   Date: Mon, 02 May 2005 11:57:10 -0400
   From: Andrew Cagney <cagney@gnu.org>

   Mark Kettenis wrote:
   >    Date: Sun, 01 May 2005 19:11:47 -0400
   >    From: Andrew Cagney <cagney@gnu.org>
   > 
   >    As part of getting ready for GCC 4, I've found that a number of arches 
   >    don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to 
   >    stop me and presumably others from going round in circles, I've updated 
   >    the MAINTAINERS file to both reflect current reality note the problem.
   > 
   > I think your GCC 3.4 is busted.

   My GCC?  What a strange turn of expression.  I'm pretty sure the warning 
   will also happen with your gcc.

Nope, 2.95.3 and 3.3.5 are fine.  And as Andreas Schwab there's a GCC
bug report for this problem.  Alas, this is not an ideal world where
compiler warnings involve no false positives.

This will probably be fixed eventually, either on the GCC side, or by
adding a workaround to BFD.  Meanwhile I want us to take notice that
the fact that vax and m68k are in pretty good shape and that listing
them as broken in MAINTAINERS is no indication that there is something
wrong with those targets themselves.

Mark

Re: [commit] note non-building architectures

[Stan Shebs]

Mark Kettenis wrote:

>   Date: Mon, 02 May 2005 11:57:10 -0400
>   From: Andrew Cagney <cagney@gnu.org>
>
>   Mark Kettenis wrote:
>   >    Date: Sun, 01 May 2005 19:11:47 -0400
>   >    From: Andrew Cagney <cagney@gnu.org>
>   > 
>   >    As part of getting ready for GCC 4, I've found that a number of arches 
>   >    don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to 
>   >    stop me and presumably others from going round in circles, I've updated 
>   >    the MAINTAINERS file to both reflect current reality note the problem.
>   > 
>   > I think your GCC 3.4 is busted.
>
>   My GCC?  What a strange turn of expression.  I'm pretty sure the warning 
>   will also happen with your gcc.
>
>Nope, 2.95.3 and 3.3.5 are fine.  And as Andreas Schwab there's a GCC
>bug report for this problem.  Alas, this is not an ideal world where
>compiler warnings involve no false positives.
>
>This will probably be fixed eventually, either on the GCC side, or by
>adding a workaround to BFD.  Meanwhile I want us to take notice that
>the fact that vax and m68k are in pretty good shape and that listing
>them as broken in MAINTAINERS is no indication that there is something
>wrong with those targets themselves.
>
Perhaps the status note could be enhanced to say
"builds with -Wno-error" or some such.

Stan

Re: [commit] note non-building architectures

[Hans-Peter Nilsson]

On Sun, 1 May 2005, Andrew Cagney wrote:

> As part of getting ready for GCC 4, I've found that a number of arches
> don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to
> stop me and presumably others from going round in circles, I've updated
> the MAINTAINERS file to both reflect current reality note the problem.

Eh... What is your current reality and why don't I see the
problem you see for cris-elf that warrants marking it as broken?

There was a build issue before for sim/cris, but it's been fixed
to the best of my knowledge.  (FWIW in a hackish way, but with
the same effect to the generated sim/cris files as a proper fix.
The proper fix has been ok'd by fche FWIW, I just haven't
regened all CGEN files for all other simulators and tested them;
it's kind of low-priority.)  That issue seems to match what you
allude to by "(sim/cris/modelv10.c:4181
crisv10f_engine_run_full?)"

I build sim/cris just now (beware, cutnpaste with wrapping):
/tmp/hptmp/src/configure --target=cris-axis-elf && make all
... in short, no problems.

I also built with gdb_mbuild.sh same host, no problems:
...
cris-elf ...
... /tmp/hptmp/src/configure --target=cris-elf --enable-gdb-build-warnings=,-Werror --enable-sim-build-warnings=,-Werror
... make cris-elf
... run cris-elf
... cleanup cris-elf
... cris-elf built
...

Of course, that was with this obvious patch to make
gdb_mbuild.sh build cris-elf (at least it *seemed* necessary):

--- /home/hp/combined/src/src/gdb/MAINTAINERS	Mon May  9 21:45:37 2005
+++ ./MAINTAINERS	Tue May 10 03:23:30 2005
@@ -67,8 +67,7 @@ the native maintainer when resolving ABI
 	avr		--target=avr ,-Werror
 			Theodore A. Roth	troth@openavr.org

-	cris		--target=cris-elf broken
-			(sim/cris/modelv10.c:4181 crisv10f_engine_run_full?)
+	cris		--target=cris-elf ,-Werror

 	d10v		OBSOLETE


And that's a gcc-3.4 on a i686:
hydra-13:hp:~: rpm -q gcc
gcc-3.4.2-6.fc3
hydra-13:hp:/tmp/hptmp/obj: gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking
--with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

I've also build with the configure line above (in a gcc-combined
tree) on x86_64-unknown-linux-gnu (FC4t2, which uses a
gcc-4.0-derivate: gcc-4.0.0-2). No problems.  Same thing on i686
FC2, (gcc-3.3.3-7) no problems.

What problem do you see and on what host, and have you updated
since Mar 24 with no local patches, at least none related to the
cris-elf build issue mentioned above?

brgds, H-P

Re: [commit] note non-building architectures

[Andrew Cagney]

Hans-Peter Nilsson wrote:

Just FYI, I currently see:

  -I/home/cagney/PENDING/Werror/src/sim/cris -I../common 
-I/home/cagney/PENDING/Werror/src/sim/cris/../common -I../../include 
-I/home/cagney/PENDING/Werror/src/sim/cris/../../include -I../../bfd 
-I/home/cagney/PENDING/Werror/src/sim/cris/../../bfd -I../../opcodes 
-I/home/cagney/PENDING/Werror/src/sim/cris/../../opcodes -I../../intl 
-I/home/cagney/PENDING/Werror/src/sim/cris/../../intl -g -O 
/home/cagney/PENDING/Werror/src/sim/cris/arch.c
/bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../common/genmloop.sh \
         -mono -no-fast -pbb -switch semcrisv10f-switch.c \
         -cpu crisv10f -infile 
/home/cagney/PENDING/Werror/src/sim/cris/mloop.in
/bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../common/genmloop.sh \
         -mono -no-fast -pbb -switch semcrisv32f-switch.c \
         -cpu crisv32f -infile 
/home/cagney/PENDING/Werror/src/sim/cris/mloop.in
/bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../../move-if-change 
eng.hin engv10.h
/bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../../move-if-change 
mloop.cin mloopv10f.c
mv: cannot stat `mloop.cin': No such file or directory
gmake[2]: *** [stamp-v10fmloop] Error 1


> On Sun, 1 May 2005, Andrew Cagney wrote:
> 
> 
>>As part of getting ready for GCC 4, I've found that a number of arches
>>don't build with gcc-3.4 when using gdb_mbuild.sh.  As an aid, and to
>>stop me and presumably others from going round in circles, I've updated
>>the MAINTAINERS file to both reflect current reality note the problem.
> 
> 
> Eh... What is your current reality and why don't I see the
> problem you see for cris-elf that warrants marking it as broken?
> 
> There was a build issue before for sim/cris, but it's been fixed
> to the best of my knowledge.  (FWIW in a hackish way, but with
> the same effect to the generated sim/cris files as a proper fix.
> The proper fix has been ok'd by fche FWIW, I just haven't
> regened all CGEN files for all other simulators and tested them;
> it's kind of low-priority.)  That issue seems to match what you
> allude to by "(sim/cris/modelv10.c:4181
> crisv10f_engine_run_full?)"
> 
> I build sim/cris just now (beware, cutnpaste with wrapping):
> /tmp/hptmp/src/configure --target=cris-axis-elf && make all
> ... in short, no problems.
> 
> I also built with gdb_mbuild.sh same host, no problems:
> ...
> cris-elf ...
> ... /tmp/hptmp/src/configure --target=cris-elf --enable-gdb-build-warnings=,-Werror --enable-sim-build-warnings=,-Werror
> ... make cris-elf
> ... run cris-elf
> ... cleanup cris-elf
> ... cris-elf built
> ...
> 
> Of course, that was with this obvious patch to make
> gdb_mbuild.sh build cris-elf (at least it *seemed* necessary):
> 
> --- /home/hp/combined/src/src/gdb/MAINTAINERS	Mon May  9 21:45:37 2005
> +++ ./MAINTAINERS	Tue May 10 03:23:30 2005
> @@ -67,8 +67,7 @@ the native maintainer when resolving ABI
>  	avr		--target=avr ,-Werror
>  			Theodore A. Roth	troth@openavr.org
> 
> -	cris		--target=cris-elf broken
> -			(sim/cris/modelv10.c:4181 crisv10f_engine_run_full?)
> +	cris		--target=cris-elf ,-Werror
> 
>  	d10v		OBSOLETE
> 
> 
> And that's a gcc-3.4 on a i686:
> hydra-13:hp:~: rpm -q gcc
> gcc-3.4.2-6.fc3
> hydra-13:hp:/tmp/hptmp/obj: gcc -v
> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
> Configured with: ../configure --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --enable-shared --enable-threads=posix --disable-checking
> --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
> 
> I've also build with the configure line above (in a gcc-combined
> tree) on x86_64-unknown-linux-gnu (FC4t2, which uses a
> gcc-4.0-derivate: gcc-4.0.0-2). No problems.  Same thing on i686
> FC2, (gcc-3.3.3-7) no problems.
> 
> What problem do you see and on what host, and have you updated
> since Mar 24 with no local patches, at least none related to the
> cris-elf build issue mentioned above?
> 
> brgds, H-P
> 

Re: [commit] note non-building architectures

[Hans-Peter Nilsson]

On Thu, 19 May 2005, Andrew Cagney wrote:

> /bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../common/genmloop.sh \
>          -mono -no-fast -pbb -switch semcrisv10f-switch.c \
>          -cpu crisv10f -infile
> /home/cagney/PENDING/Werror/src/sim/cris/mloop.in
> /bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../common/genmloop.sh \
>          -mono -no-fast -pbb -switch semcrisv32f-switch.c \
>          -cpu crisv32f -infile
> /home/cagney/PENDING/Werror/src/sim/cris/mloop.in
> /bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../../move-if-change
> eng.hin engv10.h
> /bin/sh /home/cagney/PENDING/Werror/src/sim/cris/../../move-if-change
> mloop.cin mloopv10f.c
> mv: cannot stat `mloop.cin': No such file or directory
> gmake[2]: *** [stamp-v10fmloop] Error 1

Hmm, this seems like a parallel make breaking on a rule not
handling building in parallel.  Oops.

It would *really* have helped to know that before, as simple as
mentioning how you invoked gdb_mbuild.sh.  Bug-report details,
you know...  It also disagrees a bit with the breakage note you
put in MAINTAINERS: "(sim/cris/modelv10.c:4181
crisv10f_engine_run_full?)" which tricked me into thinking you
were seeing the previous problem still.

I'll see to fixing that, and then revert the "breakage" note for
the CRIS port in MAINTAINERS.

brgds, H-P