On Thu, 19 Dec 2024, Robert Dubner wrote: > At compile-time (or on the host), we also do numeric calculations. The > ISO specification allows for compile-time computations specified in the > source code. In addition, at times I put initial values for the COBOL > variables into the run-time structures that are the COBOL variables. In > order to create those CONSTRUCTOR nodes we have to do those calculations > at compile time, hence the use of __int128 and _Float128 in the host code. > > In the run-time/host code, I have been using intTI_type_node for __int128, > and unsigned_intTI_type_node for __uint128. For floating point, I've been > using float32_type_node, float64_type_node, and float128_type_node. > > If there are recommendations as to what would work better across other > architectures, I am all ears.
As has been noted, wide_int can be used for large integer arithmetic within the compiler. For floating-point arithmetic, there are the interfaces in real.h to handle floating point within GCC's internal representation (note that some of the operations might leave a result with extra internal precision; see how fold-const.cc:const_binop calls real_arithmetic followed by real_convert to ensure correct rounding to the desired format, for example). I don't know if you support decimal floating-point in your front end, but the real.h interfaces deal with that as well (via calling out to libdecnumber for arithmetic on DFP values). Again, DFP support on the target (which is supported for a much more limited set of architectures - just aarch64 / powerpc / x86 / x86_64 / s390) does not depend on DFP support on the host, since libdecnumber handles all the DFP arithmetic required within the compiler. -- Joseph S. Myers josmy...@redhat.com
