Committed, MAINTAINERS, sim/cris: Fix make -j race and mark cris-elf as non-broken, cp-name-parser.y

Committed, MAINTAINERS, sim/cris: Fix make -j race and mark cris-elf as non-broken, cp-name-parser.y

[Hans-Peter Nilsson]

Committed.  The MAINTAINERS bit is committed as obvious as the
sim/cris patch fixes the breakage reported by Andrew Cagney in
<URL:http://sourceware.org/ml/gdb-patches/2005-05/msg00471.html>:
the line in MAINTAINERS is misleading and was found to refer to
an earlier problem Andrew ran into, since then fixed.  Besides
testing for the particular problem fixed below (a sim checkout),
I tried to run a "gdb_mbuild.sh -e cris-elf -j 2 src obj" on a
x86_64-unknown-linux-gnu (FC4t2) with the MAINTAINERS and
sim/cris patches, but that failed with:

cc1: warnings being treated as errors
cp-name-parser.y: In function 'parse_escape':
cp-name-parser.y:1443: warning: 'target_char' may be used
uninitialized in this function

in the gdb directory.  I looked at that problem and concluded
the patch to cp-name-parser.y as an obvious fix.  The warning
came from gcc-4.0.0-2 and looks correct; the c_parse_backslash
is a static function and apparently the code *has* that problem;
it's not a false positive.  It takes two looks.  Then I ran into:

cc1: warnings being treated as errors
/home/hp/simj/src/gdb/source.c: In function '_initialize_source':
/home/hp/simj/src/gdb/source.c:1649: warning: pointer targets in
passing argument 3 of 'add_setshow_uinteger_cmd' differ in
signedness

but this time, I give up and just blindly commit what I
have<rant> as that was obviously the level of testing that was
done when the change exposing that warning was committed</rant>.

gdb:
	* MAINTAINERS: Change cris-elf state to non-broken.
	* cp-name-parser.y (parse_escape): Initialize target_char to zero.

sim:
	* cris/Makefile.in (stamp-v32fmloop): Depend on stamp-v10fmloop.

