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: