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