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

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

[neil]

Synopsis: gcc 2.96, 3.0 break -E -C define line comment processing

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Mon Oct  8 13:07:58 2001
State-Changed-Why:
    Fixed for 3.1.  In the next hour or so, I'll be committing
    a patch for 3.0.2 also.  Both work by not saving comments
    as part of macro expansions [a nice idea, but causing
    too many problems.  It might be re-introduced later, but
    in such a way that it works 8-)]
    
    Thanks for your bug report.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4353&database=gcc

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

[ted]

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