https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34280
Scott McPeak <scott.g.mcpeak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |scott.g.mcpeak at gmail dot com
--- Comment #2 from Scott McPeak <scott.g.mcpeak at gmail dot com> ---
This issue still exists in GCC-12.1.0, and I want to note a few other related
behaviors.
The behavior of -M[M] is inconsistent with that of -E, -S, and -c. For
example, with -c:
$ touch foo.c bar.c
$ gcc -c foo.c bar.c -o combined.o
gcc: fatal error: cannot specify ‘-o’ with ‘-c’, ‘-S’ or ‘-E’ with multiple
files
compilation terminated.
But with -M or -MM:
$ gcc -MM foo.c bar.c -o combined.d
$ cat combined.d
bar.o: bar.c
Also note that the issue affects -MF as well:
$ gcc -MM foo.c bar.c -MF combined.d
$ cat combined.d
bar.o: bar.c
and, consequently, extends to -M[M]D:
$ gcc -c foo.c bar.c -MMD -MF combined.d
$ cat combined.d
bar.o: bar.c
I think (concurring with Andrew) that these combinations ought to be rejected
when there are multiple input files:
* (-M or -MM) and (-o or -MF)
* (-MD or -MMD) and -MF
However, a case can be made to allow those combinations if the specified output
file is "-" (standard output) since that does work, for example:
$ gcc -MM foo.c bar.c -MF -
foo.o: foo.c
bar.o: bar.c
Finally, why does this seemingly obscure bug matter? The GCC command line
language has become a de-facto standard, and a wide variety of software tools
work by interpreting, and in some cases emulating, that language. These tools
need to know about and properly handle dark corners like this one because
someone, somewhere will be relying on it, albeit almost certainly
inadvertently. It would be beneficial to users and tool makers alike for GCC
to take the lead in rejecting nonsensical command line combinations (as it has,
for example, with C++ language conformance, in my perception).
