On Wed, 21 Apr 2021, Richard Sandiford wrote:
> which AFAICT would test preprocessing for the host rather than the target.
Ah, good point. (GCC_GLIBC_VERSION_GTE_IFELSE can be used to deal with
glibc version conditionals in a way that works, given appropriate
configure options, even when the t
Joseph Myers writes:
> On Wed, 21 Apr 2021, Andreas Schwab wrote:
>
>> On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
>>
>> > However, AArch64 postdates glibc and binutils support for
>> > .init/fini_array by some distance, so it's safe to hard-code the
>> > result to "yes" for cross co
On Wed, 21 Apr 2021, Andreas Schwab wrote:
> On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
>
> > However, AArch64 postdates glibc and binutils support for
> > .init/fini_array by some distance, so it's safe to hard-code the
> > result to "yes" for cross compilers.
>
> Should there be
On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
> However, AArch64 postdates glibc and binutils support for
> .init/fini_array by some distance, so it's safe to hard-code the
> result to "yes" for cross compilers.
Should there be an automatism for any other new architecture added?
Andre
I was wondering why the (now fixed) c-c++-common/attr-retain-[78].c
failures were showing up in the native results for aarch64-linux-gnu
but not in the posted cross results. It turns out that .init/
.fini_array support is disabled by default for cross builds,
which in turn stops those tests from r
