This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
fix for PR 4447: is this really correct?
- From: Joe Buck <jbuck at synopsys dot COM>
- To: gcc at gcc dot gnu dot org, lerdsuwa at users dot sourceforge dot net
- Date: Fri, 30 Nov 2001 11:20:51 -0800 (PST)
- Subject: fix for PR 4447: is this really correct?
I wrote:
> I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
> Actually I don't think any porting is needed, as it's a fix to mangle.c,
> which hasn't had many changes; no, it doesn't change the ABI because
> hitting the relevant code caused a core dump before.
>
> This PR is an ICE and a regression from 2.95.x.
> I believe that the relevant patch is
>
> 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net>
>
> * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
> CONST_CAST_EXPR.
> * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.
Mark approved, assuming the usual testing requirements are met.
I've now verified that this fix doesn't break any C++ or libstdc++ tests
(other tests aren't relevant since this only affects cc1plus).
But I am now not sure that this fix is quite correct, though it does
improve things.
Here's the testcase:
----------------------------------------------
template<bool B,int I>
class T {
public:
T(int);
};
template<bool B1,bool B2,int I1,int I2>
T<(B1&&B2),I1+I2-int(B1&&B2)>
func(T<B1,I1> a, T<B2,I2> b) {
return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2);
}
void foo(T<true,3> a, T<true,4>b) {
func(a, b);
}
----------------------------------------------
gcc 3.0 through 3.0.2 get an ICE in the name mangler. With Kriang's
patch, the code compiles, but doing
nm -p crash.o | c++filt
on Solaris gives
0000000000 T foo(T<true, 3>, T<true, 4>)
0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
rather than
0000000000 T foo(T<true, 3>, T<true, 4>)
0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
as I would expect. It may be that the oddball expression for the return
type will not affect correctness and will just contribute to bloat instead
(for the purpose of "linkonce" directives, instantiations that are really
the same will look different). But it looks wrong.
Comments? I may still want this for 3.0.3, because it does make some
cases that ICE'd before work correctly (in my fixed-point computation
examples the relevant functions are inline so these oddball symbols
probably won't even appear).