https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182
--- Comment #6 from Mark Millard <markmigm at gmail dot com> --- (In reply to Alice Carlotti from comment #4) > Is it just the four getauxval arguments that differ? That is, are the bit > assignments withing each HWCAP the same? > > We should probably condition the AT_HWCAP* definitions upon the target OS. > Checking a header file first might work in practice, but it feels less > robust in case the header file is missing some of the definitions. The 4 are what I'm familiar with and they are ABI history/choice values rather than descriptions of aarch64 internal bit assignments or the like. I would not necessarily recognize another name that was also an example of ABI history/choice value but there may well not be other such in this context. What range of target ABI's would be covered in the conditioning? I've submitted for the FreeBSD OS context --but overall it is just an example of the more overall issue. Also, future ABI additions here with new names will repeat for each such distinct ABI. I'm not one of the folks that actually maintains the FreeBSD ports' lang/gcc1[67] or later. But I sometimes (rarely) have helped identify details of why/how lang/gcc* builds broke when extra eyes were needed. Thus my input to alternative techniques for handling the varying ABI value definitions is likely to be rather limited, even from a FreeBSD OS ports specific viewpoint. FreeBSD does have additional devel/freebsd-gcc* ports set up for testing building FreeBSD itself with gcc in its CI context. Those have not started using gcc16+ yet (gcc15 is the most recent) --and so have not yet hit the issue but at some point gcc16 will start to be used.
