[Bug preprocessor/58687] New: "#line __LINE__ ..." changes subsequent line numbers

[Bug preprocessor/58687] New: "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

            Bug ID: 58687
           Summary: "#line __LINE__ ..." changes subsequent line numbers
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mtewoodbury at gmail dot com

A preprocessor directive of the form '#line __LINE__ ..." should NOT change the
line number.  That is '__LINE__' should evaluate to the number of the NEXT line
in this context.

If you read the standards carefully, __LINE__ should have a value equal to the
number of 'new line' characters seen by the phaee 1 translation plus one WHEN
THE SUBSTITUTION OCCURS (unless modified by previous #line directives).

When the subsituyion occurs is controlled by the parsing done in phase 4 of
translation.  Specifically, subsitution in preprocessing directives occure when
the specific form of the directive has been  formally identified AND that form
calls for <pp_token> aubstitution.  The form in this case is:

    '#' 'line' <pp_token>+ <new_line>

Note that the terminating <new line> token has to have been seen BEFORE the
form is identifiad.  That means __LINE__ will normally have the line number of
the NEXT line in the file when the substitution occurs.  FURTHER NOTE that any
<new line> tokens in comments will also have been counted when the substiturion
occurs.

What is apparently happening instead is that the substitution is being made
BEFORE the particular form of the '#line' directive has been completely and
formally identified.  In other wordds you have folded the translation phases
togeather and botched up the carefully structured procedure with its
intentional delays in substitution set forth in the standard.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #1 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Created attachment 31080
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31080&action=edit
test case

Comment out the '#line' directives and it compiles without error...

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

Max TenEyck Woodbury <mtewoodbury at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtewoodbury at gmail dot com

--- Comment #2 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Grumble!

Modified testsuite/gcc.dg/cpp/line4.c to test __LINE__ use.  I think I
saw a stronger set of tests while 'googling' the problem.  I was a bit
short on understanding when I saw it, so I didn't mark it for study...

I've looked at the code that handles this.  It's in the libcpp tree.

Thw indentation is messed up.  '\t' used in many places WITHOUT consistant
tab widths.  I see spots with '\t' stops at 4 and at 8.  Indent width is
mostly 2.  Style is a bit mixed.  FOR MY OWN USE, I've cleaned this up.
The result is much more readable.

I tried a simple look-ahead hack, but no go.

Going the mild KLUGE route:  Use a special value to indicate the bad
value and emit it under special circumstances.

- define the special value CUR__LINE__ in include/libcpp.h (-1)
- modify state.in_directive to have a special value (2) when in the #line
  directive (in do_line).
- check for the CUR__LINE__ value at the end of do_line after flushing the
  tokens and use replace the special value with the current line number
  before doing the state change.
- in macro.c, __LINE__ processing, look for the special stat.in_directive
  value and return CUR__LINE__ if it has the special value.

Potential problem if someone uses __LINE__ to construct the file name.

Intrest?

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #3 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Turn off the special case immediatly after getting the number to
eliminate side effects...

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

Max TenEyck Woodbury <mtewoodbury at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major

--- Comment #4 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Why is this important?

1)  There must be a way to modify the '__FILE__' value without messing
    up the '__LINE__' value.  A 'Google' shows that the expected way to
    do this is:

        # line __LINE__ "new-__FILE__-value"

    but with this bug, the __LINE__ value gets messed up and all 
    subsequent diagnostics are off by at least one.  It also makes
    debugging more difficult if not impossible.

    Now, why change the '__FILE__' value?

    Simply to make identification host independent.  The fact that my
    projects are stored on '/VOL10' on one of my machines and '/DATA0.2'
    on another only confuses any trouble reports.  What is important is
    that the file is 'myproject/configure.c' (or whatever).

2)  Similarly, adding multi-line comments to the '# line __LINE__ ...'
    directive should NOT mess with the line numbering.

3)  Why not use a specific value in place of '__LINE__'?

    Because that embeds a maintenance problem that should not be there
    into the source.  If something gets added before the '# line <n> ...'
    directive, then <n> has to be updated.  If the source is 'generated'
    by some tool, this is reasonable, but it is NOT reasonable for base
    level source files.  Similarly, there should be a freedom to edit
    the comment without having to play with the line number.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> Simply to make identification host independent.  The fact that my
>    projects are stored on '/VOL10' on one of my machines and '/DATA0.2'

