Re: preprocessor/5153: #include path not affected by #line in cpplib

Re: preprocessor/5153: #include path not affected by #line in cpplib

[neil]

Synopsis: #include path not affected by #line in cpplib

Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-By: neil
Responsible-Changed-When: Sat Feb 23 08:30:14 2002
Responsible-Changed-Why:
    Mine.  Thanks for your bug report.
State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Sat Feb 23 08:30:14 2002
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.

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

Re: preprocessor/5153: #include path not affected by #line in cpplib

[John Marshall]

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

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

Re: preprocessor/5153: #include path not affected by #line in cpplib

[Zack Weinberg]

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

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

Re: preprocessor/5153: #include path not affected by #line in cpplib

[Neil Booth]

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

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.

preprocessor/5153: #include path not affected by #line in cpplib

[John Marshall]

>Number:         5153
>Category:       preprocessor
>Synopsis:       #include path not affected by #line in cpplib
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 18 06:46:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     John Marshall
>Release:        3.0.2
>Organization:
>Environment:
System: Linux kahikatea.falch.net 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../../gcc-3.0.2/configure --prefix=/opt/gcc/3.0 --enable-languages=c,c++
>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.)

With GCC 3.0.2 run from within the build directory, we get

$ cd test/build
$ gcc -E foo.c -traditional
# 1 "foo.c"



# 1 "../src/foo.y"

# 1 "../src/foo.h" 1
extern int foo ();
# 3 "../src/foo.y" 2

(And similarly with GCC 2.95.3.)  But without -traditional we get

$ gcc -E foo.c             
../src/foo.y:2:17: foo.h: No such file or directory

The current CVS HEAD gives the same error without -traditional.

>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.
>Release-Note:
>Audit-Trail:
>Unformatted: