https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105603
Bug ID: 105603
Summary: Manual incorrectly says -MD -E -o specifies dependency
output file
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: scott.g.mcpeak at gmail dot com
Target Milestone: ---
In the current documentation for preprocessor options:
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
under the description of the -MD switch, it says:
If -MD is used in conjunction with -E, any -o switch is understood to
specify the dependency output file (see -MF), but if used without -E,
each -o is understood to specify a target object file.
At least with current GCC-12.1.0 (also confirmed with GCC-9.3.0), this
is simply false. The -MD switch does dependency generation in addition
to normal operation, which for -E means preprocessing and sending that
output to -o:
$ mkdir tmp; cd tmp
$ echo 'int x;' > foo.c
$ gcc -MD -E -o foo.i foo.c
$ ls
foo.c foo.d foo.i
$ cat foo.i # foo.i is pp output
[...]
# 1 "foo.c"
int x;
$ cat foo.d # dependencies written to foo.d
foo.o: foo.c /usr/include/stdc-predef.h
There is nothing special about the -MD -E -o combination; each of the
switches is behaving in its usual, orthogonal way.
Now, I speculate that the author intended to describe -M/-MM, since with
those switches, the primary output of the compiler is dependency
information, and consequently -o says where it goes:
$ rm *.d *.i
$ gcc -M -E -o foo.d foo.c
$ ls
foo.c foo.d
$ cat foo.d
foo.o: foo.c /usr/include/stdc-predef.h
However, even here, there is nothing special going on. -M -E is simply
equivalent to -M alone, and -o is doing its usual job of specifying
where to put the primary output.
Therefore, I think this paragraph should simply be deleted.
Tangentially, I'll note that the equivalence of "-M -E" and "-M" is not
clearly documented, but that's part of a more general behavior of the
precedence chain of -M[M] > -E > -S > -c, which probably should be
documented, but not in the vicinity of the topic of this bug report.
For completeness, I observe this on "Target: x86_64-pc-linux-gnu".
