Re: [3.3 regression] fix incorrect line break before functional macro name

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep 14, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> The behavior change seems to have also affected other uses of the
>> preprocessor for assembly code (why do we use cc1, and not cpp0, to
>> preprocess assembly?  Shouldn't assembly be regarded as requiring
>> -traditional preprocessing?).

> (trad)cpp0 no longer exists, 

Well, doh!, that's why I couldn't figure out how we decided whether to
use it or not ;-)

> and no, assembly does not require -traditional.

Err...  Line breaks are certainly more significant for assembly than
for C, and I thought this was one of the cases in which traditional
preprocessing is to be preferred.

My thought is that, if we eventually change the preprocessor such
that, given:

#define FOO()
a FOO (
) b

it emits:

# 1 "-"

a \
  b

which -fpreprocessed doesn't accept, or:

# 1 "-"

a /*
*/b

which it does, then we'd be able to resync line (and column!) numbers
in (almost, for columns) every physical line change within a logical
line.  But this would break assemblers that don't accept escaped
newlines (or C-style comments).  We'd be taking further the trend that
the C preprocessor is for C, and that using it for other languages is
an abuse.

Comments on this approach?  Would a patch that implemented something
along these lines be acceptable for mainline?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer