On Mon, Nov 23, 2020 at 08:10:49PM +0100, Jakub Jelinek wrote: > On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote: > > On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote: > > > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote: > > > > Sure -- I am suggesting to always define __IBM128_MAX__ and the like, > > > > which then can be used to define LDBL_MAX, but also can be used > > > > directly. > > > > > > I have posted patches for this as a new set of patches. Rather than > > > trying to > > > create IBM 128-bit long double min/max/etc. defines, I just marked the > > > test as > > > needing IBM 128-bit long double. > > > > > > I did look into providing defines for these. Unfortunately the function > > > that > > > creates these (builtin_define_float_constants) is static. And the caller > > > of > > > that function (c_cpp_builtins) does not have a target hook or other > > > method to > > > provide for these defines for MD specific floating point types. > > > > So create the defines from somewhere in the backend, instead? This > > isn't rocket science. > > > > You can even leave the existing LDBL defines alone if you just override > > them later. > > The current defines are quite complex code, because defining them is very > expensive and we don't want to pay that price at every compilation start > when most of the compilations never use those macros. > So they are magic deferred macros.
Ah, so defining later will not work, or it will be quite fragile at least. So that won't fly :-/ We can provide IBM128 etc. macros for this just fine of course, but using that for the LDBL is hard then, so perhaps we should not do that second step, certainly not in stage > 1. Thanks, Segher
