From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15950 invoked by alias); 15 Jan 2010 15:06:35 -0000 Received: (qmail 15916 invoked by uid 48); 15 Jan 2010 15:06:22 -0000 Date: Fri, 15 Jan 2010 15:06:00 -0000 Message-ID: <20100115150622.15915.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/42758] ICE on assert() in function with complex(?) template argument In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "matz at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg01884.txt.bz2 ------- Comment #3 from matz at gcc dot gnu dot org 2010-01-15 15:06 ------- input_location handling is broken. (gdb) bt #0 0x00007ffff704a7c3 in strcmp () from /lib64/libc.so.6 #1 0x00000000011be858 in splay_tree_splay (sp=0x1824110, key=0) at ../../gcc/libiberty/splay-tree.c:148 #2 0x00000000011beed6 in splay_tree_lookup (sp=0x1824110, key=0) at ../../gcc/libiberty/splay-tree.c:389 #3 0x00000000007b162a in get_fileinfo (name=0x0) at ../../gcc/gcc/c-lex.c:114 note: name==0, this comes from: #25 0x0000000000765939 in fname_as_string (pretty_p=1) at ../../gcc/gcc/c-common.c:950 #26 0x00000000004e0b3a in cp_make_fname_decl (loc=1708071, id=0x7ffff7e91ec8, type_dep=1) at ../../gcc/gcc/cp/decl.c:3559 #27 0x0000000000765a7a in fname_decl (loc=1708071, rid=67, id=0x7ffff7e91ec8) at ../../gcc/gcc/c-common.c:999 Where the block in c-common.c is: 995 location_t saved_location = input_location; 996 input_location = UNKNOWN_LOCATION; 997 998 stmts = push_stmt_list (); 999 decl = (*make_fname_decl) (loc, id, fname_vars[ix].pretty); I.e. input_location is reset (that is okay here), then through the make_fname_decl call the c++ frontend is called back, which tries to construct a decl, implicitely (via cxx_make_type) accessing the fileinfo for input_filename. We want to create the __PRETTY_FUNCTION__ string decl here. I can't say if it's more sensible if the C++ frontend would deal with input_location==UNKNOWN_LOCATION sometimes, or if c-common.c should be changed to not reset it temporarily. But the latter really makes sense here, as the __PRETTY_FUNCTION__ decl is created on demand, i.e. a random place, which it then would get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758