Fix:
-traditional is not a workaround. :-)

This problem will be encountered mostly in separate-build-directory
arrangements, and Makefiles which can handle separate build directories
already mostly have lots of -I options in their CFLAGS (eg for the build
directory), so adding one more (for the source directory) isn't too hard.

The places where #include looks are "implementation-defined" in the
C standard, so this change does not cause a standards-compliance issue.
I was going to say that there is a standards-compliance issue because
this behaviour of #line is not documented in the GCC^H^H^HCPP manual, but
I just noticed that since July and Zack's rewrite it *is* documented.

However I can't tell whether the *change* in behaviour compared to the
previous compiler was noted at the time of the documentation improvement
(searching for "#line" in the archives seemingly gives you every article
ever, and there was nothing in GNATS), or whether Zack thought he was
just documenting long-standing behaviour.

In my opinion, the previous behaviour was more self-consistent.

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: John Marshall <jmarshall@acm.org>, gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/5153: #include path not affected by #line in cpplib
Date: Tue, 18 Dec 2001 16:14:35 -0800

 On Tue, Dec 18, 2001 at 11:07:28PM +0000, Neil Booth wrote:
 > > 
 > > (In the real world, what we have is foo.y, foo.h in a source directory,
 > > and foo.c has been generated in a separate build directory from foo.y.
 > > Because most GNU projects put foo.c in the source directory, they haven't
 > > encountered the problem described, but that doesn't mean arranging builds
 > > like this is invalid.)
 > 
 > Zack, is this limitation intentional or arbitrary?  It seems having it
 > affect the path can be useful, but I worry about side-effects on
 > existing code.  Then again, John says this was the historical behaviour.
 
 It was intentionally changed, but I do not remember why.  If no one
 can point to code which is broken by the historical behaviour, it
 probably makes sense to change it back.
 
 Note that a simple -I../src will cause foo.h to be found again.
 
 zw

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: John Marshall <jmarshall@acm.org>,
	Zack Weinberg <zack@codesourcery.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/5153: #include path not affected by #line in cpplib
Date: Tue, 18 Dec 2001 23:07:28 +0000

 John Marshall wrote:-
 
 > >Description:
 > In previous (i.e. non-cpplib) versions of GCC the dirname part of a filename
 > in a #line directive would affect the #include search path.  This is no
 > longer the case.  This is a change in behaviour compared to eg GCC 2.95.x.
 > >How-To-Repeat:
 > (This is not preprocessed output because the problem depends on separate
 > files and directories.)
 > 
 > [File 1: test/src/foo.h]
 > extern int foo ();
 > 
 > [File 2: test/build/foo.c]
 > /* A Bison parser, made from ../src/foo.y
 >    by GNU bison 1.30.  */
 > #line 1 "../src/foo.y"
 > #include "foo.h"
 > 
 > [File ends]
 > 
 > (In the real world, what we have is foo.y, foo.h in a source directory,
 > and foo.c has been generated in a separate build directory from foo.y.
 > Because most GNU projects put foo.c in the source directory, they haven't
 > encountered the problem described, but that doesn't mean arranging builds
 > like this is invalid.)
 
 Zack, is this limitation intentional or arbitrary?  It seems having it
 affect the path can be useful, but I worry about side-effects on
 existing code.  Then again, John says this was the historical behaviour.
 
 Neil.

Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-Why: Mine.  Thanks for your bug report.

State-Changed-From-To: open->closed
State-Changed-Why: After some discussion of a patch that I originally submitted to revert this behaviour here:
    
    http://gcc.gnu.org/ml/gcc-patches/2002-02/msg01470.html
    
    we decided to retain the current behaviour.  The above link starts a thread that also references other mails where the old behaviour was considered to be a bug.  Since the old behaviour had the potential for much confusion (see referenced mails), and which can often, if not always, be obtained with an extra -I switch, we have decided the current semantics are the lesser evil.

From: John Marshall <jmarshall@acm.org>
To: neil@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: preprocessor/5153: #include path not affected by #line in cpplib
Date: Sun, 24 Feb 2002 21:08:24 +0100

 On Sat, Feb 23, 2002 at 04:30:15PM -0000, neil@gcc.gnu.org wrote:
 >     we decided to retain the current behaviour.  The above link starts
 >     a thread that also references other mails where the old behaviour
 >     was considered to be a bug.
 
 I still agree with Andreas [1] that the old behaviour is more
 self-consistent
 
 >     Since the old behaviour [...] can
 >     often, if not always, be obtained with an extra -I switch
 
 (like I mentioned in the original bug report :-)), but all I really
 wanted to do was get the change in behaviour mentioned in GNATS and/or
 the documentation, so the next person who runs into this has more to go
 on.  Thanks for looking into this.
 
     John
 
 [1] http://gcc.gnu.org/ml/gcc-bugs/1999-06n/msg00098.html