Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.0.1/specs Configured with: ../configure --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld Thread model: posix gcc version 3.0.1 GNU CPP version 3.0.1 (cpplib) (sparc) ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.7/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include/g++-v3 /usr/local/include/g++-v3/sparc-sun-solaris2.7 /usr/local/include/g++-v3/backward /usr/local/include /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.0.1/include /usr/include End of search list. /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.0.1/cc1plus -fpreprocessed gcc_et_bug.ii -quiet -dumpbase gcc_et_bug.cpp -version -o gcc_et_bug.s GNU CPP version 3.0.1 (cpplib) (sparc) GNU C++ version 3.0.1 (sparc-sun-solaris2.7) compiled by GNU C version 3.0.1. gcc_et_bug.cpp: In function `int main()': gcc_et_bug.cpp:67: Internal error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. Release: gcc-3.0.1 Environment: sparc-solaris-2.7 How-To-Repeat: Compile the attached file
State-Changed-From-To: open->analyzed State-Changed-Why: confirmed
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org> Cc: Subject: Re: c++/4926: Segmentation Fault on Legal Code Date: Fri, 1 Nov 2002 14:31:33 -0600 (CST) It's too bad that templates with typeof are still broken in some places, since the (standards conforming) workarounds are also not working always. Here's a redux of PR 4926: -------------------------------------- template <unsigned> struct X { typedef int Type; }; template <typename T> struct Y { char array[1]; }; template<typename T> Y<T> P(T); // acts as "Y<typeof(T)>" struct F { int operator()() const; }; template <typename T> typename X<sizeof(P( T()() ).array)>::Type foo(); int main() { foo<F>(); }; -------------------------------------- By changing F::operator() into a "regular" member function, all sorts of other bugs can be triggered before the compiler finally crashed :-( Regards Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth
Confirmed with branch and mainline (20030603).
The C++ ABI does not specify how to mangle function names which contains template parameters like sizeof(complex_expression). Thus, this bug is suspended until the ABI committee takes a decision. The situation is a bit better now though, on mainline the reduced testcase will produce a "sorry, unimplemented" message, and then crash (component_ref has exactly the same problem). The crash can be fixed with this patch: Index: mangle.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/cp/mangle.c,v retrieving revision 1.79 diff -c -p -w -r1.79 mangle.c *** mangle.c 30 Jun 2003 19:02:04 -0000 1.79 --- mangle.c 1 Jul 2003 18:14:22 -0000 *************** write_expression (tree expr) *** 2023,2028 **** --- 2023,2032 ---- write_expression (TREE_OPERAND (expr, 0)); break; + case COMPONENT_REF: + write_expression (TREE_OPERAND (expr, 0)); + write_source_name (TREE_OPERAND (expr, 1)); + break; /* Handle pointers-to-members specially. */ case SCOPE_REF: which is correct per-se, but it's part of this "mangle.c can't handle complex expressions" stuff which needs clarifications from the C++ ABI committee. So, I'll keep this around for later.
I've been dealing with mangling issues recently.
Fixed by Jason's patch 2009-03-17 Jason Merrill <jason@redhat.com> * decl.c (grokfndecl): Set DECL_CONTEXT on parms. (duplicate_decls): Adjust DECL_CONTEXT of newdecl's parms. * pt.c (check_explicit_specialization): Likewise. (tsubst_copy) [PARM_DECL]: Return a dummy parm if we don't have a local specialization. * tree.c (cp_tree_equal) [PARM_DECL]: Check type and index, not name. * decl2.c (parm_index): New fn. * semantics.c (finish_decltype_type): Don't use describable_type. * mangle.c (write_expression): Likewise. Mangle ALIGNOF_EXPR. Give a sorry for unsupported codes rather than crash. Mangle conversions with other than 1 operand. New mangling for PARM_DECL. * operators.def (ALIGNOF_EXPR): Mangle as "az".
It shouldn't be closed without a testcase.
Even though the testcase in comment #2 compiles, it fails to link: tmp/ccsV5xgT.o: In function `main':^M pr4926-1.C:(.text+0x5): undefined reference to `X<sizeof ((P(((F)())())).array)>::Type foo<F>()'^M collect2: ld returned 1 exit status^M
I'm sorry, where is the definition of foo? Of course it doesn't link.
Subject: Bug 4926 Author: hjl Date: Wed Apr 1 18:09:21 2009 New Revision: 145423 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145423 Log: 2009-04-01 H.J. Lu <hongjiu.lu@intel.com> PR c++/4926 * g++.dg/template/pr4926-1.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr4926-1.C Modified: trunk/gcc/testsuite/ChangeLog
Subject: Bug 4926 Author: hjl Date: Wed Apr 1 18:10:52 2009 New Revision: 145424 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145424 Log: 2009-04-01 H.J. Lu <hongjiu.lu@intel.com> Backport from mainline: 2009-04-01 H.J. Lu <hongjiu.lu@intel.com> PR c++/4926 * g++.dg/template/pr4926-1.C: New. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/pr4926-1.C - copied unchanged from r145423, trunk/gcc/testsuite/g++.dg/template/pr4926-1.C Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
The testcase in the first attachment still failed to compile as of revision 145378: [hjl@gnu-6 gcc]$ ./xgcc -B./ -S /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii: In function ‘int main()’: /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry, unimplemented: mangling template_id_expr /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry, unimplemented: mangling template_id_expr /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry, unimplemented: mangling template_id_expr [hjl@gnu-6 gcc]$ Is this expected?
Subject: Re: C++ ABI needs clarification on mangling of complex expressions hjl dot tools at gmail dot com wrote: > /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry, > unimplemented: mangling template_id_expr > > Is this expected? That is in fact still unimplemented, and a good reason not to close the PR. Jason
Actually, we have PR 38712 specifically about the template-id case, so let's go ahead and close this PR.
Subject: Bug 4926 Author: jason Date: Wed Feb 3 20:42:48 2010 New Revision: 156482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156482 Log: PR c++/4926 PR c++/38600 * mangle.c (write_unqualified_id): Split out from write_expression. (write_unqualified_name): Call it. (write_member_name): Likewise. (write_expression): Support TEMPLATE_ID_EXPR. Disambiguate operator names. Added: trunk/gcc/testsuite/g++.dg/abi/mangle35.C trunk/gcc/testsuite/g++.dg/abi/mangle37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected