Re: preprocessor/6521: -MG creates dependency with wrong path

Re: preprocessor/6521: -MG creates dependency with wrong path

[Zack Weinberg]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Robert Spier <rspier@pobox.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org, Andreas Jaeger <aj@suse.de>,
	Roland McGrath <roland@frob.com>
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 00:03:45 -0700

 On Wed, May 08, 2002 at 07:36:46AM +0100, Neil Booth wrote:
 > Robert Spier wrote:-
 > 
 > > The only sensible patch I can think of is to remove this odd
 > > functionality entirely.
 > > 
 > > The below patch unifies handling for system and non-system include
 > > files and removes the special case.  It only affects -MG, and brings
 > > it in line with the documentation:
 > > 
 > >       -MG When used with -M or -MM, -MG says to treat missing
 > >            header files as generated files and assume they live
 > >            in the same directory as the source file.  It sup?
 > >            presses preprocessed output, as a missing header file
 > >            is ordinarily an error.
 > 
 > On further reflection, I don't think this makes any sense.
 > Files included with <> do not search the current directory,
 > so assuming the file lies there is obviously bogus.
 
 Odds are anyone including generated files with <> is using -I. or
 similar.
 
 > The sensible thing to do, IMO, is to step down the <> include path
 > until the resulting path, when appending the file name, exists, and
 > to fail if all such paths don't exist.
 
 I'm not entirely sure I understand this.
 
 I've never really liked -MG; it is too inflexible.  With <> it does
 something fairly silly, as Robert points out; but with "" it does
 something equally silly, which is to assume that splatting whatever
 string the user provided into the dependency list will work.  (It does
 _not_ assume they live in the same directory as the source file;
 consider split source and build trees.  The current behavior is
 more likely to work in practice than the documented one, but...
 
 The behavior under discussion predates cpplib, incidentally.
 
 It seems to me that we should leave -MG alone, since there are
 undoubtedly Makefiles out there depending on every last quirk of its
 semantics (remember all the fallout the last time we decided to
 improve the semantics of the -M switches?).  We should instead come up
 with a new way to do it that lets the user say where the generated
 file is expected to turn up... perhaps -Mx <path> puts all the
 dependencies on generated files in <path>.  (Where 'x' is some
 appropriate letter; I am too tired to think of a good one right now.)
 
 Come to think of it, -MG and -MP clash.  We should mark entries added
 to the list by -MG and not generate phony targets for them under -MP,
 or Make will pitch a fit about multiple rules for the same target.
 
 zw

Re: preprocessor/6521: -MG creates dependency with wrong path

[Robert Spier]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: rspier@pobox.com (Robert Spier)
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Zack Weinberg <zack@codesourcery.com>, gcc-gnats@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 14:34:55 -0700

 Looks good to me.
 
 Thank You!
 
 >OK, I've applied this.
 
 <snip patch>
 
 

Re: preprocessor/6521: -MG creates dependency with wrong path

[neil]

Synopsis: -MG creates dependency with wrong path

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Wed May  8 14:33:45 2002
State-Changed-Why:
    Fixed.  Thanks for the PR and patch!

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6521

Re: preprocessor/6521: -MG creates dependency with wrong path

[Neil Booth]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Robert Spier <rspier@pobox.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 22:25:03 +0100

 Zack Weinberg wrote:-
 
 > > > Robert, would you be willing to clarify the documentation?
 > > 
 > > OK, I'll apply Robert's patch.  What do you feel is unclear about
 > > the docs?  The fact that it refers to "current directory"?
 > 
 > Precisely.
 > 
 > I'm not sure how best to clarify it, without rewriting all the stuff
 > about dependency output (which needs doing, but I don't have time
 > now).
 
 OK, I've applied this.
 
 Neil.
 
 2002-05-08  Robert Spier <rspier@pobox.com>
 	    Neil Booth  <neil@daikokuya.demon.co.uk>
 
 	PR preprocessor/6521
 	* cppfiles.c (handle_missing_header): Don't do anything
 	different for <> includes.
 doc:
 	* cppopts.texi: Update documentation for -MG.
 
 Index: cppfiles.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/cppfiles.c,v
 retrieving revision 1.147
 diff -u -p -r1.147 cppfiles.c
 --- cppfiles.c	22 Apr 2002 17:48:01 -0000	1.147
 +++ cppfiles.c	8 May 2002 21:15:19 -0000
 @@ -658,30 +658,7 @@ handle_missing_header (pfile, fname, ang
    int print_dep = CPP_PRINT_DEPS(pfile) > (angle_brackets || pfile->map->sysp);
  
    if (CPP_OPTION (pfile, print_deps_missing_files) && print_dep)
 -    {
 -      if (!angle_brackets || IS_ABSOLUTE_PATHNAME (fname))
 -	deps_add_dep (pfile->deps, fname);
 -      else
 -	{
 -	  /* If requested as a system header, assume it belongs in
 -	     the first system header directory.  */
 -	  struct search_path *ptr = CPP_OPTION (pfile, bracket_include);
 -	  char *p;
 -	  int len = 0, fname_len = strlen (fname);
 -
 -	  if (ptr)
 -	    len = ptr->len;
 -
 -	  p = (char *) alloca (len + fname_len + 2);
 -	  if (len)
 -	    {
 -	      memcpy (p, ptr->name, len);
 -	      p[len++] = '/';
 -	    }
 -	  memcpy (p + len, fname, fname_len + 1);
 -	  deps_add_dep (pfile->deps, p);
 -	}
 -    }
 +    deps_add_dep (pfile->deps, fname);
    /* If -M was specified, then don't count this as an error, because
       we can still produce correct output.  Otherwise, we can't produce
       correct output, because there may be dependencies we need inside
 Index: doc/cppopts.texi
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/doc/cppopts.texi,v
 retrieving revision 1.5
 diff -u -p -r1.5 cppopts.texi
 --- doc/cppopts.texi	7 Apr 2002 03:12:23 -0000	1.5
 +++ doc/cppopts.texi	8 May 2002 21:15:22 -0000
 @@ -204,10 +204,13 @@ When used with the driver options @optio
  
  @item -MG
  @opindex MG
 -When used with @option{-M} or @option{-MM}, @option{-MG} says to treat missing
 -header files as generated files and assume they live in the same
 -directory as the source file.  It suppresses preprocessed output, as a
 -missing header file is ordinarily an error.
 +In conjunction with an option such as @option{-M} requesting
 +dependency generation, @option{-MG} assumes missing header files are
 +generated files and adds them to the dependency list without raising
 +an error.  The dependency filename is taken directly from the
 +@code{#include} directive without prepending any path.  @option{-MG}
 +also suppresses preprocessed output, as a missing header file renders
 +this useless.
  
  This feature is used in automatic updating of makefiles.
  

Re: preprocessor/6521: -MG creates dependency with wrong path

[Zack Weinberg]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Robert Spier <rspier@pobox.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 13:45:56 -0700

 On Wed, May 08, 2002 at 09:20:04PM +0100, Neil Booth wrote:
 > Zack Weinberg wrote:-
 > 
 > > This is true.  And we have one registered complaint about the current
 > > behavior.  We can always put it back later.
 > > 
 > > Robert, would you be willing to clarify the documentation?
 > 
 > OK, I'll apply Robert's patch.  What do you feel is unclear about
 > the docs?  The fact that it refers to "current directory"?
 
 Precisely.
 
 I'm not sure how best to clarify it, without rewriting all the stuff
 about dependency output (which needs doing, but I don't have time
 now).
 
 zw

Re: preprocessor/6521: -MG creates dependency with wrong path

[Neil Booth]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Robert Spier <rspier@pobox.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 21:20:04 +0100

 Zack Weinberg wrote:-
 
 > This is true.  And we have one registered complaint about the current
 > behavior.  We can always put it back later.
 > 
 > Robert, would you be willing to clarify the documentation?
 
 OK, I'll apply Robert's patch.  What do you feel is unclear about
 the docs?  The fact that it refers to "current directory"?
 
 Neil.

Re: preprocessor/6521: -MG creates dependency with wrong path

[Zack Weinberg]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Robert Spier <rspier@pobox.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 13:09:43 -0700

 On Wed, May 08, 2002 at 06:31:05PM +0100, Neil Booth wrote:
 > 
 > Good point, I'd not thought of that.  I tend to think, though, that
 > -MG should never really be being used with <>, so whatever we do
 > isn't that important.  That makes me like Robert's patch as it
 > deletes code, and does what is documented after all.
 
 This is true.  And we have one registered complaint about the current
 behavior.  We can always put it back later.
 
 Robert, would you be willing to clarify the documentation?
 
 > > ... perhaps -Mx <path> puts all the
 > > dependencies on generated files in <path>.  (Where 'x' is some
 > > appropriate letter; I am too tired to think of a good one right now.)
 > 
 > Hmm, I guess.  We have too many options, really.  It's a shame -MG
 > can't die.  Fancy doing it with your "closing same file twice" patch?
 > 8-)
 
 FYI, I'm not likely to get to that issue until next week.  If you want
 to fix it first, feel free.
 
 As for -MG with/without argument, I'm planning to look at it anyway
 when I move cpplib to its own directory (which will give us the
 leverage we need to do automatic dependency generation for the gcc
 directory).  Let's not worry about it now.
 
 zw

Re: preprocessor/6521: -MG creates dependency with wrong path

[Neil Booth]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Robert Spier <rspier@pobox.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 18:31:05 +0100

 Zack Weinberg wrote:-
 
 > I'm not entirely sure I understand this.
 > 
 > I've never really liked -MG; it is too inflexible.  With <> it does
 > something fairly silly, as Robert points out; but with "" it does
 > something equally silly, which is to assume that splatting whatever
 > string the user provided into the dependency list will work.  (It does
 > _not_ assume they live in the same directory as the source file;
 > consider split source and build trees.  The current behavior is
 > more likely to work in practice than the documented one, but...
 
 Good point, I'd not thought of that.  I tend to think, though, that
 -MG should never really be being used with <>, so whatever we do
 isn't that important.  That makes me like Robert's patch as it
 deletes code, and does what is documented after all.
 
 > The behavior under discussion predates cpplib, incidentally.
 > 
 > It seems to me that we should leave -MG alone, since there are
 > undoubtedly Makefiles out there depending on every last quirk of its
 > semantics (remember all the fallout the last time we decided to
 > improve the semantics of the -M switches?).  We should instead come up
 > with a new way to do it that lets the user say where the generated
 > file is expected to turn up... perhaps -Mx <path> puts all the
 > dependencies on generated files in <path>.  (Where 'x' is some
 > appropriate letter; I am too tired to think of a good one right now.)
 
 Hmm, I guess.  We have too many options, really.  It's a shame -MG
 can't die.  Fancy doing it with your "closing same file twice" patch?
 8-)
 
 > Come to think of it, -MG and -MP clash.  We should mark entries added
 > to the list by -MG and not generate phony targets for them under -MP,
 > or Make will pitch a fit about multiple rules for the same target.
 
 You mean because the missing file presumably has a make rule specifying
 how to generate it elsewhere?
 
 Neil.

Re: preprocessor/6521: -MG creates dependency with wrong path

[Tom Tromey]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Robert Spier <rspier@pobox.com>, gcc-gnats@gcc.gnu.org,
        gcc-bugs@gcc.gnu.org, Andreas Jaeger <aj@suse.de>,
        Roland McGrath <roland@frob.com>
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: 08 May 2002 10:39:08 -0600

 >>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:
 
 Zack> Come to think of it, -MG and -MP clash.  We should mark entries
 Zack> added to the list by -MG and not generate phony targets for them
 Zack> under -MP, or Make will pitch a fit about multiple rules for the
 Zack> same target.
 
 It is ok to have multiple targets of the form `foo.h:', with no
 attached rule.  In fact this is required for -MP to really work; in a
 given project many files will include any given header, and so it will
 appear in several make `include' files.
 
 Tom

Re: preprocessor/6521: -MG creates dependency with wrong path

[Roland McGrath]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Roland McGrath <roland@gnu.org>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Robert Spier <rspier@pobox.com>,
	Zack Weinberg <zack@codesourcery.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org, Andreas Jaeger <aj@suse.de>
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed,  8 May 2002 02:50:52 -0400 (EDT)

 I don't know of any use of -MG with <>.

Re: preprocessor/6521: -MG creates dependency with wrong path

[Neil Booth]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Robert Spier <rspier@pobox.com>
Cc: Zack Weinberg <zack@codesourcery.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org, Andreas Jaeger <aj@suse.de>,
	Roland McGrath <roland@frob.com>
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 07:36:46 +0100

 Robert Spier wrote:-
 
 > The only sensible patch I can think of is to remove this odd
 > functionality entirely.
 > 
 > The below patch unifies handling for system and non-system include
 > files and removes the special case.  It only affects -MG, and brings
 > it in line with the documentation:
 > 
 >       -MG When used with -M or -MM, -MG says to treat missing
 >            header files as generated files and assume they live
 >            in the same directory as the source file.  It sup?
 >            presses preprocessed output, as a missing header file
 >            is ordinarily an error.
 
 On further reflection, I don't think this makes any sense.
 Files included with <> do not search the current directory,
 so assuming the file lies there is obviously bogus.
 
 The sensible thing to do, IMO, is to step down the <> include
 path until the resulting path, when appending the file name,
 exists, and to fail if all such paths don't exist.
 
 Neil.

Re: preprocessor/6521: -MG creates dependency with wrong path

[Neil Booth]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Robert Spier <rspier@pobox.com>
Cc: Zack Weinberg <zack@codesourcery.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org, Andreas Jaeger <aj@suse.de>,
	Roland McGrath <roland@frob.com>
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Wed, 8 May 2002 07:31:56 +0100

 Robert Spier wrote:-
 
 > The only sensible patch I can think of is to remove this odd
 > functionality entirely.
 > 
 > The below patch unifies handling for system and non-system include
 > files and removes the special case.  It only affects -MG, and brings
 > it in line with the documentation:
 > 
 >       -MG When used with -M or -MM, -MG says to treat missing
 >            header files as generated files and assume they live
 >            in the same directory as the source file.  It sup?
 >            presses preprocessed output, as a missing header file
 >            is ordinarily an error.
 
 Zack,
 
 What do you think of this?  I'm a bit worried about it.
 
 Andreas,
 
 Does glibc, Hurd or any other software you're aware of depend
 on the contrary-to-documented behaviour of -MG with <>?
 
 Neil.

Re: preprocessor/6521: -MG creates dependency with wrong path

[Robert Spier]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: rspier@pobox.com (Robert Spier)
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Zack Weinberg <zack@codesourcery.com>, gcc-gnats@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Tue, 7 May 2002 23:12:18 -0700

 >> Why is this the intended behavior?  It doesn't make much sense to me=
 .
 >
 >It's intended because it's what the comment in the code says and
 >does.
 
 Ok.. But why?   Beyond it's existence, it doesn't make any sense to
 me.
 
 >I'd welcome a patch to do something more sensible.  You can wait for m=
 e
 >to look at it, but it's pretty near the bottom of my to-do list.
 
 The only sensible patch I can think of is to remove this odd
 functionality entirely.
 
 The below patch unifies handling for system and non-system include
 files and removes the special case.  It only affects -MG, and brings
 it in line with the documentation:
 
       -MG When used with -M or -MM, -MG says to treat missing
            header files as generated files and assume they live
            in the same directory as the source file.  It sup=AD
            presses preprocessed output, as a missing header file
            is ordinarily an error.
 
 The patch is against the 20020506 snapshot. =20
 
 Thanks!
 
 -R
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: gcc/cppfiles.c,v
 retrieving revision 1.1
 diff -u -r1.1 gcc/cppfiles.c
 --- gcc/cppfiles.c      2002-05-07 22:33:13-07  1.1
 +++ gcc/cppfiles.c      2002-05-07 22:35:48-07
 @@ -658,28 +658,8 @@
 =20
    if (CPP_OPTION (pfile, print_deps_missing_files) && print_dep)
      {
 -      if (!angle_brackets || IS_ABSOLUTE_PATHNAME (fname))
 +      /* Assume missing headers are in the current directory */
         deps_add_dep (pfile->deps, fname);
 -      else
 -       {
 -         /* If requested as a system header, assume it belongs in
 -            the first system header directory.  */
 -         struct search_path *ptr =3D CPP_OPTION (pfile, bracket_includ=
 e);
 -         char *p;
 -         int len =3D 0, fname_len =3D strlen (fname);
 -
 -         if (ptr)
 -           len =3D ptr->len;
 -
 -         p =3D (char *) alloca (len + fname_len + 2);
 -         if (len)
 -           {
 -             memcpy (p, ptr->name, len);
 -             p[len++] =3D '/';
 -           }
 -         memcpy (p + len, fname, fname_len + 1);
 -         deps_add_dep (pfile->deps, p);
 -       }
      }
    /* If -M was specified, then don't count this as an error, because
       we can still produce correct output.  Otherwise, we can't produce=
 
 

Re: preprocessor/6521: -MG creates dependency with wrong path

[Neil Booth]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Robert Spier <rspier@pobox.com>
Cc: Zack Weinberg <zack@codesourcery.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Sat, 4 May 2002 09:10:27 +0100

 Robert Spier wrote:-
 
 > >> This is intended behaviour (but undocumented I think); whether it is
 > >> desirable or not is a different question.
 > >> 
 > >> IMO this is not worth fixing; and we should just document the behaviour
 > >> for <> headers.  What do you think, Zack?
 > >
 > >Agreed.
 > 
 > Why is this the intended behavior?  It doesn't make much sense to me.
 
 It's intended because it's what the comment in the code says and does.
 I'd welcome a patch to do something more sensible.  You can wait for me
 to look at it, but it's pretty near the bottom of my to-do list.
 
 Neil.

Re: preprocessor/6521: -MG creates dependency with wrong path

[Robert Spier]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: rspier@pobox.com (Robert Spier)
To: Zack Weinberg <zack@codesourcery.com>
Cc: Neil Booth <neil@daikokuya.demon.co.uk>, gcc-gnats@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Fri, 3 May 2002 12:55:56 -0700

 >> This is intended behaviour (but undocumented I think); whether it is
 >> desirable or not is a different question.
 >> 
 >> IMO this is not worth fixing; and we should just document the behaviour
 >> for <> headers.  What do you think, Zack?
 >
 >Agreed.
 
 Why is this the intended behavior?  It doesn't make much sense to me.
 
 Thanks-
 
 -R
 

Re: preprocessor/6521: -MG creates dependency with wrong path

[Zack Weinberg]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: rspier@pobox.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Fri, 3 May 2002 09:46:25 -0700

 On Fri, May 03, 2002 at 01:54:10PM +0100, Neil Booth wrote:
 > rspier@pobox.com wrote:-
 > 
 > > >Description:
 > > gcc or g++ -MG outputs incorrect dependency information when there is a nonexistent header file specified in angle brackets.  (i.e. #include <...>)
 > > 
 > > It uses the path of the first specified -I argument (or the first system directory, if no directory is specified.)
 > > 
 > > The attached script demonstrates the problem.  
 > > 
 > > #include "some/header.h"
 > > #include <nonexistent.h>
 > > int main() {
 > > }
 > > gcc3 -M -MG /tmp/_16336//test.c -I/tmp/_16336//not/a/real/path
 > > test.o: /tmp/_16336/test.c some/header.h \
 > >   /tmp/_16336/not/a/real/path/nonexistent.h
 > > >How-To-Repeat:
 > > (Run attached script.)
 > 
 > This is intended behaviour (but undocumented I think); whether it is
 > desirable or not is a different question.
 > 
 > IMO this is not worth fixing; and we should just document the behaviour
 > for <> headers.  What do you think, Zack?
 
 Agreed.
 
 zw

Re: preprocessor/6521: -MG creates dependency with wrong path

[Neil Booth]

The following reply was made to PR preprocessor/6521; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: rspier@pobox.com
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
	Zack Weinberg <zack@codesourcery.com>
Subject: Re: preprocessor/6521: -MG creates dependency with wrong path
Date: Fri, 3 May 2002 13:54:10 +0100

 rspier@pobox.com wrote:-
 
 > >Description:
 > gcc or g++ -MG outputs incorrect dependency information when there is a nonexistent header file specified in angle brackets.  (i.e. #include <...>)
 > 
 > It uses the path of the first specified -I argument (or the first system directory, if no directory is specified.)
 > 
 > The attached script demonstrates the problem.  
 > 
 > #include "some/header.h"
 > #include <nonexistent.h>
 > int main() {
 > }
 > gcc3 -M -MG /tmp/_16336//test.c -I/tmp/_16336//not/a/real/path
 > test.o: /tmp/_16336/test.c some/header.h \
 >   /tmp/_16336/not/a/real/path/nonexistent.h
 > >How-To-Repeat:
 > (Run attached script.)
 
 This is intended behaviour (but undocumented I think); whether it is
 desirable or not is a different question.
 
 IMO this is not worth fixing; and we should just document the behaviour
 for <> headers.  What do you think, Zack?
 
 Neil.

preprocessor/6521: -MG creates dependency with wrong path

[rspier]

>Number:         6521
>Category:       preprocessor
>Synopsis:       -MG creates dependency with wrong path
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 30 13:36:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     rspier@pobox.com
>Release:        gcc2.95, gcc2.96rh, egcs 1.1.2 (gcc 2.91), gcc 3.0.2
>Organization:
>Environment:
Linux
>Description:
gcc or g++ -MG outputs incorrect dependency information when there is a nonexistent header file specified in angle brackets.  (i.e. #include <...>)

It uses the path of the first specified -I argument (or the first system directory, if no directory is specified.)

The attached script demonstrates the problem.  

#include "some/header.h"
#include <nonexistent.h>
int main() {
}
gcc3 -M -MG /tmp/_16336//test.c -I/tmp/_16336//not/a/real/path
test.o: /tmp/_16336/test.c some/header.h \
  /tmp/_16336/not/a/real/path/nonexistent.h
>How-To-Repeat:
(Run attached script.)
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/x-sh; name="t.sh"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="t.sh"

IyEvYmluL3NoCgpESVI9L3RtcC9fJCQvCklESVI9JERJUi9ub3QvYS9yZWFsL3BhdGgKRklMRT0k
RElSL3Rlc3QuYwoKbWtkaXIgLXAgJERJUgpta2RpciAtcCAkSURJUgoKIyBDcmVhdGUgRmlsZQpj
YXQ8PEVPRiA+ICRGSUxFCiNpbmNsdWRlICJzb21lL2hlYWRlci5oIgojaW5jbHVkZSA8bm9uZXhp
c3RlbnQuaD4KaW50IG1haW4oKSB7Cn0KRU9GCgpjYXQgJEZJTEUKCiMgRGVwZW5kZW5jeSBTY2Fu
CkNNRD0iZ2NjMyAtTSAtTUcgJEZJTEUgLUkkSURJUiIKZWNobyAkQ01ECiRDTUQKCiMgQ2xlYW4g
VXAKcm0gLXJmICRESVIK