This sounds like a bug in how you are compiling the sources.  Also there are
options inside GDB to transpose paths to the path on your machine.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #6 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to Andrew Pinski from comment #5)
> > Simply to make identification host independent.  The fact that my
> >    projects are stored on '/VOL10' on one of my machines and '/DATA0.2'
> 
> This sounds like a bug in how you are compiling the sources.  Also there are
> options inside GDB to transpose paths to the path on your machine.

It is precisely because the identification varies with the way to file name is
passed to the compiler that makes setting __FILE__ desirable.  The compiler
invocation details are not always under the developer's control.  Tools like
'make', 'autoconf' and 'automake' dictate the forms.  So, I have fairly strong
objections to calling it an external procedural BUG.  The issue REALLY is that
__LINE__ gets messed up; leave discussions of how the compiler is invoked out
of it.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #7 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
I have a patch written and I am testing it now.

What steps (other than posting it here when the tests are done) need to be done
to get it applied?

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Thanks for working on this bug.  http://gcc.gnu.org/contribute.html 
describes how to submit changes (including testcases etc.).

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #9 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #8)
> Thanks for working on this bug.  http://gcc.gnu.org/contribute.html 
> describes how to submit changes (including testcases etc.).

Thank you for the pointer.

As I said, I have a patch.  The patch includes an addition to the line4.c test
case.

What is delaying this is my testing of the change.  Specifically, I am
configuring, building bootstrap and building check for both the patched and
un-patched code then comparing the results.  The comparison was throwing up
many spurious differences due entirely to the slightly different directory
names I was using in the configuration process.  I think I now have those
details worked out, but there are still spurious differences due to temporary
file names, but I think that I can get past that.  It just takes hours for the
builds to complete...

Argh! -- someone put in a patch that I didn't track properly.  More details to
account for and another round of delays.  It'll be done when it's properly
tested.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Max TenEyck Woodbury from comment #9)
> temporary file names, but I think that I can get past that.  It just takes
> hours for the builds to complete...

If you are planning to do sporadic GCC development, it may be worthwhile to ask
for an account in the Compile Farm http://gcc.gnu.org/wiki/CompileFarm

(I could have never done any GCC development without it.)

For building GCC and testing patches there are several scripts in contrib/. I
also have my own:
http://gcc.gnu.org/wiki/ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFile&do=view&target=gccfarming
>From gcc-bugs-return-433068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 30 15:09:08 2013
Return-Path: <gcc-bugs-return-433068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12118 invoked by alias); 30 Oct 2013 15:09:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12085 invoked by uid 48); 30 Oct 2013 15:09:03 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
Date: Wed, 30 Oct 2013 15:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-58876-4-YvdRIDd4sV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58876-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58876-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg02212.txt.bz2
Content-length: 685

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX876

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Actually we can use this around the definition of default_delete<>

#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wsystem-headers"
  /// Primary template of default_delete, used by unique_ptr
  template<typename _Tp>
    struct default_delete
    {
...
    };
#pragma GCC diagnostic pop

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #11 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #10)
> 
> If you are planning to do sporadic GCC development, it may be worthwhile to
> ask for an account in the Compile Farm http://gcc.gnu.org/wiki/CompileFarm
> 
> (I could have never done any GCC development without it.)
> 
> For building GCC and testing patches there are several scripts in contrib/.
> I also have my own:
> http://gcc.gnu.org/wiki/
> ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFile&do=view&target=gccfarming

Thank you, I will look info all of that.  My own resources have limits; when it
comes to testing generated code on many architectures, I will definitely need
such resources.

I will also look at the scripts after I have a bit better handle on exactly
what kinds of problems testing raise.  I was mildly surprised that changing
line numbers in headers produced differences in what is obviously generated
code.  Without having seen that buried deep in the build directory tree, I am
sure I would not appreciate any scripts that interact with that aspect of the
build process.

I am at the base of the learning curve here.  I have some climbing to do before
I will be able to make significant contributions...

'make check' on the un-patched sources in progress.  Later...
>From gcc-bugs-return-433078-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 30 17:59:53 2013
Return-Path: <gcc-bugs-return-433078-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2648 invoked by alias); 30 Oct 2013 17:59:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2608 invoked by uid 55); 30 Oct 2013 17:59:49 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/47754] [missed optimization] AVX allows unaligned memory operands but GCC uses unaligned load and register operand
Date: Wed, 30 Oct 2013 17:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: minor
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-47754-4-0T5EzImZms@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-47754-4@http.gcc.gnu.org/bugzilla/>
References: <bug-47754-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg02222.txt.bz2
Content-length: 2485

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG754

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Oct 30 17:59:44 2013
New Revision: 204219

