Bug 21250 - [4.1 Regression] line number 0 for <built-in> causes GAS to complain
Summary: [4.1 Regression] line number 0 for <built-in> causes GAS to complain
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: 4.1.0
Assignee: Per Bothner
URL:
Keywords:
: 21634 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-27 13:30 UTC by Segher Boessenkool
Modified: 2005-10-14 17:07 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-09-10 05:52:30


Attachments
proposed patch (907 bytes, patch)
2005-10-12 16:45 UTC, Per Bothner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Segher Boessenkool 2005-04-27 13:30:10 UTC
powerpc64-linux-gcc -c -o any-file.o any-file.S 
 
results in 
 
any-file.S: Assembler messages: 
any-file.S:1: Warning: line numbers must be positive; line number 0 rejected 
 
as the pre-processed file looks like 
 
# 1 "any-file.S" 
# 0 "<built-in>" 
# 1 "<command line>" 
# 1 "any-file.S" 
... 
 
This regression is caused by 
 
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02132.html
Comment 1 Per Bothner 2005-04-28 05:12:40 UTC
Not sure what the right solution is.
We should be consistent as to whether definitions in <built-in>
have line 0 and line 1, and it wasn't before my change.
One option is to fix gas.
Another if to suppress the # 0 <built-in> line, as it doesn't
seem very useful.
Another is to declare this a gas bug.
There are of course others ....
(However, I'm on vacation and away from home, so deeling
with email and bugs i difficult.)
Comment 2 Segher Boessenkool 2005-04-28 15:08:39 UTC
The C standard has this to say about line numbers, in 6.10.4/2:

The line number of the current source line is one greater than the number of new-line characters read 
or introduced in translation phase 1 (5.1.1.2) while processing the source file to the current token. 

So, a line number of 0 is impossible.  GAS is correct to complain about this.

It would be nice to be consistent, yes; but consistently right, please, not
consistently wrong ;-)
Comment 3 Per Bothner 2005-04-28 23:59:10 UTC
Re comment #2:

I don't believe the text you quoted from the C standard is relevant.
<built-in> is not a "source file".

While the C standard isn't directly relevant to Gas, a relevant issue
is what the C standard says of #line directives: Should a C compiler
complain if it sees a line number zero in a #line directive?  Note this
is directly answered by your quotation.

But rather than argue standards, my inclination would be to use zero
as the pseudo-line-number of <built-in> declarations, but suppress the
output of the # 0 <built-in> in preprocessor output.  This will have to
be discussed on the gcc/gcc-patches mailing list (after I get back home).
Comment 4 Andrew Pinski 2005-05-17 21:55:28 UTC
*** Bug 21634 has been marked as a duplicate of this bug. ***
Comment 5 Paul Pluzhnikov 2005-09-15 23:31:20 UTC
The line '#0 <built-in>' causes trouble for other tools that work with 
the output from 'gcc -E'; e.g. edgcpfe refuses to parse it:

$ gcc -E - < /dev/null > junk.i && edgcpfe --c junk.i
"<stdin>", line 1: error: invalid line number
  # 0 "<built-in>"
    ^

1 error detected in the compilation of "junk.i".

What is the problem of emitting '#1 <built-in>' anyway?
Since neither corresponds to a "real" line number, it's not clear what
advantage '#0' has, especially if it is to be suppressed in the output.
Comment 6 Andrew Pinski 2005-10-12 00:15:02 UTC
Per,
Are you going to fix this soon, if not please say you have no time and I will look into it.

Thanks,
Andrew Pinski
Comment 7 per 2005-10-12 05:13:54 UTC
Subject: Re:  [4.1 Regression] line number 0 for <built-in>
 causes GAS to complain

pinskia at gcc dot gnu dot org wrote:
> ------- Comment #6 from pinskia at gcc dot gnu dot org  2005-10-12 00:15 -------
> Per,
> Are you going to fix this soon, if not please say you have no time and I will
> look into it.

I was awfully busy, but I had a little break so I could take a look.

The following patch seems like it might be reasonable, and it seems
to fix the immediate problem, but I haven't run a bootstrap yet.

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 05:09:19 -0000
@@ -394,7 +394,8 @@ pp_file_change (const struct line_map *m
  	    flags = " 1";
  	  else if (map->reason == LC_LEAVE)
  	    flags = " 2";
-	  print_line (map->start_location, flags);
+	  else if (map->start_location != BUILTINS_LOCATION)
+	    print_line (map->start_location, flags);
  	}
      }
  }
Comment 8 Paul Pluzhnikov 2005-10-12 06:16:57 UTC
The patch above suppresses the '#0 <built-in>', but not if one does:

  /usr/local/gcc-4.1-20050813/bin/gcc -v -E -dD - < /dev/null

