[Bug c++/11437] New: [3.3/3.4] g++ segfaults

[Bug c++/11437] New: [3.3/3.4] g++ segfaults

[debian-gcc at lists dot debian dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: [3.3/3.4] g++ segfaults
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: debian-gcc at lists dot debian dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-linux
  GCC host triplet: i386-linux
GCC target triplet: i386-linux

[ forwarded from http://bugs.debian.org/200011 ]

void f (void) 
{ 
    struct { } a; 
    __imag__ a; 
} 
 
Only occurs with g++, not gcc.

[Bug c++/11437] ICE in lookup_name_real

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-07-04 21:53:44
               date|                            |
            Summary|[3.3/3.4] g++ segfaults     |ICE in lookup_name_real
   Target Milestone|3.4                         |---


------- Additional Comments From bangerth at dealii dot org  2003-07-04 21:53 -------
Confirmed. This crashes every gcc version I have since at least 2.95.

Here's a backtrace:
#0  lookup_name_real (name=0x0, prefer_type=0, nonclass=1, namespaces_only=0, 
    flags=2) at ../../gcc-3.4-CVS/gcc/cp/decl.c:5879
#1  0x0806cfe1 in lookup_name_nonclass (name=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/decl.c:5957
#2  0x0806d002 in lookup_function_nonclass (name=0x0, args=0xe)
    at ../../gcc-3.4-CVS/gcc/cp/decl.c:5963
#3  0x080531ca in build_new_op (code=132, flags=3, arg1=0x401ad804, arg2=0x0, 
    arg3=0x0) at ../../gcc-3.4-CVS/gcc/cp/call.c:3712
#4  0x08118d90 in build_x_unary_op (code=132, xarg=0x401ad804)
    at ../../gcc-3.4-CVS/gcc/cp/typeck.c:3896
#5  0x080fcdde in cp_parser_unary_expression (parser=0x0, address_p=false)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:4483
#6  0x080fd61c in cp_parser_pm_expression (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:4944
#7  0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x84923a0, fn=0x80fd600 <cp_parser_pm_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#8  0x080fd6c1 in cp_parser_multiplicative_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:4998
#9  0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x84923c0, 
    fn=0x80fd6a0 <cp_parser_multiplicative_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#10 0x080fd6f1 in cp_parser_additive_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5021
#11 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x84923d8, fn=0x80fd6d0 <cp_parser_additive_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#12 0x080fd721 in cp_parser_shift_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5044
#13 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x8492400, fn=0x80fd700 <cp_parser_shift_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#14 0x080fd751 in cp_parser_relational_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5079
#15 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x8492438, fn=0x80fd730 <cp_parser_relational_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#16 0x080fd781 in cp_parser_equality_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5102
#17 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x8492450, fn=0x80fd760 <cp_parser_equality_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#18 0x080fd7b1 in cp_parser_and_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5123
#19 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x8492460, fn=0x80fd790 <cp_parser_and_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#20 0x080fd7e1 in cp_parser_exclusive_or_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5144
#21 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x8492470, fn=0x80fd7c0 <cp_parser_exclusive_or_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#22 0x080fd811 in cp_parser_inclusive_or_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5166
#23 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x8492480, fn=0x80fd7f0 <cp_parser_inclusive_or_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#24 0x080fd841 in cp_parser_logical_and_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5187
#25 0x081068d2 in cp_parser_binary_expression (parser=0x401ab4c0, 
    token_tree_map=0x8492490, fn=0x80fd820 <cp_parser_logical_and_expression>)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13553
#26 0x080fd871 in cp_parser_logical_or_expression (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5208
#27 0x080fd999 in cp_parser_assignment_expression (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5307
#28 0x080fdaf8 in cp_parser_expression (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5456
#29 0x080fdedd in cp_parser_expression_statement (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5747
#30 0x080fdc6a in cp_parser_statement (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5660
#31 0x080fdfd7 in cp_parser_statement_seq_opt (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5805
#32 0x080fdf76 in cp_parser_compound_statement (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5778
#33 0x081033eb in cp_parser_ctor_initializer_opt_and_function_body (parser=0x4)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:11104
#34 0x08106d58 in cp_parser_function_definition_after_declarator (
    parser=0x401ab4c0, inline_p=220) at ../../gcc-3.4-CVS/gcc/cp/parser.c:13851
#35 0x08106cb2 in cp_parser_function_definition_from_specifiers_and_declarator
    (parser=0x401ab4c0, decl_specifiers=0x0, attributes=0x0, declarator=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:13797
#36 0x081019f0 in cp_parser_init_declarator (parser=0x401ab4c0, 
    decl_specifiers=0x4019bf3c, prefix_attributes=0x0, 
    function_definition_allowed_p=true, member_p=false, 
    function_definition_p=0xbffff037) at ../../gcc-3.4-CVS/gcc/cp/parser.c:9615
#37 0x080feb8e in cp_parser_simple_declaration (parser=0x401ab4c0, 
    function_definition_allowed_p=true)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:6587
#38 0x080fea64 in cp_parser_block_declaration (parser=0x401ab4c0, 
    statement_p=false) at ../../gcc-3.4-CVS/gcc/cp/parser.c:6513
#39 0x080fe91d in cp_parser_declaration (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:6433
#40 0x080fe7c8 in cp_parser_declaration_seq_opt (parser=0x0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:6342
#41 0x080fa0e2 in cp_parser_translation_unit (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:2256
#42 0x08107f02 in yyparse () at ../../gcc-3.4-CVS/gcc/cp/parser.c:14676
#43 0x08182036 in c_common_parse_file (set_yydebug=0)
    at ../../gcc-3.4-CVS/gcc/c-opts.c:1189
