This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR c/12446
On Sat, 4 Oct 2003, Eric Botcazou wrote:
> > Both messages are reasonable (the types *are* incompatible - you can't
> > assign an array (that hasn't decayed to a pointer) to a pointer).
>
> Agreed, but I find the original one easier to understand for non C experts.
> Are you ok to standardize on this one for both cases?
I don't object to using the more precise error messages.
> Do you mean that you run the new testsuite against the old compiler? Then
> there will be failures anyway, so I don't really see the problem. It is also
> a standard practice to simply adjust error line numbers, so failures are to
> be expected with the old compiler in the old part of the testsuite.
There will be failures - but there should be a vaguely realistic
indication of how much better the new compiler is, and in this case the
compiler hasn't fixed bugs shown by the existing testcases, but rather
tweaked some error messages (not a change that generally gets tested
except where the old messages were actually *wrong*) as part of fixing
another bug not previously covered by the testsuite.
If you don't *need* to change a testcase to accommodate changed error
messages, then doing so is dubious; rather keep the testcase testing
exactly what it was testing before (whatever that might be). In this case
the testcases allowed multiple possible messages, which should cover both
the old and the new.
> The change to gcc.dg/c90-array-lval-1.c simply reverts your changes, since
> the patch reverts your changes to the error message. And
> gcc.dg/c90-array-lval-3.c duplicates part of gcc.dg/c90-array-lval-1.c.
But reverting changes to an error message doesn't require reverting
changes to a corresponding testcase - the testcases allow both variant
messages because both are OK! The point of the conformance tests is to
test conformance rather than fine details of error message wording. (The
Ada maintainers have insisted in the past that the parts of ACATS
requiring a baseline giving precise error messages for erroneous code
would not be useful at all for GCC because of the amount of work involved
in updating them after slight refinements to error messages - hopefully
the approach used in the C and C++ testsuites of using much weaker regexps
to match against messages shows its benefits in this regard.)
> Do you mean that the dg-options line should have -pedantic-errors, or that
> the error message should only be produced with -pedantic-errors?
The dg-options line should have -pedantic-errors - all the conformance
tests do except for a few where it's specifically being tested that
-std=whatever should suffice for valid code to be accepted without any
further options.
--
Joseph S. Myers
jsm@polyomino.org.uk