URL: http://gcc.gnu.org/viewcvs?rev 4219&root=gcc&view=rev
Log:
    PR target/47754
    * config/i386/i386.c (ix86_avx256_split_vector_move_misalign): If
    op1 is misaligned_operand, just use *mov<mode>_internal insn
    rather than UNSPEC_LOADU load.
    (ix86_expand_vector_move_misalign): Likewise (for TARGET_AVX only).
    Avoid gen_lowpart on op0 if it isn't MEM.

    * gcc.target/i386/avx256-unaligned-load-1.c: Adjust scan-assembler
    and scan-assembler-not regexps.
    * gcc.target/i386/avx256-unaligned-load-2.c: Likewise.
    * gcc.target/i386/avx256-unaligned-load-3.c: Likewise.
    * gcc.target/i386/avx256-unaligned-load-4.c: Likewise.
    * gcc.target/i386/l_fma_float_1.c: Use pattern for
    scan-assembler-times instead of just one insn name.
    * gcc.target/i386/l_fma_float_2.c: Likewise.
    * gcc.target/i386/l_fma_float_3.c: Likewise.
    * gcc.target/i386/l_fma_float_4.c: Likewise.
    * gcc.target/i386/l_fma_float_5.c: Likewise.
    * gcc.target/i386/l_fma_float_6.c: Likewise.
    * gcc.target/i386/l_fma_double_1.c: Likewise.
    * gcc.target/i386/l_fma_double_2.c: Likewise.
    * gcc.target/i386/l_fma_double_3.c: Likewise.
    * gcc.target/i386/l_fma_double_4.c: Likewise.
    * gcc.target/i386/l_fma_double_5.c: Likewise.
    * gcc.target/i386/l_fma_double_6.c: Likewise.

Modified:
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-1.c
    trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-2.c
    trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-3.c
    trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_double_1.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_double_2.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_double_3.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_double_4.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_double_5.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_double_6.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_float_1.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_float_2.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_float_3.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_float_4.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_float_5.c
    trunk/gcc/testsuite/gcc.target/i386/l_fma_float_6.c

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:

> Thank you, I will look info all of that.  My own resources have limits; when it
> comes to testing generated code on many architectures, I will definitely need
> such resources.

A fix for this particular bug should only need testing on one 
architecture.  It's not like changes to the register allocator that are 
likely to have architecture-specific issues.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #13 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #12)
> On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:
> 
>> Thank you, I will look info all of that.  My own resources have limits; when
>> it comes to testing generated code on many architectures, I will definitely
>> need such resources.
> 
> A fix for this particular bug should only need testing on one 
> architecture.  It's not like changes to the register allocator that are 
> likely to have architecture-specific issues.

Yes.  'make -w -k check' on the base configuration is still in progress. 
There's enough stuff wrong with the base that I need a log to check against. 
Using the compile farm here would add a queuing delay, slowing the process
further.

Oh, and could you mark this bug as either 'confirmed' or 'in-progress'?

I do have another bug (58884) that will need those resources if I am the one
that tackles fixing it...

Later...

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #14 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Created attachment 31125
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31125&action=edit
Patch to postpone __LINE__ evaluation to the end of a # line directive.

Patch includes changes to 2 source code files, a header and the line4.c test
case.

make bootstrap OK.

make -k check of patched and un-patched code matches except for time stamps.

Formal release of changes copyright to FSF granted.

Max TenEyck Woodbury

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #15 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Could you all give me some idea on how soon this might be applied?

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

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

--- Comment #16 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 4 Nov 2013, mtewoodbury at gmail dot com wrote:

> Could you all give me some idea on how soon this might be applied?

At some time after seeing this on gcc-patches, I or another preprocessor 
reviewer will review the patch (after checking that the FSF copyright.list 
file reflects receipt of the assignment, if the patch seems big enough to 
need it).

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #18 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #16)
> On Mon, 4 Nov 2013, mtewoodbury at gmail dot com wrote:
> 
> > Could you all give me some idea on how soon this might be applied?
> 
> At some time after seeing this on gcc-patches, I or another preprocessor 
> reviewer will review the patch (after checking that the FSF copyright.list 
> file reflects receipt of the assignment, if the patch seems big enough to 
> need it).

it's been a couple weeks.  Any progress?

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

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

