[PATCH] Fix PR c/12446
Eric Botcazou
ebotcazou@libertysurf.fr
Sat Oct 4 04:35:00 GMT 2003
> 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?
> The expected error texts allow both alternatives for a reason: to avoid
> spurious failures when the current testsuite is used with an old compiler
> (which used to be a standard part of regression testing releases - the new
> compiler should have no failures that aren't shown with the old one, but
> there's no need for gratuitous testcase changes that make the old one look
> worse than it was),
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.
> and because the point is to ensure that *some* reasonable error is given
> for the cases where the standard requires it rather than to guarantee a
> precise wording for every error. The tests should pass after this patch
> without needing to be changed: this laxity serves to save work when minor
> changes are made that may have a small effect on the error messages.
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.
> All these tests should use -pedantic-errors.
Do you mean that the dg-options line should have -pedantic-errors, or that
the error message should only be produced with -pedantic-errors?
> All the c90-array-lval-*.c tests have corresponding C99 tests - in this
> case, to verify that initialization works (only assignment being covered in
> the testsuite, as this bug uncovered).
Ok, I'll add the C99 counterpart.
> And dg-error doesn't guarantee that the diagnostic is an error rather than
> a warning, hence the more complex idiom used in these testcases to ensure
> that (one day dejagnu may get fixed and we can simplify the tests, but
> probably also need to fix many with the wrong one of dg-error and
> dg-warning).
Ah! Thanks for the correction.
--
Eric Botcazou
More information about the Gcc-patches
mailing list