Christophe Lyon <christophe.l...@linaro.org> writes:
> On Fri, 8 Nov 2019 at 10:44, Richard Sandiford
> <richard.sandif...@arm.com> wrote:
>>
>> Tested on aarch64-linux-gnu and x86_64-linux-gnu. Applied as obvious.
>>
>
> Hi Richard,
>
> The new deref_2.c test fails with -mabi=ilp32:
> FAIL: gcc.target/aarch64/sve/acle/general/deref_2.c
> -march=armv8.2-a+sve (test for excess errors)
> Excess errors:
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general/deref_2.c:17:39:
> error: no matching function for call to 'svld1(svbool_t&, int32_t*&)'
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general/deref_2.c:17:38:
> error: invalid conversion from 'int32_t*' {aka 'long int*'} to 'const
> int*' [-fpermissive]
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general/deref_2.c:17:38:
> error: invalid conversion from 'int32_t*' {aka 'long int*'} to 'const
> unsigned int*' [-fpermissive]
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general/deref_2.c:18:43:
> error: no matching function for call to 'svld1(svbool_t&, int32_t*&)'
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general/deref_2.c:18:42:
> error: invalid conversion from 'int32_t*' {aka 'long int*'} to 'const
> int*' [-fpermissive]
> /gcc/testsuite/gcc.target/aarch64/sve/acle/general/deref_2.c:18:42:
> error: invalid conversion from 'int32_t*' {aka 'long int*'} to 'const
> unsigned int*' [-fpermissive]
Ugh. This is because for -mabi=ilp32, newlib's stdint.h defines int32_t
to be long int rather than int. It's easy to update the ACLE code to use
the right stdint.h type, but the problem is that for ILP32, the C++ code:
int x;
f(&x);
does not resolve to any of the overloads:
void f(int8_t *);
void f(int16_t *);
void f(int32_t *);
void f(int64_t *);
Of course, if int32_t was defined to "int" then the above would fail for
"long int", but it seems especially surprising that this doesn't work
for int. These days using long int directly is usually a mistake anyway.
I guess this int != int32_t thing is just something that users will have
to live with if they care about compatibility with ILP32 newlib.
I'll try to make the tests ILP32 clean once we're in stage 3, including
fixing the problems that Andreas pointed out.
Thanks,
Richard
