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

[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.

[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