This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch]: set $(STRICT_WARN) for "build" object files

It seems that all the "build" object files are now placed in a
subdirectory "build/" on mainline.  This confuses the warning flag
mechanism in GCC's Makefile and causes these files to be built without
$(STRICT_WARN) and we lose having "-pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Werror" for these files
in stage2 and stage3.

If I remember correctly how this hack works, in $(GCC_WARN_CFLAGS) we
rely on the @D in $($(@D)-warn) resolving to "." and therefore we pull
in the $(.-warn) make variable set above.  However now @D is set to
"build" and thus the uninitialized $(build-warn) variable is obtained.
So we simply have to set $(build-warn) to fix this.

The following appears to do the trick.  Bootstrapped on
i686-unknown-linux-gnu, and I visually inspected the output log to see
that the additional flags were applied to the "build" files.

Ok for mainline?


2005-01-10  Kaveh R. Ghazi  <>

	* Set a `build-warn' variable.

diff -rup orig/egcc-CVS20050109/gcc/ egcc-CVS20050109/gcc/
--- orig/egcc-CVS20050109/gcc/	2005-01-05 21:21:27.000000000 -0500
+++ egcc-CVS20050109/gcc/	2005-01-10 10:36:09.000000000 -0500
@@ -184,6 +184,7 @@ VALGRIND_DRIVER_DEFINES = @valgrind_path
 # This is how we control whether or not the additional warnings are applied.
 .-warn = $(STRICT_WARN)
+build-warn = $(STRICT_WARN)
 GCC_WARN_CFLAGS = $(LOOSE_WARN) $($(@D)-warn) $(NOCOMMON_FLAG) $($@-warn)
 # These files are to have -Werror bypassed in stage2:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]