15220 – [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory (original) (raw)

Description Paul Jarc 2004-04-30 05:52:38 UTC

$ gcc -v Reading specs from /fs/pkgs/mount/package/misc/spf/gcc-3.4.0/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/specs Configured with: ../gcc-3.4.0/configure --prefix=/package/misc/spf/gcc-3.4.0 --disable-nls --enable-libgcj --with-as=/package/misc/spf/gcc-3.4.0/spf/as --with-ld=/package/misc/spf/gcc-3.4.0/spf/ld --enable-threads Thread model: posix gcc version 3.4.0

$ echo $'#include <foo.h>\n#include "bar.h"' | gcc -xc /dev/stdin -E -MM -MG stdin.o: /dev/stdin foo.h bar.h

Previous versions of gcc (I checked 2.95.3, 3.2.3, and 3.3.3) do not include foo.h in the output, which is appropriate, since foo.h would not be searched for in the source directory when actually compiling the file.

Jim Wilson has some ideas: http://gcc.gnu.org/ml/gcc/2004-04/msg01413.html

Comment 1 Drea Pinski 2004-04-30 12:53:54 UTC

Confirmed but something else is a regression from 3.2.3. Before 3.3, GCC used to warn about foo.h being missing so there might be more to what caused it than what Jim thinks.

Comment 2 Giovanni Bajo 2004-06-06 03:54:31 UTC

Retargeting to 3.4.1, being a regression on that release branch.

Comment 3 Mark Mitchell 2004-06-14 17:26:41 UTC

Neil, I'm not going to hold up 3.4.1 for this patch, but would you please take a look at this problem?

Comment 4 Mark Mitchell 2004-08-29 18:50:29 UTC

Postponed until GCC 3.4.3.

Comment 5 Mark Mitchell 2004-11-01 00:44:51 UTC

Postponed until GCC 3.4.4.

Comment 6 Nathanael C. Nerode 2004-11-27 23🔞56 UTC

Ow. The dependencies are emitted in open_file_failed in libcpp/files.c; but that routine doesn't know whether the file was called for in a <> or a "" directive.

Fixing this requires some restructuring of libcpp code so that the dependencies are emitted in a place which does know (perhaps the same place, but that requires a lot of extra information passing).

Comment 7 Neil Booth 2004-11-28 00:50:06 UTC

Subject: Re: [3.3/3.4/4.0 regression] "gcc -E -MM -MG" reports missing system headers in source directory

neroden at gcc dot gnu dot org wrote:-

------- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 23:18 ------- Ow. The dependencies are emitted in open_file_failed in libcpp/files.c; but that routine doesn't know whether the file was called for in a <> or a "" directive.

Fixing this requires some restructuring of libcpp code so that the dependencies are emitted in a place which does know (perhaps the same place, but that requires a lot of extra information passing).

Note that current behaviour was discussed and agreed in a thread in 2003, on a previous bug report about prior behaviour.

Neil.

Comment 8 Eric Botcazou 2004-12-05 09:35:08 UTC

Neil, would you mind updating the status of this bug so that it doesn't appear as a critical regression against 3.4.x and 4.0? If the observed behaviour is the intended one, please close the bug as WONTFIX.

Comment 9 Paul Jarc 2004-12-05 22:40:59 UTC

3.4 is a lost cause by this point, but I'd really like to see this fixed for 4.0. My build system needs this to track dependencies. What exactly was agreed before - the lack of the warning, or the misleading outfor for missing <foo.h> files? (I don't care about the warning.) Got a link to that thread?

Comment 10 James Juran 2004-12-13 18:43:24 UTC

I believe the bug Neil referred to in comment #7 is bug preprocessor/6521 from May 2002.

Comment 11 Paul Jarc 2004-12-13 19:10:23 UTC

Ok, bug preprocessor/6521 looks like it had the same symptom I see now with 3.4. Neil and Zack didn't think it was worth fixing at first, but it did get fixed, and managed to stay fixed through 3.3.

I agree with the comments that it's not very important how -MG handles <> headers, but what does matter to me is that they are not made to look like "" headers. I use "gcc -E -MM -MG foo.c 2> /dev/null" and parse the output to find out which "" headers would need to be generated in order to compile this file. If <> headers are included in that list, I get unnecessary build failures, since some headers that I can't provide appear to be needed (but actually aren't). It would be ok with me if <> headers were ignored entirely for -MG. As it is, they are ignored only if they exist - otherwise, 3.4 gives misleading output, 3.3 is silent, and earlier versions warn.

Comment 12 Steven Bosscher 2005-02-09 10:37:31 UTC

I don't see why this is critical.

Comment 13 Drea Pinski 2005-07-22 21:12:15 UTC

Moving to 4.0.2 pre Mark.

Comment 17 Jim Wilson 2005-11-07 19:49:08 UTC

Subject: [Bug 15220](show%5Fbug.cgi?id=15220 "RESOLVED FIXED - [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory")

Author: wilson Date: Mon Nov 7 19:49:04 2005 New Revision: 106608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106608 Log: Fix problem with -MM -MG and missing system header files. [PR preprocessor/15220](show%5Fbug.cgi?id=15220 "RESOLVED FIXED - [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory")

Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/cppfiles.c branches/gcc-3_4-branch/gcc/cpphash.h branches/gcc-3_4-branch/gcc/cppinit.c

Comment 18 Jim Wilson 2005-11-07 19:51:09 UTC

Mine.

Comment 19 Jim Wilson 2005-11-07 19:52:26 UTC

Fixed on gcc-3.4.x branch, gcc-4.0.x branch, and mainline.