Index: cp-name-parser.y
===================================================================
RCS file: /cvs/src/src/gdb/cp-name-parser.y,v
retrieving revision 1.1
diff -p -u -r1.1 cp-name-parser.y
--- cp-name-parser.y	12 May 2005 16:01:08 -0000	1.1
+++ cp-name-parser.y	28 May 2005 08:31:18 -0000
@@ -1440,7 +1440,7 @@ c_parse_backslash (int host_char, int *t
 static int
 parse_escape (const char **string_ptr)
 {
-  int target_char;
+  int target_char = 0;
   int c = *(*string_ptr)++;
   if (c_parse_backslash (c, &target_char))
     return target_char;
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.317
diff -p -u -r1.317 MAINTAINERS
--- MAINTAINERS	27 May 2005 04:51:52 -0000	1.317
+++ MAINTAINERS	28 May 2005 08:05:25 -0000
@@ -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
 
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/sim/cris/Makefile.in,v
retrieving revision 1.2
diff -p -u -r1.2 Makefile.in
--- Makefile.in	24 Mar 2005 06:12:41 -0000	1.2
+++ Makefile.in	28 May 2005 07:56:03 -0000
@@ -103,7 +103,9 @@ crisv32f.o: crisv32f.c cris-tmpl.c $(CRI
 # FIXME: What is mono and what does "Use of `mono' is wip" mean (other
 # than the apparent; some "mono" feature is work in progress)?
 mloopv32f.c engv32.h: stamp-v32fmloop
-stamp-v32fmloop: $(srcdir)/../common/genmloop.sh mloop.in Makefile
+# We depend on stamp-v10fmloop to get serialization to avoid
+# racing with it for the same temporary file-names when "make -j".
+stamp-v32fmloop: stamp-v10fmloop $(srcdir)/../common/genmloop.sh mloop.in Makefile
 	$(SHELL) $(srccom)/genmloop.sh \
 		-mono -no-fast -pbb -switch semcrisv32f-switch.c \
 		-cpu crisv32f -infile $(srcdir)/mloop.in

brgds, H-P

Re: Committed, MAINTAINERS, sim/cris: Fix make -j race and mark cris-elf as non-broken, cp-name-parser.y

[Daniel Jacobowitz]

Please don't commit unrelated changes together in the future.

On Sat, May 28, 2005 at 10:58:31AM +0200, Hans-Peter Nilsson wrote:
> cc1: warnings being treated as errors
> cp-name-parser.y: In function 'parse_escape':
> cp-name-parser.y:1443: warning: 'target_char' may be used
> uninitialized in this function
> 
> in the gdb directory.  I looked at that problem and concluded
> the patch to cp-name-parser.y as an obvious fix.  The warning
> came from gcc-4.0.0-2 and looks correct; the c_parse_backslash
> is a static function and apparently the code *has* that problem;
> it's not a false positive.  It takes two looks.  Then I ran into:

Maybe it takes three?  Your patch is incorrect, since it is covering up
a real problem.  It ought to be "return c".

> cc1: warnings being treated as errors
> /home/hp/simj/src/gdb/source.c: In function '_initialize_source':
> /home/hp/simj/src/gdb/source.c:1649: warning: pointer targets in
> passing argument 3 of 'add_setshow_uinteger_cmd' differ in
> signedness
> 
> but this time, I give up and just blindly commit what I
> have<rant> as that was obviously the level of testing that was
> done when the change exposing that warning was committed</rant>.

Hello?  Please think for a moment or read the beginning of the gdb_byte
discussion.  Most of us have not started using GCC 4.0.0 yet, and even
Andrew hadn't in February.  Earlier versions didn't produce that
warning.

It's quite well known by now that GDB does not build using GCC 4.0.0
and -Werror.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Committed, MAINTAINERS, sim/cris: Fix make -j race and mark cris-elf as non-broken, cp-name-parser.y

[Daniel Jacobowitz]

On Sat, May 28, 2005 at 10:22:27AM -0400, Daniel Jacobowitz wrote:
> On Sat, May 28, 2005 at 10:58:31AM +0200, Hans-Peter Nilsson wrote:
> > cc1: warnings being treated as errors
> > cp-name-parser.y: In function 'parse_escape':
> > cp-name-parser.y:1443: warning: 'target_char' may be used
> > uninitialized in this function
> > 
> > in the gdb directory.  I looked at that problem and concluded
> > the patch to cp-name-parser.y as an obvious fix.  The warning
> > came from gcc-4.0.0-2 and looks correct; the c_parse_backslash
> > is a static function and apparently the code *has* that problem;
> > it's not a false positive.  It takes two looks.  Then I ran into:
> 
> Maybe it takes three?  Your patch is incorrect, since it is covering up
> a real problem.  It ought to be "return c".

Like so.  Checked with GCC 4.1.0 20050508 and committed.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-05-28  Daniel Jacobowitz  <dan@codesourcery.com>

	* cp-name-parser.y (parse_escape): Revert previous change.  Return
	the input character by default.

Index: cp-name-parser.y
===================================================================
RCS file: /cvs/src/src/gdb/cp-name-parser.y,v
retrieving revision 1.2
diff -u -p -r1.2 cp-name-parser.y
--- cp-name-parser.y	28 May 2005 08:49:13 -0000	1.2
+++ cp-name-parser.y	28 May 2005 16:47:46 -0000
@@ -1440,7 +1440,7 @@ c_parse_backslash (int host_char, int *t
 static int
 parse_escape (const char **string_ptr)
 {
-  int target_char = 0;
+  int target_char;
   int c = *(*string_ptr)++;
   if (c_parse_backslash (c, &target_char))
     return target_char;
@@ -1498,7 +1498,7 @@ parse_escape (const char **string_ptr)
 	  return i;
 	}
       default:
-	return target_char;
+	return c;
       }
 }
 

Re: cp-name-parser.y

[Hans-Peter Nilsson]

> Date: Sat, 28 May 2005 12:49:59 -0400
> From: Daniel Jacobowitz <drow@false.org>

> On Sat, May 28, 2005 at 10:22:27AM -0400, Daniel Jacobowitz wrote:
> > On Sat, May 28, 2005 at 10:58:31AM +0200, Hans-Peter Nilsson wrote:
> > > It takes two looks.
> > 
> > Maybe it takes three?

Probably; I incorrectly assumed that the code that person wrote
was correct to the main parts and didn't review it's semantics.
I hope to avoid that in the future. :-)

>  Your patch is incorrect, since it is covering up
> > a real problem.  It ought to be "return c".
> 
> Like so.  Checked with GCC 4.1.0 20050508 and committed.

Thanks.

brgds, H-P