From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26049 invoked by alias); 18 Dec 2001 14:46:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 26019 invoked by uid 71); 18 Dec 2001 14:46:02 -0000 Resent-Date: 18 Dec 2001 14:46:02 -0000 Resent-Message-ID: <20011218144602.26018.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, John Marshall Received:(qmail 24633 invoked from network); 18 Dec 2001 14:43:07 -0000 Received: from unknown (HELO zappa.falch.net) (193.69.105.131) by sources.redhat.com with SMTP; 18 Dec 2001 14:43:07 -0000 Received: from kahikatea.falch.net (kahikatea.falch.net [193.71.98.234]) by zappa.falch.net (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id fBIEe2B32257 for ; Tue, 18 Dec 2001 15:40:02 +0100 Received: from johnm by kahikatea.falch.net with local (Exim 3.33 #1 (Debian)) id 16GLSK-0001Et-00 for ; Tue, 18 Dec 2001 15:42:56 +0100 Message-Id: Date: Tue, 18 Dec 2001 06:46:00 -0000 From: John Marshall To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version:3.113 Subject: preprocessor/5153: #include path not affected by #line in cpplib X-SW-Source: 2001-12/txt/msg00959.txt.bz2 List-Id: >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: