[Bug c++/57945] New: internal compiler error: in varpool_get_node, at cgraph.h:840

[Bug c++/57945] New: internal compiler error: in varpool_get_node, at cgraph.h:840

[cas43 at cs dot stanford.edu]

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

            Bug ID: 57945
           Summary: internal compiler error: in varpool_get_node, at
                    cgraph.h:840
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cas43 at cs dot stanford.edu

== Compiling this code: ==

static __typeof(pthread_once) __gthrw_pthread_once __attribute__
((__weakref__("pthread_once")));


== like this: ==

g++ prog.cpp


== produces this output: ==

prog.cpp:1:17: error: ‘pthread_once’ was not declared in this scope
 static __typeof(pthread_once) __gthrw_pthread_once __attribute__
((__weakref__("pthread_once")));
                 ^
prog.cpp:1:97: error: invalid type in declaration before ‘;’ token
 static __typeof(pthread_once) __gthrw_pthread_once __attribute__
((__weakref__("pthread_once")));
                                                                               
                 ^
prog.cpp:1:97: internal compiler error: in varpool_get_node, at cgraph.h:840
0x4f087f varpool_get_node
    ../../s-4.9/gcc/cgraph.h:840
0xcea462 varpool_get_node
    ../../s-4.9/gcc/varpool.c:281
0xcea462 varpool_analyze_node(varpool_node*)
    ../../s-4.9/gcc/varpool.c:288
0x7d42c7 analyze_functions
    ../../s-4.9/gcc/cgraphunit.c:935
0x7d5735 finalize_compilation_unit()
    ../../s-4.9/gcc/cgraphunit.c:2097
0x5edde0 cp_write_global_declarations()
    ../../s-4.9/gcc/cp/decl2.c:4356
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

== using this version of gcc: ==

Using built-in specs.
COLLECT_GCC=../new-gcc/i-4.9/bin/g++
COLLECT_LTO_WRAPPER=/home/craig/new-gcc/i-4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../s-4.9/configure --prefix=/home/craig/new-gcc/i-4.9
Thread model: posix
gcc version 4.9.0 20130718 (experimental) (GCC)
>From gcc-bugs-return-426423-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 21 03:19:51 2013
Return-Path: <gcc-bugs-return-426423-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9787 invoked by alias); 21 Jul 2013 03:19:49 -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 7661 invoked by uid 48); 21 Jul 2013 03:17:45 -0000
From: "cas43 at cs dot stanford.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57946] New: internal compiler error: Segmentation fault in int_fits_type_p
Date: Sun, 21 Jul 2013 03:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cas43 at cs dot stanford.edu
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-57946-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-07/txt/msg00930.txt.bz2
Content-length: 2860

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

            Bug ID: 57946
           Summary: internal compiler error: Segmentation fault in
                    int_fits_type_p
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cas43 at cs dot stanford.edu

when compiling this program:

enum ENUM2 {  ENUM2_a = (enum ENUM2) 4,  ENUM2_b = 0x9FFFFFFF,  ENUM2_c 0x100000000 };

like this:  g++ prog.cpp

I get this output:

prog.cpp:1:40: internal compiler error: Segmentation fault
   enum ENUM2 {  ENUM2_a = (enum ENUM2) 4,  ENUM2_b = 0x9FFFFFFF,  ENUM2_c 0x100000000 };
                                        ^
0xaac4cf crash_signal
    ../../s-4.9/gcc/toplev.c:333
0xc9c684 int_fits_type_p(tree_node const*, tree_node const*)
    ../../s-4.9/gcc/tree.c:8543
0x6587ae ocp_convert(tree_node*, tree_node*, int, int, int)
    ../../s-4.9/gcc/cp/cvt.c:754
0x656437 cp_build_c_cast(tree_node*, tree_node*, int)
    ../../s-4.9/gcc/cp/typeck.c:7052
0x619f1f cp_parser_binary_expression
    ../../s-4.9/gcc/cp/parser.c:7692
0x61a3df cp_parser_assignment_expression
    ../../s-4.9/gcc/cp/parser.c:7928
0x61a836 cp_parser_assignment_expression
    ../../s-4.9/gcc/cp/parser.c:7978
0x61a836 cp_parser_constant_expression
    ../../s-4.9/gcc/cp/parser.c:8188
0x60dfc7 cp_parser_enumerator_definition
    ../../s-4.9/gcc/cp/parser.c:15361
0x60dfc7 cp_parser_enumerator_list
    ../../s-4.9/gcc/cp/parser.c:15308
0x60dfc7 cp_parser_enum_specifier
    ../../s-4.9/gcc/cp/parser.c:15234