--- Comment #19 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 19 Nov 2013, mtewoodbury at gmail dot com wrote:

> it's been a couple weeks.  Any progress?

I don't recall seeing this on gcc-patches (any patch attached to Bugzilla 
is taken as work-in-progress, not a submission for review) - please give 
the URL in the list archives of the patch submission.

(I don't see your assignment in fencepost:/gd/gnuorg/copyright.list, but 
the FSF does not always record paperwork in a particularly timely fashion; 
if it's been at least a week since you sent in paperwork, I advise chasing 
up assign@gnu.org.  It would require more careful consideration to see if 
this patch is actually large enough to need paperwork.)

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2013-11-28
     Ever confirmed|0                           |1

--- Comment #20 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Suspending pending a DR since I think the present code is correct and while the
standard is ambiguous I think the interpretation here strains the wording of
the standard.  I'd proposed to close this if a DR (or other WG14 document)
isn't under consideration at the Parma meeting of WG14.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #21 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to Joseph S. Myers from comment #20)
> Suspending pending a DR since I think the present code is correct and while
> the standard is ambiguous I think the interpretation here strains the
> wording of the standard.  I'd proposed to close this if a DR (or other WG14
> document) isn't under consideration at the Parma meeting of WG14.

A 'DR' is not necessary and is unlikely to be submitted.  The ambiguity
referred 
to is in the expansion of macros, not in the processing of directives.  

The elaborate description of the different forms of the '#line' (and other) 
directives makes it clear that <pp-token> expansion is not to take place until 
after the <end-of-line> for the directive has been seen.  

Accepted usage is for '#line __LINE__' to leave the line numbering unchanged.  
Any other interpretation would require some form of expression evaluation in 
order to leave line numbering unchanged; a possibility that has been rejected.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

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

--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:

> The elaborate description of the different forms of the '#line' (and other) 
> directives makes it clear that <pp-token> expansion is not to take place until 
> after the <end-of-line> for the directive has been seen.  

