This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fix for PR 4447: is this really correct?
- From: mike stump <mrs at windriver dot com>
- To: gcc at gcc dot gnu dot org, jbuck at synopsys dot COM, lerdsuwa at users dot sourceforge dot net
- Date: Fri, 30 Nov 2001 15:21:50 -0800 (PST)
- Subject: Re: fix for PR 4447: is this really correct?
> From: Joe Buck <jbuck@synopsys.COM>
> To: gcc@gcc.gnu.org, lerdsuwa@users.sourceforge.net
> Date: Fri, 30 Nov 2001 11:20:51 -0800 (PST)
> 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).
If I understand the fix, it is worse than not having it, as it hides a
real bug?
> But I am now not sure that this fix is quite correct, though it does
> improve things.
I think the ICE is preferable, as otherwise you have to explain that
you have to break the ABI, which is worse.
> 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>)
Ick! Looks like a bug.
> Comments? I may still want this for 3.0.3, because it does make
> some cases that ICE'd before work correctly
Is that working correctly? I don't think so. From an, I don't care
about the abi, yes, it works fine, but from an, gosh, what do you mean
you totally broke the abi, I thought you said you weren't going to do
that, it looks like absolute horror.