Opinions on how to handle this bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
This came up because we give <built-in> 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, we end up with preprocessor output like this:
# 1 "any-file"
# 0 "<built-in>"
# 1 "<command line>"
# 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 course we don't really support.
My suggested solution: suppress the output of <built-in>, so
we get:
# 1 "any-file"
# 1 "<command line>"
# 1 "any-file"
There should never be anything following <built-in>, so it's useless
as well as confusing. Also, if we compile multiple files at once (or
use a compile server), then logically the <built-in> declaration
*precede* all the actual code, which suggests that if <built-in> is
output it should be the *first* line. But that would break too much
code. Simplest and cleanest solution: Just get rid of the <built-in>
line in pre-processor output. This might break some tools that look
at cpp output, but it seems unlikely. I'll check that -fpreprocessed
doesn't break (I assume the testsuite tests this?), and I'll ask
someone to check distcc.
Objections to this approach? Other suggestions? One alternative is
to fix gas to not complain about line number 0.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