in which case it *still* produces (now arguably plain wrong):

 # 1 "<stdin>"
 #define __STDC_HOSTED__ 1
 # 0 "<built-in>"
 #define __GNUC__ 4
 # 0 "<built-in>"
 #define __GNUC_MINOR__ 1
 ...

The patch below makes it emit this instead:

 # 1 "<stdin>"
 # 1 "<built-in>"
 #define __STDC_HOSTED__ 1
 # 1 "<built-in>"
 #define __GNUC__ 4
 # 1 "<built-in>"
 #define __GNUC_MINOR__ 1
 # 1 "<built-in>"
 #define __GNUC_PATCHLEVEL__ 0
 # 1 "<built-in>"

which roughly matches what gcc-3.x and 2.9x did.

May I repeat my question: 
What is the problem of emitting '#1 <built-in>' anyway?

--- gcc/c-opts.c.orig   2005-07-19 05:09:31.000000000 -0700
+++ gcc/c-opts.c        2005-10-11 22:57:34.000000000 -0700
@@ -1309,7 +1309,7 @@
 
       cb_file_change (parse_in,
                      linemap_add (&line_table, LC_RENAME, 0,
-                                  _("<built-in>"), 0));
+                                  _("<built-in>"), 1));
 
       cpp_init_builtins (parse_in, flag_hosted);
       c_cpp_builtins (parse_in);
Comment 9 per 2005-10-12 07:10:32 UTC
Subject: Re:  [4.1 Regression] line number 0 for <built-in>
 causes GAS to complain

ppluzhnikov at charter dot net wrote:

> May I repeat my question: 
> What is the problem of emitting '#1 <built-in>' anyway?

It's certainly better than emitting '#0 <built-in>', but is
there any reason for emitting either?

> --- gcc/c-opts.c.orig   2005-07-19 05:09:31.000000000 -0700
> +++ gcc/c-opts.c        2005-10-11 22:57:34.000000000 -0700
> @@ -1309,7 +1309,7 @@
> 
>        cb_file_change (parse_in,
>                       linemap_add (&line_table, LC_RENAME, 0,
> -                                  _("<built-in>"), 0));
> +                                  _("<built-in>"), 1));
> 
>        cpp_init_builtins (parse_in, flag_hosted);
>        c_cpp_builtins (parse_in);

See my rationale/discussion for the orginal patch:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02132.html
There is eisting code that assumes that builtins have line number 0.
Note this is *internally* - one option is to translate internal
line number 0 to line number 1 on output.  But I think the cleaner
solution is to just supress the '#' lines for <built-in>.

But people think it is important to keep the '#1 <built-in>' lines,
for compatibility, I can convinced.  I just think they're pointless.
Comment 10 per 2005-10-12 07:20:11 UTC
Subject: Re:  [4.1 Regression] line number 0 for <built-in>
 causes GAS to complain

What about 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 07:15:57 -0000
@@ -241,7 +241,7 @@ print_line (source_location src_loc, con
      putc ('\n', print.outf);
    print.printed = 0;

-  if (!flag_no_line_commands)
+  if (!flag_no_line_commands && src_loc != BUILTINS_LOCATION)
      {
        const struct line_map *map = linemap_lookup (&line_table, src_loc);

Comment 11 per 2005-10-12 16:22:35 UTC
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.
Comment 12 Per Bothner 2005-10-12 16:45:22 UTC
Created attachment 9977 [details]
proposed patch

This is my proposed patch.  It has not been boot-strapped yet.
I don't know if there might be problems with -g3 debug output.
Comment 13 CVS Commits 2005-10-14 14:56:56 UTC
Subject: Bug 21250

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	bothner@gcc.gnu.org	2005-10-14 14:56:49

Modified files:
	gcc            : c-ppoutput.c ChangeLog 

Log message:
	PR preprocessor/21250
	* c-ppoutput.c (print_line): Print internal line 0 as 1.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-ppoutput.c.diff?cvsroot=gcc&r1=1.26&r2=1.27
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10157&r2=2.10158

Comment 14 Andrew Pinski 2005-10-14 17:07:24 UTC
Fixed.
Comment 15 CVS Commits 2005-10-15 17:04:20 UTC
Subject: Bug 21250

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	bothner@gcc.gnu.org	2005-10-15 17:04:13

Modified files:
	gcc            : c-ppoutput.c ChangeLog 

Log message:
	PR preprocessor/21250
	* c-ppoutput.c (print_line): Print internal line 0 as 1.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-ppoutput.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.24&r2=1.24.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.465&r2=2.7592.2.466