On Thu, Dec 19, 2024 at 11:31 AM James K. Lowden <jklow...@schemamania.org> wrote: > > On Mon, 16 Dec 2024 23:36:37 +0000 (UTC) > Joseph Myers <josmy...@redhat.com> wrote: > > > > +extern "C" _Float128 __gg__float128_from_qualified_field > > > > I'm not entirely sure whether this is host or target code (you always > > need to be clear about which is which in GCC), but in any case, both > > hosts and targets without __int128 or _Float128 are supported in GCC. > > In preparing my comprehensive TODO list, these points need > clarification (for us both, I think). > > We are ignoring 32-bit architectures and rely on 128-bit numeric support > to meet ISO COBOL requirements. I know there's a way to enumerate > supported targets but don't know how. As of now, any missing support > is reported by the compiler when building gcobol.
Maybe it is better to just use _BitInt instead of __int128. Yes the number of targets that support _BitInt for C is less than __int128 but in the future _BitInt will be more supported than __int128 especially on 32bit targets. E.g. _BitInt(128) is supported on 32bit x86 while __int128 is not. Thanks, Adnrew Pinski > > Is there an architecture-feature database within gcc that lists which > ones support _Float128? > > > In general, target code - including headers - should not go under > > gcc/ at all. And host code shouldn't be using __* identifiers as > > those are reserved. > > The above function is implemented in the runtime library. It is called > from generated code, and from within the library. We have many such > functions. They have leading underscores because they're not > intended to be called by any user; that is, they're part of the > implementation. It's my understanding we *are* the implementation to > which such names are reserved. > > > whether this is host or target code > > I think "target" must be the answer? The function is not used to build > gcobol. The built compiler emits code that calls that function, which > it requires be supplied by libgcobol. > > Does this answer your concerns? I have it filed under "not a > problem" unless you tell me otherwise. > > --jkl
