Andrew Pinski wrote:
On Aug 22, 2005, at 1:27 AM, Mark Mitchell wrote:
(Quite a few of the diagnostic messages
stem from the design decision to issue warnings from the
optimizers...)
Only 8 out of 49 at that, though some are very minor as two are just
complaining wording of the warning.
It was a little snarky of me to throw that in there; I do realize this
is considered a settled issue. As you know, it's a pet peeve of mine.
I still think that until we give up on this approach we're going to see
strange warning behavior; the price of our quest for better accuracy
will be less predictability and less consistency from release to release.
And almost all are uninitialized warnings which are always questionable as
there is no way to warn from
the front-end without flow control.
Most compilers use very simplistic methods for doing these warnings, in
their front ends. They still use control flow, but in much simpler
ways. The accuracy of the warnings is therefore less than in GCC (in
that, generally, other compilers warn less often than GCC, and therefore
detect fewer problems), but the number of false positives is generally
nearly zero.
Though I don't agree, it's certainly true that the consensus has been to
try for greater accuracy, by using the optimizers. I'm not trying to
upset the apple cart; I was just throwing in a little barb.
to the next. If we don't care about diagnostic bugs (which we really
should
but it seems like we don't), then can we just remove the target milestones
for all of those too.
No, we should not do that. As you say, we should be trying to fix them.
Though, naturally, they're less important, all things equal, to
wrong-code, rejects-valid, or ice-on-valid bugs.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
