------- Comment #11 from per at bothner dot com 2005-10-12 16:22 -------
Subject: Re: [4.1 Regression] line number 0 for <built-in>
causes GAS to complain
I agree that -dD output should be preceded by a '#1 <built-on>' or
a '#0 <built-in>', since otherwise the output is a bit confusing:
# 1 "<stdin>"
#define __STDC_HOSTED__ 1
...
# 1 "<command line>"
We can determine that __STDC_HOSTED__ is <built-in> because the #define
preceded the "<command line>" but still it's confusing - and we might
consider suppressing the "<command line>" if there is nothing there.
Still, emitting the <built-in> ion this case makes sense.
Emitting a <built-in> before each#define is silly and ugly. We can
fix this with this patch:
Index: c-ppoutput.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-ppoutput.c,v
retrieving revision 1.25
diff -u -p -r1.25 c-ppoutput.c
--- c-ppoutput.c 25 Jun 2005 01:59:23 -0000 1.25
+++ c-ppoutput.c 12 Oct 2005 16:06:12 -0000
@@ -322,7 +322,8 @@ cb_define (cpp_reader *pfile, source_loc
fputs ((const char *) NODE_NAME (node), print.outf);
putc ('\n', print.outf);
- print.src_line++;
+ if (line != BUILTINS_LOCATION)
+ print.src_line++;
}
There is a similar annoyance for repeated "#1 <command-line>".
I'm hoping the above is uncontroversial, we still have three choices:
(1) always emit '#1 <built-in>' regardless.
(2) suppress the '#0 <built-in>' in the normal (non-'-dD') case
(2a) but emit '#0 <built-in>' before emitting <built-in> #defines; or
(2b) emit '#1 <built-in>' before emitting <built-in> #defines.
(2a) is I think cleaner (for humans) but assumes there aren't any
tools we care about that will be parsing -dD output *and* that
complain about line number 0 for <built-in>.
Implementation:
(1) Map line number 0 to line 1 in print_line.
(2a) My first patch (in comment #7).
(2b) My patch in comment #7 plus some other patch.
I expect another patch shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
