Hi Richard,
>> So unless additional concerns come up, I'll commit this patch in a
>> couple of days.
>
> This probably warrants documenting in gcc-16/changes.html
that's what I meant to do. I originally planned to refer from the
caveats section there to the patch posting, but that's probably too
low-level for regular users. I'll probably go ahead and add a
user-centric description to a gcc-16 porting_to.html, describing the
interoperability impact with GCC < 16, clang, and Studio 12.6 CC (which
also implements the GNU C++ ABI). I'd forgotten about this in the patch
description, but have already some of this in response to Jonathan's
comment on the ABI break in the PR.
> Does this mean that ABI-wise non-fixincluded and fixincluded
> versions do not inter-operate? I wonder if it makes sense
> to diagnose int8_t versions that do not adhere to the (updated)
> ABI then (not sure if there's a suitable backend hook).
It meanwhile occured to me that I might be able to do better than what I
currently have. The idea runs as follows:
* Make INT8_TYPE etc. compile-time configurable via some -mint8_t-compat
(or -msolaris-compat) option, off by default.
* Have that predefine __INT8_T_COMPAT__ if on.
* Wrap the fixed definitions in <sys/int_types.h> in #ifndef
__INT8_T_COMPAT__.
I guess this might work, but (at least initially) only for C-family
languages. At least D (or others that can interlink with C++) would
need their own handling, e.g. gdc definition a matching version tag to
control the definitions in libdruntime/core/stdc/stdint.d.
If this is worth the complexity or even GCC 16 material I cannot really
tell, though.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
