[Bug preprocessor/94535] New: __LINE__ value changed for macro invocations spanning multiple lines

[Bug preprocessor/94535] New: __LINE__ value changed for macro invocations spanning multiple lines

[alisdairm at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

            Bug ID: 94535
           Summary: __LINE__ value changed for macro invocations spanning
                    multiple lines
           Product: gcc
           Version: 9.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alisdairm at me dot com
  Target Milestone: ---

Given the following simple program, the line that static_asserts changed from
gcc 8 to gcc 9 (and remains so for current trunk prior to 10's release):

#define LINE(DUMMY) __LINE__

constexpr int X = LINE(
                       wrap);

static_assert(X == 3); // gcc 8 and earlier, non-gcc compilers
static_assert(X == 4); // gcc 9 and 10

Note that every other compiler I have access to has the original gcc 8
behavior.
(tested widely with Godbolt compiler explorer, and on Solaris/AIX with native
compilers)

Unsurprisingly, this is breaking unit tests and other code similarly sensitive
to line numbers.

Godbolt link for quick testing: https://godbolt.org/z/LU--gC

[Bug preprocessor/94535] __LINE__ value changed for macro invocations spanning multiple lines

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Both values are valid I think.
Even rejecting the code is valid too; multiline macro functions are undefined
IIRC.

[Bug preprocessor/94535] __LINE__ value changed for funciton macro invocations spanning multiple lines

[alisdairm at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #2 from Alisdair Meredith <alisdairm at me dot com> ---
Thanks for the speedy response, really appreciated!

I believe this is well-defined behavior, but can accept that the value of
__LINE__ may be unspecified - I do struggle with pre-processor wording.

There is no multiline "macro function" here, there is an invocation of a macro,
and the invocation spans multiple lines.  Our actual use case looks more like:

   INVOKE_MACRO(ARG1,
                ARG2,
                ARG3);

Where the line-wraps are forced by coding convention and line-length limits. 
This is not a control-line that defined a macro, so I believe the token
sequence is taken after discarding irrelevant whitespace.  The issue is whether
__LINE__ should correspond to the line with the opening paren, the closing
paren, or one of the lines in-between.  Until gcc9, AFAICT, all compilers
agreed on the line with the opening paren.  Even if it is unspecified behavior
(so free to choose) it would be helpful to preserve a compatibility with past
gcc compilers, and all other tested compilers, unless there is a strong reason
to want the change.  If there were more compiler divergence on the issue, I
would be less concerned.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>There is no multiline "macro function" here, there is an invocation of a macro, and the invocation spans multiple lines. 

I miss-remembered the issue, the issue was only with preprocessor directives
inside macro functions (this changed in GCC 3.3 and above really).

But I still think both line #s are correct.  is the line at the opening of the
macro function or the closing?

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[alisdairm at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #4 from Alisdair Meredith <alisdairm at me dot com> ---
(In reply to Andrew Pinski from comment #3)

> I miss-remembered the issue, the issue was only with preprocessor directives
> inside macro functions (this changed in GCC 3.3 and above really).
> 
> But I still think both line #s are correct.  is the line at the opening of
> the macro function or the closing?

I have been bitten by that UB as well in the past, and can see the confusion :)

I believe I got it backwards in my previous message:
historically gcc and other compilers produced __LINE__ from the closing paren,
and from gcc 9 it is now determined by the opening paren.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Why not do this:
static_assert(X == 3 || X == 4);

There that works for both cases.

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Why not do this:
static_assert(X == 3 || X == 4);

There that works for both cases.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

Martin Sebor <msebor at gcc dot gnu.org> changed:

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

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
The following proposal was accepted into C2X last year:
  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2322.htm
It seems to me like it's about the same thing but I just skimmed it.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[alisdairm at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #8 from Alisdair Meredith <alisdairm at me dot com> ---
(In reply to Andrew Pinski from comment #6)
> Why not do this:
> static_assert(X == 3 || X == 4);
> 
> There that works for both cases.

The code example was intended to the be smallest reproducible example that
shows the value changing.  The typical failure we see is unit tests for our
testing framework, validating the message coming from our testing assert macros
and similar.  We format the error message we expect to see with a value offset
from the current line, to verify that the message captured writing to the
console (which we redirect for comparison) is the same.

We now need to adjust those tests, and similar, to account for the __LINE__
number varying in some testing invocations - which is doable.  My concern is
how many other folks are waiting to upgrade to gcc 9 and stumble over the same
issue?  If it is a dark enough corner, then maybe none :)

If this were to revert to historical behavior for gcc 10, we would just skip
those particular formatting tests on gcc9, as we have enough test coverage with
other compilers to have confidence in the message we output, and when actual
tests fire in production, they will still point to a valid line for our test
asserts.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[alisdairm at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #9 from Alisdair Meredith <alisdairm at me dot com> ---
(In reply to Martin Sebor from comment #7)
> The following proposal was accepted into C2X last year:
>   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2322.htm
> It seems to me like it's about the same thing but I just skimmed it.

Thanks - that is a good reference, and it looks that gcc9 is implementing the
new recommended best practice.  Does anyone active in SG14 know if existing
practice was surveyed before making this recommendation?  My testing has been
limited to C++ compilers, and I believe there are a wider range of C vendors
that may be relevant than my little survey had access to.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[alisdairm at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #10 from Alisdair Meredith <alisdairm at me dot com> ---
And double-checking the C++ Standard again, I think I have wording in favor of
my report and contradicting the recommended best practice for the pending C
standard:

[cpp.line]p2 "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.2)
while processing the source file to the current token."

We will not start interpreting the tokens for macro expansion until after
seeing
the closing paren for the invocation, which means counting all the newlines up
to
the closing paren, and so reporting the higher line number.

The joys of a shared pre-processor specification.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #11 from Martin Sebor <msebor at gcc dot gnu.org> ---
Fred, the author of the paper, usually tests a number of compilers.  In the
paper referenced from n2322 he mentions a bunch:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1911.htm

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This changed in r9-1926-g6f41f92bebfb0b5eb3a3859b1c3bb7710d1cb48b as PR69558
fix.

[Bug preprocessor/94535] __LINE__ value changed for function-like macro invocations spanning multiple lines

[alisdairm at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535

--- Comment #13 from Alisdair Meredith <alisdairm at me dot com> ---
As this has shipped for two releases now (gcc9 and 10) I recommend closing as
Works As Designed, citing C standard paper N2322 as reason for the change.