From: mike stump <mrs@windriver.com>
To: gcc@gcc.gnu.org, jbuck@synopsys.COM, lerdsuwa@users.sourceforge.net
Subject: Re: fix for PR 4447: is this really correct?
Date: Fri, 23 Nov 2001 22:03:00 -0000 [thread overview]
Message-ID: <200111302321.PAA17355@kankakee.wrs.com> (raw)
> 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.
WARNING: multiple messages have this Message-ID
From: mike stump <mrs@windriver.com>
To: gcc@gcc.gnu.org, jbuck@synopsys.COM, lerdsuwa@users.sourceforge.net
Subject: Re: fix for PR 4447: is this really correct?
Date: Fri, 30 Nov 2001 15:23:00 -0000 [thread overview]
Message-ID: <200111302321.PAA17355@kankakee.wrs.com> (raw)
Message-ID: <20011130152300.f_nVQ6H-EOQDl7um-uzWKQeM5ZO3TRu8ocZ36mUGxTw@z> (raw)
> 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.
next reply other threads:[~2001-11-30 23:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-23 22:03 mike stump [this message]
2001-11-24 5:14 ` Joe Buck
2001-11-30 16:20 ` Joe Buck
2001-11-30 15:23 ` mike stump
2001-12-03 9:49 ` Mark Mitchell
2001-12-03 9:53 ` Joe Buck
2001-12-03 9:56 ` Mark Mitchell
-- strict thread matches above, loose matches on Subject: below --
2001-12-03 15:40 mike stump
2001-11-24 15:40 mike stump
2001-11-30 18:14 ` mike stump
2001-12-01 16:14 ` Joe Buck
2001-11-21 22:25 GCC 3.0.3 Joe Buck
2001-11-23 14:47 ` fix for PR 4447: is this really correct? Joe Buck
2001-11-24 20:36 ` Kriang Lerdsuwanakij
2001-11-30 23:02 ` Kriang Lerdsuwanakij
2001-12-01 16:08 ` Joe Buck
2001-12-02 3:12 ` Kriang Lerdsuwanakij
2001-12-03 9:42 ` Mark Mitchell
2001-12-01 17:32 ` Alexandre Oliva
2001-11-30 11:20 ` Joe Buck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200111302321.PAA17355@kankakee.wrs.com \
--to=mrs@windriver.com \
--cc=gcc@gcc.gnu.org \
--cc=jbuck@synopsys.COM \
--cc=lerdsuwa@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).