On Thu, Feb 20, 2025 at 7:23 PM Paul Koning <paulkon...@comcast.net> wrote: > > > > > On Feb 19, 2025, at 8:18 PM, James K. Lowden <jklow...@schemamania.org> > > wrote: > > > > On Wed, 19 Feb 2025 12:55:03 +0100 > > Matthias Klose <d...@debian.org> wrote: > > > >> libgcobol/ChangeLog > >> * Makefile.in: New file. > >> * acinclude.m4: New file. > >> * aclocal.m4: New file. > >> * configure.ac: New file. > >> * configure.tgt: New file. > >> > >> I had updated the configure.tgt, please find it attached here again. > > > > It seems we missed your updated patch and invented our own solution, such > > as it is. Sorry for the misunderstanding. I certainly never meant to > > ignore you. > > > > We know we're currently being too restrictive by limiting host and target > > to x86_64 and aarch64. But your patch as supplied is also insufficient, so > > we attempted to generalize it. > > > > I would like to do this in a way you approve of. Let me lay out the > > requirements as of today. For both host and target: > > > > 1. support for _Float128 > > 2. support for __int128 > > I understand a target requirement if you need to generate code that uses that > datatype. But why a host requirement? For floating point arithmetic at > compile time, there is the GCC internal "real" component, which offers > host-independent floating point arithmetic. One of the reasons that exists > is to allow compile-time arithmetic for targets that have a wider float range > than the host (say, VAX vs. IEEE), but it should also enable high precision > floating point operations inside GCC without caring what width floating point > is native to the host.
On the target there's soft-float (not sure about _Float128 status there though), for __int128 we don't have general libgcc emulation available though, but it would be a nice-to-have thing. I'm sure we can work on both aspects even after merging in the process of enabling a wider set of host/target combinations (with, as you say, priority on host support). Richard. > > paul >
