[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[pinskia at gcc dot gnu dot org]

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

Thanks,
Andrew Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[per at bothner dot com]

------- Comment #7 from per at bothner dot com  2005-10-12 05:13 -------
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);
        }
      }
  }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[ppluzhnikov at charter dot net]

------- Comment #8 from ppluzhnikov at charter dot net  2005-10-12 06:16 -------
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);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[per at bothner dot com]

------- Comment #9 from per at bothner dot com  2005-10-12 07:10 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[per at bothner dot com]

------- Comment #10 from per at bothner dot com  2005-10-12 07:20 -------
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);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[per at bothner dot com]

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

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[bothner at gcc dot gnu dot org]

------- Comment #12 from bothner at gcc dot gnu dot org  2005-10-12 16:45 -------
Created an attachment (id=9977)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9977&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[cvs-commit at gcc dot gnu dot org]

------- Comment #13 from cvs-commit at gcc dot gnu dot org  2005-10-14 14:56 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2005-10-14 17:07 -------
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[cvs-commit at gcc dot gnu dot org]

------- Comment #15 from cvs-commit at gcc dot gnu dot org  2005-10-15 17:04 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[ppluzhnikov at charter dot net]

------- Additional Comments From ppluzhnikov at charter dot net  2005-09-15 23:31 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at charter dot
                   |                            |net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-17 21:55 -------
*** Bug 21634 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |falk at debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[bothner at gcc dot gnu dot org]

------- Additional Comments From bothner at gcc dot gnu dot org  2005-04-28 23:59 -------
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).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[segher at kernel dot crashing dot org]

------- Additional Comments From segher at kernel dot crashing dot org  2005-04-28 15:08 -------
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 ;-)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[bothner at gcc dot gnu dot org]

------- Additional Comments From bothner at gcc dot gnu dot org  2005-04-28 05:12 -------
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.)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bothner at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-28 05:12:41
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250

[Bug preprocessor/21250] [4.1 Regression] line number 0 for <built-in> causes GAS to complain

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|line number 0 for <built-in>|[4.1 Regression] line number
                   |causes GAS to complain      |0 for <built-in> causes GAS
                   |                            |to complain
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250