preprocessor/3951: need for -MF w/ -M breaks backward compat. w/ documentedfeatures.

preprocessor/3951: need for -MF w/ -M breaks backward compat. w/ documentedfeatures.

[cgd]

>Number:         3951
>Category:       preprocessor
>Synopsis:       need for -MF w/ -M breaks backward compat. w/ documented features.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 06 16:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Chris G. Demetriou
>Release:        3.0
>Organization:
Broadcom Corp.
>Environment:
System: SunOS xxx 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4
host: sparc-sun-solaris2.7
build: sparc-sun-solaris2.7
target: sparc-sun-solaris2.7
configured with: ../gcc/configure --enable-languages=c --prefix=/users/cgd/proj/gnu/current/nat/../nat.install
>Description:
	The need for the -MF flag to place dependency output in a file
	breaks backward compatibility with historical dependency generation
	into a file using -o.  Reading an old version of the manual
	(e.g. for 2.95.3), use of -o is reasonably understood to be
	"documented" and supported, specifically (see
	http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC2 ):

	* In the description of -M, "The list of rules is printed on
	standard output instead of the preprocessed C program.  -M
	implies -E."  That can and was reasonably construed by developers
	to mean that "-M output goes the same place as -E output".

	* In the description of -E, "Preprocess all the C source files
	specified and output the results to standard output or to the
	specified output file."

	* In the description of -o, "Place output in file file. This
	applies _regardless to whatever sort of output is being produced_,
	whether it be an executable file, an object file, an assembler
	file or preprocessed C code."  (emphasis mine.)


	So, if you believe -o, the output of -M is output and isn't
	otherwise specially described, so it should go to whever -o
	specifies.

	If you follow the chain of logic that goes with "dependencies
	generated by -M go where the preprocessor output would go" you
	reach the same conclusion.


	Various third-party developers of code (at least some not
	open-source, even!) used -M -o in their makefiles to generate
	dependency files.  I.e., this is a real compatibility problem.
	(I didn't trip over it myself, it was brought to my attention
	by a user I support.)

	There has been no backward-compatibility time, etc., when the
	old behaviour still worked but was marked as deprecated.  Proper
	functioning of '-o' simply disappeared in the 3.0 release (if
	your point of reference is the previous release, rather than a
	development snapshot, of course 8-).

	Also, since -MF wasn't present in older releases of
	the compiler and -o actually seems to produce _different output_,
	there's no way to make a Makefile work with old
	and new versions of the compiler short of explicitly testing
	for the compiler version and using different flags and possibly
	additional post-processing.  That makes it harder to support use
	of multiple versions of GCC.

	Finally, with the new behaviour there's no obvious way short of
	saying something like:

		gcc -M -MF file.d -o /dev/null file.c

	to just _toss_ the preprocessor output and only generate dependencies.
	Given that oftentimes the -M options are used solely to generate
	dependencies, that seems ... less than desirable.  (Is "/dev/null"
	a portable construct?  I wouldn't think so...)

>How-To-Repeat:

	With a previous version of GCC do:

		echo "#include <stdlib.h>" > foo.c
		gcc -M -o foo.d foo.c

	note that the dependencies are now in foo.d, and the target with
	dependencies is foo.o.

	Do the same with GCC 3.0.  Note that dependencies have been
	spit out on stdout, the target with dependencies is foo.d (!!),
	and foo.d has not been created.

	Try to get makefiles (which may or may not be GNU-make friendly) to
	cope with these multiple versions of gcc.

>Fix:
	Change the behaviour back to what it used to be?

	Error out if -o and -M are specified, at least for a few
	releases, rather than producing unexpected output?  (That doesn't
	solve makefile compatibility issues, but it could make the
	problem much clearer, and therefore make them easier to debug.)

>Release-Note:
>Audit-Trail:
>Unformatted: