On Mon, 9 Mar 2020, Christophe Lyon wrote:
> Hi Joseph,
>
> I've noticed that your patch introduces regressions on aarch64:
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve (test for errors, line 33)
> we now get
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c:33:44:
> error: empty scalar initializer
> while we expect dg-error {initializer element is not constant}
>
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve (test for errors, line 85)
> we no longer emit dg-error {empty scalar initializer }
>
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> -march=armv8.2-a+sve (test for excess errors)
> FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> -march=armv8.2-a+sve (test for errors, line 85)
> we no longer emit dg-error {empty scalar initializer }
>
> Since the compiler did not ICE before your patch, is that new
> behaviour expected (and the tests need an update), or is that a
> problem with the patch?
Where there has already been an error about the type of an initializer,
it's expected that some other errors about the value of that initializer
will disappear. So I think the cases where a previously expected error
has disappeared are cases where the tests need an update; they already
expect an error for the type.
That leaves the case where you report that "empty scalar initializer" has
appeared. That seems like a bug. Maybe some SVE case means
process_init_element is ignoring something in an initializer for an SVE
type that did not in fact result in the variable-size error from
digest_init? Is the "empty scalar initializer" error coming from the
compound literal on line 33, as opposed to the variable initialized on
that line?
--
Joseph S. Myers
jos...@codesourcery.com
