[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mini-patch] Fix a set of warnings
From: |
Tim Van Holder |
Subject: |
Re: [mini-patch] Fix a set of warnings |
Date: |
18 Jun 2001 10:19:48 +0200 |
On 17 Jun 2001 22:11:16 -0600, Tom Tromey wrote:
> >>>>> "Tim" == Tim Van Holder <address@hidden> writes:
>
> Tim> This small patch allows automake to run for the CVS tree
> Tim> of gas without producing these warnings:
> Tim> Use of uninitialized value in substitution (s///) at automake line 1587.
> Tim> Use of uninitialized value in concatenation (.) at automake line 188.
> Tim> Use of uninitialized value in quotemeta at automake line 6972.
>
> Can you tell me a simple way to reproduce this?
>
(BTW, this also occurs in the gas tree of binutils 2.11)
I added some print's around the problem area and got:
Extension: c => c
Loop containing failure completed
Extension: l => lex
Loop containing failure completed
Extension: y => yacc
Loop: ($derived, $source, $obj) = (as_new, config/m68k-parse.y,
m68k-parse)
Use of uninitialized value in substitution (s///) at
/opt/gcc3/bin/automake line 1550.
Use of uninitialized value in concatenation (.) at
/opt/gcc3/bin/automake line 1551.
Use of uninitialized value in quotemeta at /opt/gcc3/bin/automake line
6906.
Loop containing failure completed
So it would seem there is a problem with the yacc setup here (and
indeed, yacc does not have a compiler attribute, and that is what's
being used here).
They do have their own rule for m68k-parse.c:
# The m68k operand parser.
EXTRA_as_new_SOURCES = config/m68k-parse.y
# If m68k-parse.y is in a different directory, then ylwrap will use an
# absolute path when it invokes yacc, which will cause yacc to put the
# absolute path into the generated file. That's a pain when it comes
# to generating snapshots, because it introduces spurious diffs.
# Since when we make the snapshots $(srcdir) = ".", we check for that
# case and handle it differently. This means that anybody who
# configures with $(srcdir) = "." will have to set their path in the
# debugger if they want to debug m68k-parse.y. This is bad, but on
# the other hand it's good that people who use the prebuilt
# m68k-parse.c don't get a spurious absolute path.
m68k-parse.c: $(srcdir)/config/m68k-parse.y
f=$(srcdir)/config/m68k-parse.y; \
if [ $$f = "./config/m68k-parse.y" ]; then \
ln -s config/m68k-parse.y . > /dev/null 2>/dev/null || \
ln config/m68k-parse.y . > /dev/null 2>/dev/null || \
cp config/m68k-parse.y . >/dev/null 2>/dev/null; \
f=m68k-parse.y; \
else true; fi; \
$(SHELL) $(YLWRAP) "$(YACC)" $$f y.tab.c m68k-parse.c --; \
if [ $$f = "m68k-parse.y" ]; then \
rm -f m68k-parse.y; \
else true; fi
m68k-parse.o: m68k-parse.c $(srcdir)/config/m68k-parse.h
# Don't let the .y.h rule clobber m68k-parse.h.
m68k-parse.h: ; @true
$(srcdir)/config/m68k-parse.h: ; @true
--
Tim Van Holder - Anubex N.V.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was posted using plain text. I do not endorse any
products or services that may be hyperlinked to this message.