0x60dfc7 cp_parser_type_specifier
    ../../s-4.9/gcc/cp/parser.c:14014
0x622ad9 cp_parser_decl_specifier_seq
    ../../s-4.9/gcc/cp/parser.c:11288
0x626599 cp_parser_simple_declaration
    ../../s-4.9/gcc/cp/parser.c:10878
0x6285a0 cp_parser_block_declaration
    ../../s-4.9/gcc/cp/parser.c:10827
0x63160b cp_parser_declaration
    ../../s-4.9/gcc/cp/parser.c:10724
0x6302dd cp_parser_declaration_seq_opt
    ../../s-4.9/gcc/cp/parser.c:10610
0x631b92 cp_parser_translation_unit
    ../../s-4.9/gcc/cp/parser.c:3930
0x631b92 c_parse_file()
    ../../s-4.9/gcc/cp/parser.c:28827
0x742ad4 c_common_parse_file()
    ../../s-4.9/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


Compiler version:

Using built-in specs.
COLLECT_GCC=/home/craig/new-gcc/i-4.9/bin/g++
COLLECT_LTO_WRAPPER=/home/craig/new-gcc/i-4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../s-4.9/configure --prefix=/home/craig/new-gcc/i-4.9
Thread model: posix
gcc version 4.9.0 20130718 (experimental) (GCC)

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-27
            Summary|internal compiler error: in |[4.9 Regression] ICE: in
                   |varpool_get_node, at        |varpool_get_node, at
                   |cgraph.h:840                |cgraph.h:840
     Ever confirmed|0                           |1

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[reichelt at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|2013-07-27 00:00:00         |2013-10-05
                 CC|                            |reichelt at gcc dot gnu.org
      Known to work|                            |4.7.0, 4.8.0
      Known to fail|                            |4.9.0

--- Comment #1 from Volker Reichelt <reichelt at gcc dot gnu.org> ---
Here's an even simpler testcase which is probably valid (at least it was
accepted in 4.8.x):

=================================================
static int i __attribute__((weakref("j")));
=================================================

cc1plus: internal compiler error: in varpool_get_node, at cgraph.h:891
0x512ddc varpool_get_node
        ../../gcc/gcc/cgraph.h:891
0xd2d101 varpool_get_node
        ../../gcc/gcc/varpool.c:389
0xd2d101 varpool_analyze_node(varpool_node*)
        ../../gcc/gcc/varpool.c:396
0x804217 analyze_functions
        ../../gcc/gcc/cgraphunit.c:1035
0x805739 finalize_compilation_unit()
        ../../gcc/gcc/cgraphunit.c:2260
0x618920 cp_write_global_declarations()
        ../../gcc/gcc/cp/decl2.c:4365
Please submit a full bug report, [etc.]

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
I have another test case that generates this ICE.

Source code available on request.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Honza?

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Even better something that uses it and that even declares the original:
extern int j;
static int i __attribute__((weakref("j")));

int
foo (void)
{
  return &i ? i : 0;
}

This ICEs with cc1plus even at -O2, since r199971.  The problem is that
node->alias_target is IDENTIFIER_NODE, some places cope with it being
IDENTIFIER_NODE (in fact, I don't see where it would become something
different), but some places just blindly assume it must be a DECL_P.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> Even better something that uses it and that even declares the original:
> extern int j;
> static int i __attribute__((weakref("j")));
> 
> int
> foo (void)
> {
>   return &i ? i : 0;
> }
> 
> This ICEs with cc1plus even at -O2, since r199971.  The problem is that
> node->alias_target is IDENTIFIER_NODE, some places cope with it being
> IDENTIFIER_NODE (in fact, I don't see where it would become something
> different), but some places just blindly assume it must be a DECL_P.

It is IDENTIFIER_NODE until it is "resolved" into a target symbol that
is a decl (and one gets proper reference edge in symbol table). 
For normal aliases the identifier_node gets turned into a decl after
compilation unit is finalized (via resolve_alias). External weakrefs may
be never resolved...

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> ---
OK, somewhat confusing on the testcase above is that j is defined, but C++ FE
never consider it uses and thus never passes it to middle-end.

The problem is that C++ FE chose to first assemble alias:
#0  assemble_alias (decl=<var_decl 0x7ffff70401c8 i>, target=
    <identifier_node 0x7ffff7047c08 j>) at ../../gcc/varasm.c:5682
#1  0x0000000000ca94cc in rest_of_decl_compilation (decl=<var_decl
0x7ffff70401c8 i>, 
    top_level=1, at_end=0) at ../../gcc/passes.c:205
