This testcase triggered an ICE in rtx_vector_builder::step because
we were trying to use a stepped representation for floating-point
constants.  The underlying problem was that the arguments to
rtx_vector_builder were the wrong way around, meaning that some
variations were likely to be incorrectly encoded for integers
(but probably as a silent failure).

Also, aarch64_sve_expand_vector_init_handle_trailing_constants
tries to extend the trailing constant elements to a full vector
by following the "natural" pattern of the original vector, which
should generally lead to nicer constants.  However, for the testcase,
we'd then end up picking a variable for some elements.  Fixed by
stubbing out all variable elements with zeros.

That fix involved testing valid_for_const_vector_p.  For consistency,
the patch uses the same test when finding trailing constants, instead
of the previous aarch64_legitimate_constant_p.

2020-04-20  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
	PR target/94668
	* config/aarch64/aarch64.c (aarch64_sve_expand_vector_init): Fix
	order of arguments to rtx_vector_builder.
	(aarch64_sve_expand_vector_init_handle_trailing_constants): Likewise.
	When extending the trailing constants to a full vector, replace any
	variables with zeros.

gcc/testsuite/
	PR target/94668
	* gcc.target/aarch64/sve/pr94668.c: New test.