[PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

Segher Boessenkool segher@kernel.crashing.org
Mon Nov 23 20:13:58 GMT 2020


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


More information about the Gcc-patches mailing list