The question is not when it takes place, it's what the "current token" is 
when it takes place, because "line number" is defined in terms of the 
current token rather than the time of expansion.  I think the current 
token is clearly __LINE__ on the #line directive.  Consider the case where 
there are no more tokens after that directive, just the newline at the end 
of the directive (you can easily construct cases where the value of 
__LINE__ in such a context affects the validity of the program, by 
concatenating it with something else to form what might or might not be a 
macro name) - it's not possible the the current token to be anything on a 
subsequent line, because there aren't any subsequent tokens.  So the 
current token has got to be __LINE__ (or maybe, in the more complicated 
cases I referred to, something else on the #line line).  That's different 
from

macro
(
__LINE__
)

where all of the tokens from "macro" to ")" are involved in expansion at 
the same time and you can argue for any of "macro", "__LINE__" and ")" as 
being the "current token".  (It's also different from the cases where 
backslash-newline appears in the middle of __LINE__ so the question is 
whether "to the current token" means to the start of end of that token.)

> Accepted usage is for '#line __LINE__' to leave the line numbering unchanged.  

It's quite possible there's a common bug among multiple other 
implementations where it does leave the line number unchanged, but I'm now 
tending to that actually being a bug in those implementations rather than 
an ambiguity in the standard.  That is, there is no way in the standard to 
leave the line number unchanged, and no defect, and it might be better to 
wait until a revision process for a new major C standard version is 
underway them submit a proposal for e.g. #line with just a filename and no 
line number (or a #file directive - either would be a reasonable way of 
achieving that goal).

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #23 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #22)
> On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:
> 
> > The elaborate description of the different forms of the '#line' (and other) 
> > directives makes it clear that <pp-token> expansion is not to take place 
> > until after the <end-of-line> for the directive has been seen.  
> 
> The question is not when it takes place, it's what the "current token" is 
> when it takes place, because "line number" is defined in terms of the 
> current token rather than the time of expansion.

If that is what they meant, they would have said something like "the line 
number when the __LINE__ token is seen', but they say 'current line' and 
define 'current line' elsewhere.

> I think the current token is clearly __LINE__ on the #line directive.  

But the standard says 'current line'.  It says nothing about 'current 
token' in this context.

> Consider the case where 
> there are no more tokens after that directive, just the newline at the end 
> of the directive (you can easily construct cases where the value of 
> __LINE__ in such a context affects the validity of the program, by 
> concatenating it with something else to form what might or might not be a 
> macro name) - it's not possible the the current token to be anything on a 
> subsequent line, because there aren't any subsequent tokens.  So the 
> current token has got to be __LINE__ (or maybe, in the more complicated 
> cases I referred to, something else on the #line line).  That's different 
> from
> 
> macro
> (
> __LINE__
> )
> 
> where all of the tokens from "macro" to ")" are involved in expansion at 
> the same time and you can argue for any of "macro", "__LINE__" and ")" as 
> being the "current token".  (It's also different from the cases where 
> backslash-newline appears in the middle of __LINE__ so the question is 
> whether "to the current token" means to the start of end of that token.)
> 
You are arguing about macro expansion again.  Macro expansion is an 
immediate process and, as you pointed out, somewhat ambiguous.  The case 
being argued here is the expansion of <pp-tokens> in directives where their 
expansion is delayed until after the form of the directive has been 
established.

> > Accepted usage is for '#line __LINE__' to leave the line numbering 
> > unchanged.  
> 
> It's quite possible there's a common bug among multiple other 
> implementations where it does leave the line number unchanged, but I'm now 
> tending to that actually being a bug in those implementations rather than 
> an ambiguity in the standard.  That is, there is no way in the standard to 
> leave the line number unchanged, and no defect, and it might be better to 
> wait until a revision process for a new major C standard version is 
> underway them submit a proposal for e.g. #line with just a filename and no 
> line number (or a #file directive - either would be a reasonable way of 
> achieving that goal).

So everyone else is wrong?

Realty, you should consider what the users of the language need to be able 
to do.  There is need for an easy way to change __FILE__ without messing 
up the line number sequence.  '#line __LINE__ ...' is fairly obviously that 
mechanism and the extra verbiage in the standard is a fairly obvious 
attempt to accommodate that need.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

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

--- Comment #24 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:

> > The question is not when it takes place, it's what the "current token" is 
> > when it takes place, because "line number" is defined in terms of the 
> > current token rather than the time of expansion.
> 
> If that is what they meant, they would have said something like "the line 
> number when the __LINE__ token is seen', but they say 'current line' and 
> define 'current line' elsewhere.
> 
> > I think the current token is clearly __LINE__ on the #line directive.  
> 
> But the standard says 'current line'.  It says nothing about 'current 
> token' in this context.

The only uses of the phrase "current line" in C11 are in subclause 5.2.2 
Character display semantics; I suppose you mean "current source line".  
What 6.10.4 says is "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.", and 6.10.8.1 says __LINE__ expands to "The presumed line 
number (within the current source file) of the current source line (an 
integer constant).".  "line number of the current source line" is defined 
as a whole in terms of the "current token"; "current source line" is not 
something that's defined or meaningful by itself.  Not processing until 
expansion occurs, not processing until the form of a syntax construct is 
identified, but processing to the current token, which is surely __LINE__ 
in this case.

> You are arguing about macro expansion again.  Macro expansion is an 
> immediate process and, as you pointed out, somewhat ambiguous.  The case 
> being argued here is the expansion of <pp-tokens> in directives where their 
> expansion is delayed until after the form of the directive has been 
> established.

Expansion of those tokens is just one instance of macro expansion.  
Exactly the same ambiguity occurs in the case of

#line macro \
( \
__LINE__ \
)

(is "macro", "__LINE__" or ")" the current token?) and does not occur in 
the case of plain

#line __LINE__

> So everyone else is wrong?

Implementations not treating #line __LINE__ as giving the next line the 
same line number as the #line directive are either using a very strained 
interpretation of the standard, or haven't considered the issue and have 
achieved their results by accident.

> Realty, you should consider what the users of the language need to be able 
> to do.  There is need for an easy way to change __FILE__ without messing 
> up the line number sequence.  '#line __LINE__ ...' is fairly obviously that 
> mechanism and the extra verbiage in the standard is a fairly obvious 
> attempt to accommodate that need.

I don't believe the standard makes any such attempt to accommodate such a 
(marginal) need; the wording is simply the most natural way to describe 
the possible forms of #line directive within the style used by the 
standard.  Note there are no examples in the standard to indicate any 
particular intent regarding corner cases of #line or __LINE__.

If you disagree with an implementor (or conformance testsuite vendor, 
etc.) about the interpretation of the standard, the next step is to file a 
DR with WG14.  You can send proposed DRs directly to the convenor - most 
go that way - you don't need to go via your National Body (although WG14 
has no obligation to accept a document as a DR unless the formal NB 
process is followed).