[PATCH] libctf: remove CTF_F_ARRNELEMS flag

[Nick Alcock]

On 28 Feb 2026, Alan Modra verbalised:
> On Fri, Feb 27, 2026 at 03:07:15PM +0000, Nick Alcock via Binutils wrote:
>> On 27 Feb 2026, Nick Alcock via Binutils verbalised:
>> All tests passed: pushed to master.
>
> aarch64-linux-gnu  +FAIL: libctf-lookup/multidim-array
> alpha-linux-gnu  +FAIL: libctf-lookup/multidim-array
> arm-linux-gnueabi  +FAIL: libctf-lookup/multidim-array
> hppa-linux-gnu  +FAIL: libctf-lookup/multidim-array
> ia64-linux-gnu  +FAIL: libctf-lookup/multidim-array
> m68k-linux-gnu  +FAIL: libctf-lookup/multidim-array
> microblaze-linux-gnu  +FAIL: libctf-lookup/multidim-array
> mips64-linux-gnuabi64  +FAIL: libctf-lookup/multidim-array
> mips-linux-gnu  +FAIL: libctf-lookup/multidim-array
> powerpc-linux-gnu  +FAIL: libctf-lookup/multidim-array
> riscv64-linux-gnu  +FAIL: libctf-lookup/multidim-array
> s390-linux-gnu  +FAIL: libctf-lookup/multidim-array
> s390x-linux-gnu  +FAIL: libctf-lookup/multidim-array
> sh4-linux-gnu  +FAIL: libctf-lookup/multidim-array
> sparc64-linux-gnu  +FAIL: libctf-lookup/multidim-array
>
> So does this mean I need to rebuild all my cross compilers?  Well, not
> all, these are (GCC) 13.0.0 20220910 (experimental).  I do have some
> later cross compilers that pass the test.  powerpc64le-linux-gnu and
> powerpc64-linux-gnu are both (GCC) 15.0.1 20250311 (experimental).

This is, alas, expected -- in the absence of this flag, it's impossible
to tell whether the reverse-dumping bug is fixed in the compiler, so
GCCs older than 14.1 will fail the test. The failure is harmless, in
that binutils before this change (supporting the flag) got the results
wrong for GCC > 14 wrong instead, since GCC never actually *emitted* the
flag to say that the bug was fixed!

This was all a complete mess, but thankfully the older compilers that
had this bug aren't working any worse than they were before (we're just
spotting the underlying problem now), and they're slowly going to age
into history.

In hindsight the bug-compat flag was a bad idea, even though I normally
try to make libctf produce correct output for both before-bugfix and
afte-bugfix compiler changes: we can reverse the order of array elements
in objdump --ctf output, but we can't reverse the order observed in the
actual CTF type graph when libctf users walk it, and that's what most
consumers will care about. So it was only ever introducing confusion to
make the dump output inconsistent with the type graph like that. I don't
know what I was thinking...

(The test is testing ctf_type_aname(), which is the machinery used by
the CTF type dumper under the covers, so alas we cannot really move it
into GCC, even though it's affected by a GCC bugfix: it's testing part
of libctf.)

-- 
NULL && (void)