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".