#2  0x0000000000610745 in make_rtl_for_nonlocal_decl (decl=<var_decl
0x7ffff70401c8 i>, 
    init=<tree 0x0>, asmspec=0x0) at ../../gcc/cp/decl.c:5909
#3  0x0000000000613173 in cp_finish_decl (decl=<var_decl 0x7ffff70401c8 i>,
init=
    <tree 0x0>, init_const_expr_p=false, asmspec_tree=<tree 0x0>, flags=1)
    at ../../gcc/cp/decl.c:6480
#4  0x000000000073291d in cp_parser_init_declarator (parser=0x7ffff7048000, 
    decl_specifiers=0x7fffffffe2f0, checks=0x0,
function_definition_allowed_p=true, 
    member_p=false, declares_class_or_enum=0,
function_definition_p=0x7fffffffe37f, 
    maybe_range_for_decl=0x0) at ../../gcc/cp/parser.c:16804
#5  0x0000000000729785 in cp_parser_simple_declaration (parser=0x7ffff7048000, 
    function_definition_allowed_p=true, maybe_range_for_decl=0x0)
    at ../../gcc/cp/parser.c:11195
#6  0x0000000000729573 in cp_parser_block_declaration (parser=0x7ffff7048000,
statement_p=
    false) at ../../gcc/cp/parser.c:11076
#7  0x00000000007292ee in cp_parser_declaration (parser=0x7ffff7048000)
    at ../../gcc/cp/parser.c:10973
#8  0x0000000000728e68 in cp_parser_declaration_seq_opt (parser=0x7ffff7048000)
    at ../../gcc/cp/parser.c:10859
#9  0x000000000071cfdd in cp_parser_translation_unit (parser=0x7ffff7048000)
    at ../../gcc/cp/parser.c:4018
#10 0x00000000007519b4 in c_parse_file () at ../../gcc/cp/parser.c:31322
#11 0x00000000008b5e5d in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1056
#12 0x0000000000daf45f in compile_file () at ../../gcc/toplev.c:547
#13 0x0000000000db14da in do_compile () at ../../gcc/toplev.c:1887
#14 0x0000000000db1649 in toplev_main (argc=3, argv=0x7fffffffe6a8)
    at ../../gcc/toplev.c:1963
#15 0x000000000155cb50 in main (argc=3, argv=0x7fffffffe6a8) at
../../gcc/main.c:36

and then finalize variable

#0  varpool_finalize_decl (decl=<var_decl 0x7ffff70401c8 i>) at
../../gcc/cgraphunit.c:824
#1  0x0000000000ca96ca in rest_of_decl_compilation (decl=<var_decl
0x7ffff70401c8 i>, 
    top_level=1, at_end=0) at ../../gcc/passes.c:238
#2  0x0000000000610745 in make_rtl_for_nonlocal_decl (decl=<var_decl
0x7ffff70401c8 i>, 
    init=<tree 0x0>, asmspec=0x0) at ../../gcc/cp/decl.c:5909

It should do just one of these.

Index: passes.c
===================================================================
--- passes.c    (revision 206013)
+++ passes.c    (working copy)
@@ -187,6 +187,8 @@ rest_of_decl_compilation (tree decl,
               int top_level,
               int at_end)
 {
+  bool finalize = true;
+
   /* We deferred calling assemble_alias so that we could collect
      other attributes such as visibility.  Emit the alias now.  */
   if (!in_lto_p)
@@ -203,6 +205,7 @@ rest_of_decl_compilation (tree decl,
     DECL_EXTERNAL (decl) = 0;
     TREE_STATIC (decl) = 1;
     assemble_alias (decl, alias);
+    finalize = false;
       }
   }

@@ -234,7 +237,7 @@ rest_of_decl_compilation (tree decl,
          rebuild it.  */
       if (in_lto_p && !at_end)
         ;
-      else if (TREE_CODE (decl) != FUNCTION_DECL)
+      else if (finalize && TREE_CODE (decl) != FUNCTION_DECL)
         varpool_finalize_decl (decl);
     }

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
That patch is OK.

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Honza, can you commit the patch then?

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Fri Jan 17 14:19:55 2014
New Revision: 206708

URL: http://gcc.gnu.org/viewcvs?rev=206708&root=gcc&view=rev
Log:
    PR c++/57945
    * passes.c (rest_of_decl_compilation): Don't call varpool_finalize_decl
    on decls for which assemble_alias has been called.

    * c-c++-common/torture/pr57945.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/torture/pr57945.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/passes.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed by Honza's patch I've checked in.