On Wed, 18 Dec 2024, James K. Lowden 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.
Could you give more details of what is required or optional in ISO COBOL? Looking at ISO/IEC 1989:2023 (and searching for "128"), I see, for example, in A.3 item 17, "The usages FLOAT-BINARY-32, FLOAT-BINARY-64 and FLOAT-BINARY-128 are dependent on the capabilities of the processor.". The corresponding C and C++ features are optional - some targets support them, some don't, the language doesn't require them to be supported. (I'm aware of a C++ proposal to require support for 128-bit integers, but I'm not sure of its current status. If it went in, we'd need all architecture maintainers for 8-bit/16-bit/32-bit architectures to define the ABI for 128-bit integers on their target, in collaboration with the maintainers of any ABI document or other implementations.) And having support for such features on the target is in any case independent of having it on the host. You can build GCC to run on 32-bit Arm (no __int128 or _Float128) as the host, and generate code for AArch64 (has __int128 and _Float128) as the target. It would be odd to require a 64-bit host for a particular language (if you need arithmetic within the compiler itself wider than natively supported on the host, we have both GCC's wide_int and GMP available; likewise, GCC's real* and MPFR for wider floating-point support). If you require __int128 on the target, the toplevel / libgcobol configure code will need to handle building libgcobol only for the subset of multilibs for the target that have __int128, since lots of targets have both 32-bit multilibs (no __int128) and 64-bit multilibs (with __int128). > Is there an architecture-feature database within gcc that lists which > ones support _Float128? _Float128 is generally TFmode. Look at the TARGET_SCALAR_MODE_SUPPORTED_P hooks to see which support TFmode. The default hook supports it if it's used for long double (TARGET_C_MODE_FOR_FLOATING_TYPE hook). Although most 64-bit targets do support _Float128, that isn't universally the case. For example, powerpc64 big-endian doesn't. > > 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. OK, so this header should go in the libgcobol/ directory, not in gcc/cobol/ (which is where this patch version has it). The same for any other headers declaring functions in libgcobol. If there's any header that needs to be included in both the compiler and the library for some reason (e.g. if you need a header defining constants that are used by the library, and the compiler also needs to know when generating code), we'll need to look at that in more detail. But function declarations certainly should only be included in one of those two places: the compiler's headers should declare functions that are part of the compiler, the library's headers should declare functions that are part of the library. And structure declarations can't readily be shared either simply because the host and target can have different types. -- Joseph S. Myers josmy...@redhat.com