#44 0x083c0a4a in compile_file () at ../../gcc-3.4-CVS/gcc/toplev.c:2070
#45 0x083c5ad7 in do_compile () at ../../gcc-3.4-CVS/gcc/toplev.c:4960
#46 0x083c5b48 in toplev_main (argc=0, argv=0xbffff1f4)
    at ../../gcc-3.4-CVS/gcc/toplev.c:4989
#47 0x08185e5b in main (argc=0, argv=0x0) at ../../gcc-3.4-CVS/gcc/main.c:37
#48 0x400419ed in __libc_start_main () from /lib/libc.so.6
(gdb)

[Bug c++/11437] ICE in lookup_name_real

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From bangerth at dealii dot org  2003-07-04 21:54 -------
I forgot to say: I don't know whether the code is legal, but
it shouldn't ICE anyway, in particular not without any other message.

W.

[Bug c++/11437] ICE in lookup_name_real

[neroden at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From neroden at gcc dot gnu dot org  2003-07-09 03:54 -------
The bug will also show up with __imag and __real.

If I replace __imag__ with something like int, the backtrace when the error occurs
is the same from the top down to this point:
#29 0x080fdedd in cp_parser_expression_statement (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5747
#30 0x080fdc6a in cp_parser_statement (parser=0x401ab4c0)
    at ../../gcc-3.4-CVS/gcc/cp/parser.c:5660

In the case where it gets to the correct error message, it instead goes:
#7  0x080f90e9 in cp_parser_declaration_statement (parser=0x40133144)
    at ../../gcc-main/gcc/cp/parser.c:6079
#8  0x080f8760 in cp_parser_statement (parser=0x4018a4c0)
    at ../../gcc-main/gcc/cp/parser.c:5501

In other words, it fails to parse it as a declaration statement, and tries to parse it as an expression statement.
Which seems quite wrong to me.  For some cryptic reason, it doesn't recognize it as a type name.

The actual ICE is caused by something else:

#2  0x0806d002 in lookup_function_nonclass (name=0x0, args=0xe)
    at ../../gcc-3.4-CVS/gcc/cp/decl.c:5963
#3  0x080531ca in build_new_op (code=132, flags=3, arg1=0x401ad804, arg2=0x0, 
    arg3=0x0) at ../../gcc-3.4-CVS/gcc/cp/call.c:3712

Clearly we shouldn't be looking up a NULL name under any circumstances.  How this happens is beyond me.

[Bug c++/11437] ICE in lookup_name_real

[neroden at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From neroden at gcc dot gnu dot org  2003-07-09 05:51 -------
OK.  I now understand things better, and see that __imag is supposed to be an operator, which is kinda gross.

The bug can be reproduced with a of any class or struct type, but not with a of any numeric type (I guess they're implicitly converted or something).

My pointer to the ICE is still correct.  More info. :-)  build_x_unary_op decides that it should look for a function, so it calls build_new_op.
build_new_op is called with code==REALPART_EXPR or IMAGPART_EXPR.  Then we get to the line:
    fnname = ansi_opname (code);
which assigns to fnname the value 0x0, which is what gets passed to the function name lookup (looking for a user-defined operator).

Now, ansi_opname is a macro, expanding to:
(operator_name_info[(int) (CODE)].identifier)
__real__ and __imag__ aren't listed in operators.def, so their table entries are never initialized.
Isn't that lovely.

I think that points to an obvious fix.

[Bug c++/11437] ICE in lookup_name_real

[cvs-commit at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From cvs-commit at gcc dot gnu dot org  2003-07-11 23:01 -------
Subject: Bug 11437

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	neroden@gcc.gnu.org	2003-07-11 23:01:55

Modified files:
	gcc/cp         : operators.def ChangeLog 

Log message:
	PR c++/11437
	* operators.def: Add definitions for __imag__, __real__.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/operators.def.diff?cvsroot=gcc&r1=1.14&r2=1.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3512&r2=1.3513

[Bug c++/11437] ICE in lookup_name_real

[neroden at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


neroden at gcc dot gnu dot org changed:

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


------- Additional Comments From neroden at gcc dot gnu dot org  2003-07-12 03:47 -------
Now gives:

test.cxx:5: error: no match for 'operator__imag__' in '__imag__a'

Which is reasonable.
Closing as fixed (on mainline).

[Bug c++/11437] ICE in lookup_name_real

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neroden at gcc dot gnu dot
                   |                            |org
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


------- Additional Comments From bangerth at dealii dot org  2003-07-12 23:17 -------
Nathanael,
the error message has no spaces before or after the __imag__, in both parts
where it occurs. Can you add another patch to insert it there, i.e. rewrite
  operator__imag__
into
  operator __imag__
and 
  __imag__a
into
  __imag__ a
?

Thanks (and thanks for fixing the ICE in the first place!)
  Wolfgang

[Bug c++/11437] ICE in lookup_name_real

[neroden at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


neroden at gcc dot gnu dot org changed:

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


------- Additional Comments From neroden at gcc dot gnu dot org  2003-07-12 23:22 -------
That's way beyond me, because it's handled by operator-independent mangling code in the C++ front end.  Please open another PR for that issue.  :-)

[Bug c++/11437] ICE in lookup_name_real

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From bangerth at dealii dot org  2003-07-12 23:54 -------
OK, the new report is now PR 11510.
W.

[Bug c++/11437] ICE in lookup_name_real

[dhazeghi at yahoo dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.4


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