On Mon, Jul 8, 2024 at 9:11 AM Eric Botcazou <botca...@adacore.com> wrote:
>
> Hi,
>
> the Ada compiler now defers to the gimplifier for ordering comparisons of
> arrays of bytes (Ada parlance for <, >, <= and >=) because the gimplifier in
> turn defers to memcmp for them, which implements the required semantics.
>
> However the gimplifier has a special processing for aggregate types whose mode
> is not BLKmode and this processing deviates from the memcmp semantics when the
> target is little-endian.
>
> Tested on x86-64/Linux, OK for the mainline?
+ if (code != EQ_EXPR && code != NE_EXPR)
+ {
+ gcc_assert (BYTES_BIG_ENDIAN == WORDS_BIG_ENDIAN);
+ gcc_assert (TREE_CODE (scalar_type) == INTEGER_TYPE);
IIRC at least some array of vector also have vector mode, I'm not sure
type_for_mode is an INTEGER_TYPE in that case nor am I sure
the max 128 bytes size holds here. There's also
array_mode_supported_p which can indicate larger modes are OK.
That said, when BYTES_BIG_ENDIAN the outcome is better
than before.
If we do not have any BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN
target then maybe it's time to retire WORDS_BIG_ENDIAN? Otherwise
is there a fallback solution? I wonder if we can fall back to
gimplify_variable_sized_compare if gimplify_scalar_mode_aggregate_compare
"fails".
Richard.
>
> 2024-07-08 Eric Botcazou <ebotca...@adacore.com>
>
> * gimplify.cc (gimplify_scalar_mode_aggregate_compare): Add support
> for ordering comparisons.
>
>
> 2024-07-08 Eric Botcazou <ebotca...@adacore.com>
>
> * gnat.dg/array42.adb,/gnat.dg/array42_pkg.ads: New test.
>
> --
> Eric Botcazou
