Opinions on how to handle this bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
a) don't print the line; or
b) output its line number as 1; or
c) fix its line number (internally) as 1.
c) seems cleanest to me, but I don't really care.
This is especially
an issue for people who use cpp to pre
Zack Weinberg wrote:
Stuff does appear between and with -g3, -dD,
and possibly some of the other -d switches. That is why they're
there. I would have no objection to suppressing it (and
too) when none of those options is in use.
In that case it's probably easiest to just hack c-ppoutput.c so
Neil Booth <[EMAIL PROTECTED]> writes:
>> But that would break too much
>> code. Simplest and cleanest solution: Just get rid of the
>> line in pre-processor output. This might break some tools that look
>> at cpp output, but it seems unlikely.
>
> Agreed - we never guarantee the form of -E any
Per Bothner <[EMAIL PROTECTED]> writes:
...
> However, we end up with preprocessor output like this:
>
> # 1 "any-file"
> # 0 ""
> # 1 ""
> # 1 "any-file"
>
> Some assemblers complain about line number 0. This is especially
> an issue for people who use cpp to preprocessor assembler, which
> of c
Per Bothner wrote:-
> Opinions on how to handle this bug?
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
>
> This came up because we give declarations
> line 0, but used line 1 in a different date structure.
> I fixed the code to consistently use line 0, which is
> needed for the --enable-m
Opinions on how to handle this bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
This came up because we give declarations
line 0, but used line 1 in a different date structure.
I fixed the code to consistently use line 0, which is
needed for the --enable-mapped-location unification.
However,
