Re: preprocessor/7022: #line in .i files is broken in gcc 3.1

Re: preprocessor/7022: #line in .i files is broken in gcc 3.1

[neil]

Synopsis: #line in .i files is broken in gcc 3.1

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Thu Jun 13 13:29:29 2002
State-Changed-Why:
    This is intentional: -fpreprocessed only expects to see what can appear in a preprocessed file.  In particular, it doesn't expand macros, and #line expects macros to expand.
    
    Please change your tool to do the # markers; they work on all versions of GCC.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7022

Re: preprocessor/7022: #line in .i files is broken in gcc 3.1

[Ted Merrill]

The following reply was made to PR preprocessor/7022; it has been noted by GNATS.

From: Ted Merrill <ted@arraycomm.com>
To: neil@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>, <ted@arraycomm.com>, <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: preprocessor/7022: #line in .i files is broken in gcc 3.1
Date: Thu, 13 Jun 2002 13:42:59 -0700 (PDT)

 You are basically saying that the only preprocessor you will support
 is the one shipped with GCC.
 While that is "legally" ok from the point of the C standard,
 it is a very restrictive view.
 However, i suppose you have more important things to worry about,
 and i will (have, in fact) changed the tool we use.
 Thanks for considering this issue,
 Ted Merrill
 
 On 13 Jun 2002 neil@gcc.gnu.org wrote:
 
 > Synopsis: #line in .i files is broken in gcc 3.1
 >
 > State-Changed-From-To: open->closed
 > State-Changed-By: neil
 > State-Changed-When: Thu Jun 13 13:29:29 2002
 > State-Changed-Why:
 >     This is intentional: -fpreprocessed only expects to see what can appear in a preprocessed file.  In particular, it doesn't expand macros, and #line expects macros to expand.
 >
 >     Please change your tool to do the # markers; they work on all versions of GCC.
 >
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7022
 >
 

Re: preprocessor/7022: #line in .i files is broken in gcc 3.1

[Neil Booth]

The following reply was made to PR preprocessor/7022; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: ted@arraycomm.com
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/7022: #line in .i files is broken in gcc 3.1
Date: Thu, 13 Jun 2002 21:31:14 +0100

 ted@arraycomm.com wrote:-
 
 > I think there are two areas in the source code that need a
 > fix.  Most importantly, there is some problem with generic
 > #line handling that i have not figured out.
 > Secondarily, there is code to peek at the first line of a
 > file for a # <number> directive, which is clearly broken
 > since it does not check for #line ... if this never
 > got fixed it would be no big deal.
 
 That code is deliberate too.  Remember that the .i file is
 really just a contract between the preprocessor and the compiler,
 whose semantics and format need not be documented, and do change
 subtly from time to time.
 
 The compiler expects to see a # <NUM> line at the beginning
 of a file to tell it what the original file was.  The preprocessor
 doesn't output #line, so there is no check for it.
 
 Neil.

preprocessor/7022: #line in .i files is broken in gcc 3.1

[ted]

>Number:         7022
>Category:       preprocessor
>Synopsis:       #line in .i files is broken in gcc 3.1
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 13 12:36:04 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Ted Merrill
>Release:        gcc-3.1
>Organization:
>Environment:
Sparc solaris
>Description:
gcc-3.1 chokes on #line directive in a pre-processed (.i)
file.  This worked in gcc-3.0.4 and earlier.

We make heavy use of a tool that modifies C code
after passing through the preprocessor.
We can modify the tool to work around this bug
(by producing the # number  format...)
but it would still be nice to get this fixed.
>How-To-Repeat:
E.g. the following:

#line 1 "mainfile.c"
int x;

#line 23 "specialfile"
int y;

produces the following (with -v option):

Reading specs from /opt/local/gnu/gcc3-64/lib/gcc-lib/sparc64-sun-solaris2.8/3.1/specs
Configured with: ../gcc-3.1/configure --prefix=/opt/local/gnu/gcc3-64 --enable-languages=c,c++ --enable-threads=posix --verbose --enable-long-long --enable-shared --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --with-cpu=ultrasparc --disable-nls sparc64-sun-solaris2.8
Thread model: posix
gcc version 3.1
 /opt/local/gnu/gcc3-64/lib/gcc-lib/sparc64-sun-solaris2.8/3.1/cc1 -fpreprocessed ilinebug2.i -quiet -dumpbase ilinebug2.i -version -o /var/tmp//ccILGXxb.s
GNU CPP version 3.1 (cpplib) (sparc ELF)
GNU C version 3.1 (sparc64-sun-solaris2.8)
        compiled by GNU C version 3.1.
ilinebug2.i:1: syntax error at '#' token
ilinebug2.i:1: parse error before numeric constant
ilinebug2.i:4: syntax error at '#' token


>Fix:
I think there are two areas in the source code that need a
fix.  Most importantly, there is some problem with generic
#line handling that i have not figured out.
Secondarily, there is code to peek at the first line of a
file for a # <number> directive, which is clearly broken
since it does not check for #line ... if this never
got fixed it would be no big deal.
>Release-Note:
>Audit-Trail:
>Unformatted: