The following C program will not compile with the command "gcc file.c": #define FIRST "This is a split int main() { printf( FIRST string"); } It gives the expected error message about the malformed preprocessor token. However if the output of "cpp file.c" or "gcc -E file.c" is saved and fed back into gcc then it DOES compile and run. Here is the output of "gcc -E file.c": int main() { printf( "This is a split string"); } I checked the ANSI standard and this is indeed an illegal program. Shouldn't the preprocessor give an error message when run alone?
Confirmed, a regression from 3.3.3.
On a related note, is macro prescanning of arguments part of the ANSI standard? In "Harbison and Steele" they seem to imply argument prescanning in macros is not ANSI-compliant...
Subject: Re: [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly? This bug is closely related to bug 14634 - not diagnosing these cases with -E looks like another case of the same ill-advised extensions (which I'd still be glad to revert to being mandatory errors).
There is a reference to this problem in: http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01827.html But it says it was not the cause of the problem though. -------------------------------------------------------- Janis, Could you do a regression hunt on this bug? Thanks, Andrew Pinski
A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=66019 r66019 | neil | 2003-04-23 22:44:06 +0000 (Wed, 23 Apr 2003)
Subject: Re: [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly? pinskia at gcc dot gnu dot org wrote:- > > > ------- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 05:11 ------- > Confirmed, a regression from 3.3.3. Rather, intended behaviour since 3.3.3. Neil.
Subject: Bug 28768 Author: jsm28 Date: Wed Sep 13 01:04:18 2006 New Revision: 116915 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116915 Log: libcpp: PR c/28768 PR preprocessor/14634 * lex.c (lex_string): Pedwarn for unterminated literals. libgomp: * configure.ac (HAVE_CLOCK_GETTIME): Add missing second argument to AC_DEFINE. * configure: Regenerate. gcc/testsuite: * gcc.dg/cpp/include2.c, gcc.dg/cpp/macspace1.c, gcc.dg/cpp/macspace2.c, gcc.dg/cpp/multiline.c, gcc.dg/cpp/trad/literals-2.c: Update expected diagnostics. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/include2.c trunk/gcc/testsuite/gcc.dg/cpp/macspace1.c trunk/gcc/testsuite/gcc.dg/cpp/macspace2.c trunk/gcc/testsuite/gcc.dg/cpp/multiline.c trunk/gcc/testsuite/gcc.dg/cpp/trad/literals-2.c trunk/libcpp/ChangeLog trunk/libcpp/lex.c trunk/libgomp/ChangeLog trunk/libgomp/configure trunk/libgomp/configure.ac
Fixed in 4.2.0 by making this a mandatory pedwarn; I don't consider this suitable to apply to past release branches which have had releases without the pedwarn.