public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: John Marshall <jmarshall@acm.org> To: gcc-gnats@gcc.gnu.org Subject: preprocessor/5153: #include path not affected by #line in cpplib Date: Tue, 18 Dec 2001 06:46:00 -0000 [thread overview] Message-ID: <E16GLSK-0001Et-00@kahikatea.falch.net> (raw) >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:
next reply other threads:[~2001-12-18 14:46 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-12-18 6:46 John Marshall [this message] 2001-12-18 15:16 Neil Booth 2001-12-18 16:16 Zack Weinberg 2002-02-23 9:56 neil 2002-02-24 12:22 John Marshall
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=E16GLSK-0001Et-00@kahikatea.falch.net \ --to=jmarshall@acm.org \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).