The command "gcc -E -C -P test.c", where the contents of test.c are:

<test.c>
#define macro(x) x
macro(
// Comment
y
)
</test.c>

produces the following result:

<result>
// Comment y

</result>

where the trailing newline of the // comment is removed, causing the next line 
of code ("y") to be integrated into the comment. I would have expected one of 
the following:

<result>
// Comment
y

</result>

<result>
/* Comment*/ y

</result>

I cannot be sure this is a bug; I suppose gcc can do whatever its authors want 
here as regards -C, which is not standardized stuff afaik. I did some research 
and found no info about this specific behaviour. But if this is deliberate, I 
can't see the pros, and the inconvenient is nasty: the preprocessed code does 
not have the same meaning as the source, and may even be made syntactically 
incorrect.

I could make this behaviour happen with 3 different gcc versions; here are 
their answers to "gcc -v":

1. MinGW candidate (on Windows 98), gcc 3.4.1:
Reading specs from C:/GCC-CO~1.TAR/BIN/../lib/gcc/mingw32/3.4.1/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.1 (mingw special)

2. MinGW stable (on Windows 98), gcc 3.2.3:
Reading specs from C:/MINGW/BIN/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-
exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)

3. DJGPP stable (on Windows 98), gcc 3.3.3:
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/3.33/specs
Configured with: /devel/gnu/gcc/3.3/gnu/gcc-3.33/configure djgpp --prefix=/dev/e
nv/DJDIR --disable-nls
Thread model: single
gcc version 3.3.3

With an older gcc ("gcc version 2.95.2 19991024 (release)", provided with Linux 
for PlayStation2 Release 1.0), I got another (also wrong) result:

<result>



y

</result>

where the comment just disappears.

PS Sorry for not filling in the "triplet" fields, but I have no clue what this 
is about -- I did search everywhere I could think of, and could only find that 
I'm not the only one baffled by this. Maybe some help could be provided on 
the "Enter bug" page, like the notes about priority or severity for instance?