From mboxrd@z Thu Jan 1 00:00:00 1970 From: ted@arraycomm.com To: gcc-gnats@gcc.gnu.org Cc: ted@arraycomm.com Subject: preprocessor/4353: gcc 2.96, 3.0 break -E -C define line comment processing Date: Tue, 18 Sep 2001 16:26:00 -0000 Message-id: <20010918232152.28643.qmail@sourceware.cygnus.com> X-SW-Source: 2001-09/msg00394.html List-Id: >Number: 4353 >Category: preprocessor >Synopsis: gcc 2.96, 3.0 break -E -C define line comment processing >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Tue Sep 18 16:26:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Ted Merrill, ArrayComm, Inc. >Release: gcc-2.96, gcc-3.0 >Organization: >Environment: several cross compilation targets incl. solaris, arm, etc. >Description: We compile a large amount of C code with both the -C and -E options (because we do further processing before final compilation). Given the following file: #define foo 1 //comment here int bar(void) { return foo; } gcc-3.0 with -C -E produces the following output: # 2 "test1.c" int bar(void) { return 1 //comment here; } This of course won't compile! gcc-2.96 gives me the same result, but gcc-2.95 (and earlier) gives: # 1 "test1.c" //comment here int bar(void) { return 1 ; } ... which works nicely. This change breaks a LOT of our code. I did come up with a hack on the source code to work around it but my hack suppresses comments entirely, and of course it would be nice to take care of this in the main tree! It appears from comments in the source code that this change was deliberate but i'm not sure that the author considered the effect on this case! A related problem is seen in the following file: #define foo 0 //comment #if foo yyy #endif gcc 2.96 and 3.0 abort with the diagnostic: test2.c:2:5: "//comment" is not valid in #if expressions whereas gcc 2.95 was quite happy, producing: # 1 "test2.c" //comment >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: