Alexandre Oliva writes:
> On Jan 23, 2024, Richard Sandiford wrote:
>
>> Performing the check in expand is itself wrong
>
> *nod*
>
>> So I think we should enforce the immediate range within the frontend
>> instead, via TARGET_CHECK_BUILTIN_CALL.
>
> Sounds good. Can that accommodate the existin
On Jan 23, 2024, Richard Sandiford wrote:
> Performing the check in expand is itself wrong
*nod*
> So I think we should enforce the immediate range within the frontend
> instead, via TARGET_CHECK_BUILTIN_CALL.
Sounds good. Can that accommodate the existing uses in always_inline
wrappers?
> U
Alexandre Oliva writes:
> Calling arm_neon.h functions that take lanes as arguments may fail to
> report malformed values if the intrinsic happens to be optimized away,
> e.g. because it is pure or const and the result is unused.
>
> Adding __AARCH64_LANE_CHECK calls to the always_inline functions
Calling arm_neon.h functions that take lanes as arguments may fail to
report malformed values if the intrinsic happens to be optimized away,
e.g. because it is pure or const and the result is unused.
Adding __AARCH64_LANE_CHECK calls to the always_inline functions would
duplicate errors in case
