[Bug c/44191] New: -E output broken for gcc-4.5.0

[Bug c/44191] New: -E output broken for gcc-4.5.0

[gcc-bug at andihellmund dot com]

Hey,

while working on a low-prio PR24024, I recognized that the -E output of
gcc-4.5.0 is somehow "broken" for certain constructs, for example:

==== test.c ====
int main ()
{
  int ret, a;

  ret = a + \
  b;
}
==== END test.c ====

(gcc-4.5.0) # gcc -E test.c
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test.c"
int main ()
{
int ret, a;
ret = a +
 b;
}

I also tested this on older versions of gcc and each of these versions (4.2.0,
4.3.0 and 4.4.3) return the expected output:

# 1 "test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test.c"
int main ()
{
int ret, a;
ret = a + b;

}

I currently suspect that this incorrect output in gcc-4.5.0 is caused by
_cpp_clean_line. For my understanding, _cpp_clean_line should detect the splice
operator and merge the two lines to form a new logical line which is then
output due to the -E option.


-- 
           Summary: -E output broken for gcc-4.5.0
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gcc-bug at andihellmund dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44191

[Bug preprocessor/44191] -E output broken for gcc-4.5.0

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2010-05-18 22:44 -------
That's just incorrect assumption.
The reason why the first alternative is now preferred is to provide proper
locus for the b token.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44191

[Bug preprocessor/44191] -E output broken for gcc-4.5.0

[ipinkas at nds dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44191

Israel Pinkas <ipinkas at nds dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ipinkas at nds dot com

--- Comment #2 from Israel Pinkas <ipinkas at nds dot com> 2012-09-11 22:40:08 UTC ---
A am not sure what Jakub means by Locus, but the C and C++ standards are clear
that during the preprocessing stage, the sequence backslash-newline is dropped
from the stream.  Line splicing occurs before tokenization.

While in most situations there is no difference, there are some cases which are
affected by this bug:

1. Token splicing.  Two tokens are separated by only a backslash-newline in the
source are supposed to be concatenated into a single token.  In a bizzare twist
to this bug, this behavior is preserved.  See example below.

2. Use of cpp for other purposes.  There exist multiple software packages which
are not compilers for C-line languages that use cpp as a preprocessor,
accepting that cpp is C-oriented in a number of ways.  This includes some
assemblers and other packages that need file inclusion, conditional
compilation, and simple macros.  Many of these packages rely on the line
splicing.

The bug description needs to be slighly ammended.  The splicing behavior was
changed only when the first character following the newline is a space or tab. 
The following demonstrates:

==== x.txt ====
Test\
ing
Test\
 case
==== END ====
$ cpp x.txt
# 1 "x.txt"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "x.txt"
Testing

Test
 code
==========

The first instance spliced the tokens.  However, the second instance left the
newline, a change in behavior and a deviation from the spec.