GCC Bugzilla – Bug 11105
[3.3/3.4 regression of sorts] ICE in mangle_conv_op_name_for_type
Last modified: 2004-01-17 04:22:55 UTC
[Mark, this is likely related to 8006 and 9729, which is why I CC: you] This is an attempt to work around a problem in 11097, but with both 3.3 and mainline we either get an error for an ABI problem or, if one specifies -fabi-version=0, an ICE (see below). The code compiled with prior versions, although probably to bogus results. So it's a regression-of-sorts, but the present state is clearly not very desirable -- you can't compile the code even if the miscompilation would not lead to problems in a given program. So here's the testcase: ---------------------------------- template <typename T> struct S { struct I{}; operator I* (); }; template <typename T> struct S2 : S<T> { operator typename S<T>::I* (); }; template struct S2<int>; -------------------------------- g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc -fabi-version=1 x.cc:7: error: due to a defect in the G++ 3.2 ABI, G++ has assigned the same mangled name to two different types g/x> g/x> g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc -fabi-version=0 x.cc:7: internal compiler error: in mangle_conv_op_name_for_type, at cp/mangle.c:2653 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Results with 3.3 are the same. W.
Confirmed on the mainline (20030608).
Also confirmed on 3.3.1 (20030526).
Subject: Bug 11105 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2003-06-17 16:58:20 Modified files: gcc/cp : ChangeLog cp-tree.h mangle.c search.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.ext: pretty2.C Added files: gcc/testsuite/g++.dg/template: conv7.C conv8.C Removed files: gcc/testsuite/g++.dg/abi: conv1.C Log message: PR c++/11105 * cp-tree.h (DECL_CONV_FN_TYPE): New method. * mangle.c (struct globals): Remove internal_mangling_p. (write_unqualified_name): Use DECL_CONV_FN_TYPE. (write_template_parm): Don't write out the level number. (conv_type_names): New variable. (hash_type): New function. (compare_type): Likewise. (mangle_conv_op_name_for_type): Don't try to mangle conversion operator names. * search.c (lookup_conversion_operator): New function. (lookup_fnfields_1): Use it. PR c++/11105 * g++.dg/abi/conv1.C: Remove it. * g++.dg/template/conv7.C: New test. * g++.dg/template/conv8.C: Likewise. * g++.old-deja/g++.ext/pretty2.C: Do not test __FUNCTION__ for a conversion operator. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3427&r2=1.3428 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.852&r2=1.853 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/mangle.c.diff?cvsroot=gcc&r1=1.72&r2=1.73 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/search.c.diff?cvsroot=gcc&r1=1.264&r2=1.265 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.2773&r2=1.2774 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/abi/conv1.C.diff?cvsroot=gcc&r1=1.1&r2=NONE http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/conv7.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/conv8.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.ext/pretty2.C.diff?cvsroot=gcc&r1=1.7&r2=1.8
Subject: Bug 11105 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: mmitchel@gcc.gnu.org 2003-06-17 17:05:16 Modified files: gcc/cp : ChangeLog cp-tree.h decl.c mangle.c search.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.ext: pretty2.C Added files: gcc/testsuite/g++.dg/template: conv7.C conv8.C Log message: 2003-06-17 Mark Mitchell <mark@codesourcery.com> PR c++/11105 * cp-tree.h (DECL_CONV_FN_TYPE): New method. * decl.c (lookup_name_real): Backport conversion operator code from mainline. * mangle.c (struct globals): Remove internal_mangling_p. (write_unqualified_name): Use DECL_CONV_FN_TYPE. (write_template_parm): Don't write out the level number. (conv_type_names): New variable. (hash_type): New function. (compare_type): Likewise. (mangle_conv_op_name_for_type): Don't try to mangle conversion operator names. * search.c (lookup_conversion_operator): New function. (lookup_fnfields_1): Use it. 2003-06-17 Mark Mitchell <mark@codesourcery.com> PR c++/11105 * g++.dg/abi/conv1.C: Remove it. * g++.dg/template/conv7.C: New test. * g++.dg/template/conv8.C: Likewise. * g++.old-deja/g++.ext/pretty2.C: Do not test __FUNCTION__ for a conversion operator. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.146&r2=1.3076.2.147 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.776.2.20&r2=1.776.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.965.2.46&r2=1.965.2.47 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/mangle.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.63.2.3&r2=1.63.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/search.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.243.2.9&r2=1.243.2.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.186&r2=1.2261.2.187 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/conv7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/conv8.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.ext/pretty2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.6&r2=1.6.54.1
Fixed with attached patch.
Mark, with your patch, the compiler does now no longer give an error in default mode on the small code snippet. That is, either we now miss issuing the error, or your patch actually changes the mangling, but this would be an ABI change. Was that the intent of the patch, found here: http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01962.html Note that this question really is at the heart of PR 11812, which I will close in a minute since it is a duplicate of this re-opened PR. W.
*** Bug 11812 has been marked as a duplicate of this bug. ***
This patch removed the erroneous manglings. It is true that there are some functions whose manglings might change, but only where those manglings could have collided with other functions before. There is no way to win here. The regression we had before was that perfectly legal code that worked fine with GCC 2.95 couldn't be correctly compiled; now it compiles, but it is perhaps mangled differently than GCC 3.2. This is the same kind of ABI change that you get when you find out that you're passing two arguments to a function in the same stack slot. If you don't fix it, your compiler is horribly broken.
Sorry to repeat myself, but I don't see how this answers my original question in bug 11812: is this the regression of a regression or did the definition of ABI compatibility change from 3.3 to 3.3.1?
Subject: Re: [3.3/3.4 regression of sorts] ICE in mangle_conv_op_name_for_type On Thu, 2003-08-07 at 11:00, jhr dot walter at t-online dot de wrote: > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11105 > > > > ------- Additional Comments From jhr dot walter at t-online dot de 2003-08-07 18:00 ------- > Sorry to repeat myself, but I don't see how this answers my original question > in bug 11812: is this the regression of a regression or did the definition of > ABI compatibility change from 3.3 to 3.3.1? Neither. It's a bug fix. A necessary consequence of the bug fix is that some functions are mangled differently. We've never tried to say that maintaining ABI compatibility would prevent us from fixing bugs. That's not true for the C compiler either.
I think what Mark wants to say is the following: the old state was that the compiler silently generated code that might not have worked. The original "fix" was to have it generate an error to notify you of this. The fix to 11105 then changed the error to a working compiler that just did the right thing. It's true that this changed the ABI, but since it changed it from a nonfunctional to a functional state, it's not an ABI change that can break existing, working code. In this respect, we're still backward compatible and there is no need to guard the fix with -fabi-version=x. W.
OK, I'm trying to understand: > the old state was that the compiler silently generated code that might not > have worked. 3.2 generates the same mangled name for some different types. > The original "fix" was to have it generate an error to notify you of this. 3.3 generates no code for the 3.2 ABI: due to a defect in the G++ 3.2 ABI, G++ has assigned the same mangled name to two different types. When linking 3.3 code against 3.2 code nobody would know what happens. > The fix to 11105 then changed the error to a working compiler that just did > the right thing. 3.3.1 generates some code for the 3.2 ABI. But when linking 3.3.1 code against 3.2 code still nobody would know what happens (I assume ;-). Isn't ABI compatibility all about linking code compiled with different compilers?
Subject: Re: [3.3/3.4 regression of sorts] ICE in mangle_conv_op_name_for_type > Isn't ABI compatibility all about linking code compiled with different > compilers? Right, but what's the reason to keep link compatibility with code that might or might not work, depending on uncontrollable circumstances? W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
> Right, but what's the reason to keep link compatibility with code that might > or might not work, depending on uncontrollable circumstances? OK, but this would answer the original question: the definition of ABI compatibility has changed from 3.3 to 3.3.1: gcc is neither compatible nor incompatible to buggy code: behaviour simply is undefined. Thanks, Joerg