From: Andrew_Pinski@PlayStation.Sony.Com
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, C++] Make Canonical ICE instead of just warn when mismatching
Date: Fri, 05 Jan 2007 00:17:00 -0000 [thread overview]
Message-ID: <OFDDFF1606.48E075E5-ON8825725A.0000E2A6-8825725A.00018B87@playstation.sony.com> (raw)
In-Reply-To: <20070105000339.GA3489@nevyn.them.org>
Daniel Jacobowitz <drow@false.org> wrote on 01/04/2007 04:03:39 PM:
> On Thu, Jan 04, 2007 at 07:00:22PM -0500, Andrew Pinski wrote:
> > Except what Mike is talking about is not really an issue we should
> > be worrying about right now because again this is an internal check.
> > If GCC is broken, why try to continue?
>
> You haven't thought enough about the reason the warning was added as a
> warning. Please go read it again, and then think about it (and don't
> copy me about it again). Thanks.
The only thing the warning says to me, is that GCC is broken. And if an
user
gets it, what can they do except complain or ignore it. With an internal
compiler error, they are more willing to complain about that than a
warning
being there. If it was an internal error, we would have caught the issue
with
tramp3d earlier.
The warning is useless to the common user of GCC really. I don't see why
I am getting push back on a simple change that is actually obviously the
correct
thing to do for an internal check. Can I now then change all the internal
checking
ICEs into warnings because that is what the real issue here? To me,
Canonical
types was not thought through enough if this was a warning and the
reviewer of
the patch should have caught this issue when reviewing the patch in the
first place.
There are multiple issues with Canonical types right now, since it causes
memory usage
to go up around 1-2% (in C and other langauge code) which seems like not a
good thing
when most of the problems are really just internal to the C++ front-end
rather than
in generic code.
Thanks,
Andrew Pinski
next prev parent reply other threads:[~2007-01-05 0:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-04 5:30 Andrew_Pinski
2007-01-04 19:23 ` Mike Stump
2007-01-04 21:00 ` Andrew_Pinski
2007-01-04 22:26 ` Doug Gregor
2007-01-06 8:25 ` Eric Botcazou
2007-01-04 22:36 ` Mike Stump
2007-01-04 23:44 ` Andrew_Pinski
2007-01-04 23:48 ` Daniel Jacobowitz
2007-01-04 23:59 ` Andrew Pinski
2007-01-05 0:03 ` Daniel Jacobowitz
2007-01-05 0:17 ` Andrew_Pinski [this message]
2007-01-05 6:44 ` Gabriel Dos Reis
2007-01-05 14:14 ` Doug Gregor
2007-01-05 14:16 ` Richard Kenner
2007-01-05 6:41 ` Gabriel Dos Reis
2007-01-05 2:04 ` Mike Stump
2007-01-05 3:13 ` Brooks Moses
2007-01-05 14:13 ` Doug Gregor
2007-01-05 14:20 ` Richard Guenther
2007-01-05 14:35 ` Doug Gregor
2007-01-05 19:04 ` Mike Stump
2007-01-05 19:12 ` Richard Guenther
2007-01-08 5:14 ` Andrew Pinski
2007-01-05 6:35 ` Gabriel Dos Reis
2007-01-05 6:33 ` Gabriel Dos Reis
2007-01-23 3:41 ` Mark Mitchell
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=OFDDFF1606.48E075E5-ON8825725A.0000E2A6-8825725A.00018B87@playstation.sony.com \
--to=andrew_pinski@playstation.sony.com \
--cc=gcc-patches@gcc.gnu.org \
/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).