preprocessor/4353: gcc 2.96, 3.0 break -E -C define line comment processing

[ted@arraycomm.com]

>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: