[Bug preprocessor/58844] [4.8/4.9 Regression] ICE with invalid use of ##

[Bug preprocessor/58844] [4.8/4.9 Regression] ICE with invalid use of ##

[reichelt at gcc dot gnu.org]

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

Volker Reichelt <reichelt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
      Known to work|                            |4.6.0, 4.7.0
   Target Milestone|---                         |4.8.3
      Known to fail|                            |4.8.0, 4.9.0

[Bug preprocessor/58844] New: [4.8/4.9 Regression] ICE with invalid use of ##

[reichelt at gcc dot gnu.org]

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

            Bug ID: 58844
           Summary: [4.8/4.9 Regression] ICE with invalid use of ##
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet triggers an ICE since GCC 4.8.0:

======================
#define X A######A
X
======================

bug.c:2:1: internal compiler error: Segmentation fault
 X
 ^
0x963a4f crash_signal
        ../../gcc/gcc/toplev.c:335
0xe7c107 paste_all_tokens
        ../../gcc/libcpp/macro.c:668
0xe7c107 cpp_get_token_1
        ../../gcc/libcpp/macro.c:2364
0x5d087c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
        ../../gcc/gcc/c-family/c-lex.c:300
0x56d103 c_lex_one_token
        ../../gcc/gcc/c/c-parser.c:223
0x56e240 c_parser_peek_2nd_token
        ../../gcc/gcc/c/c-parser.c:447
0x58653e c_parser_declaration_or_fndef
        ../../gcc/gcc/c/c-parser.c:1482
0x589285 c_parser_external_declaration
        ../../gcc/gcc/c/c-parser.c:1380
0x589d21 c_parser_translation_unit
        ../../gcc/gcc/c/c-parser.c:1267
0x589d21 c_parse_file()
        ../../gcc/gcc/c/c-parser.c:13222
0x5d8683 c_common_parse_file()
        ../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

[Bug preprocessor/58844] [4.8/4.9 Regression] ICE with invalid use of ##

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-19
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug preprocessor/58844] [4.8/4.9 Regression] ICE with invalid use of ##

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32159
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32159&action=edit
gcc49-pr58844.patch

Untested fix.

Regarding the validity of this testcase,
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html
suggests that it is valid rather than invalid.

[Bug preprocessor/58844] [4.8/4.9 Regression] ICE with invalid use of ##

[dodji at gcc dot gnu.org]

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

--- Comment #4 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
yes, the patch looks good to me.

Thank you for looking into that.

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |ice-on-valid-code
      Known to work|                            |4.9.0
            Summary|[4.8/4.9 Regression] ICE    |[4.8 Regression] ICE with
                   |with invalid use of ##      |invalid use of ##
      Known to fail|4.9.0                       |

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Mar  6 08:10:08 2014
New Revision: 208370

URL: http://gcc.gnu.org/viewcvs?rev=208370&root=gcc&view=rev
Log:
    Backport from mainline
    2014-02-19  Jakub Jelinek  <jakub@redhat.com>

    PR preprocessor/58844
    * macro.c (enter_macro_context): Only push
    macro_real_token_count (macro) tokens rather than
    macro->count tokens, regardless of
    CPP_OPTION (pfile, track-macro-expansion).

    * c-c++-common/cpp/pr58844-1.c: New test.
    * c-c++-common/cpp/pr58844-2.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/cpp/pr58844-1.c
    branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/cpp/pr58844-2.c
Modified:
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/libcpp/ChangeLog
    branches/gcc-4_8-branch/libcpp/macro.c

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |4.8.3
         Resolution|---                         |FIXED

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
reasoning why gcc considers it valid.

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[potswa at mac dot com]

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

--- Comment #11 from David Krauss <potswa at mac dot com> ---
On 2014–08–12, at 3:10 PM, jakub at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
wrote:

> Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for
> reasoning why gcc considers it valid.

That reasoning goes awry at “ISO C is silent about this possibility.” C and C++
both say,

> each instance of a ## preprocessing token in the replacement list (not from an argument) is deleted and the preceding preprocessing token is concatenated with the following preprocessing token.

This is unambiguous in that consecutive ## tokens get pasted; they can’t all be
operators. The spec also says, “The order of evaluation of ## operators is
unspecified,” which doesn’t seem like much of a constraint but it does suggest
that they are evaluated one-by-one.

The standard also says “If the result is not a valid preprocessing token, the
behavior is undefined,” so no diagnosis is required. However, there have been a
couple proposals to make it required, so it’s a very good idea. Even if the
user really meant them to be operators, it won’t be portable.
>From gcc-bugs-return-458236-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 12 08:07:00 2014
Return-Path: <gcc-bugs-return-458236-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24075 invoked by alias); 12 Aug 2014 08:07:00 -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 23909 invoked by uid 48); 12 Aug 2014 08:06:51 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
Date: Tue, 12 Aug 2014 08:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: lto
X-Bugzilla-Keywords: build, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels 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: cc
Message-ID: <bug-62077-4-l5qP5J2cb1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62077-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62077-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: 2014-08/txt/msg00733.txt.bz2
Content-length: 815

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb077

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #9 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Sven C. Dack from comment #7)
> > Created attachment 33299 [details]
> > Removes the use of the jobserver from bootstrap-lto.mk
> >
> > The patch changes bootstrap-lto.mk to use a single, unpartitioned stream
> > instead of the jobserver.
>
> This patch makes sense from a reproducibility point of view too.

But it will increase the build-time enormously.

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 12 Aug 2014, potswa at mac dot com wrote:

> > each instance of a ## preprocessing token in the replacement list (not 
> > from an argument) is deleted and the preceding preprocessing token is 
> > concatenated with the following preprocessing token.
> 
> This is unambiguous in that consecutive ## tokens get pasted; they can't 
> all be operators.

I think my reading was: they are all operators, all get deleted, and then, 
after the deletion, the (preceding, following) pairs of remaining tokens 
get concatenated (the concatenations happening in an unspecified order, 
with it being OK if they do all happen simultaneously).

I see nothing to rule out that sequence of events, or any other sequence 
of deletions and concatenations of tokens (where if the sequence results 
in ## being concatenated with a non-placemarker, you have undefined 
behavior).  I wouldn't object to a future standard revision tightening up 
what's allowed here - though if you do the obvious tightening of adding a 
new Constraint "Two consecutive ## preprocessing tokens shall not occur in 
the replacement list for either form of macro definition." (to C11 
6.10.3.3), implementation of that would need to be conditional on the 
standard version selected (it's clear that macro definitions with 
consecutive ## are valid at present and only their expansion may result in 
undefined behavior).

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Also, in the case of just two consecutive ##, with a placemarker either 
side, I think however you read it the concatenations are currently valid 
and you end up with no preprocessing tokens in the expansion.

#define m(a,b) a####b
m(,)