Re: [PATCH 7/9] Refactor math-finite.h and introduce mathcalls-redir.h

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 13 Jun 2018, Tulio Magno Quites Machado Filho wrote:

> Yes, I can reproduce it in our tests if I replace -mlong-double-128 with
> -mlong-double-64.
> However, this is not user-visible because this warning is ignored in system
> headers.
> 
> Do you still think a bug report is necessary?

I think we want to be clean with -Wsystem-headers; thus, there should be a 
bug report.

> > Instead, I'd suggest merging bits/math-finite.h into bits/mathcalls.h as 
> > much as possible - have macros such as __MATHCALL_FINITE that are called 
> > in bits/mathcalls.h to declare the functions with __*_finite variants, and 
> > with __MATHCALL_FINITE defined the same as __MATHCALL when the finite 
> > function variants aren't in use.  That way you have just a single 
> > redirection for each function.  (You'll need a sysdeps bits/ header for an 
> > architecture, i.e. ia64, to declare it doesn't support the _finite 
> > functions at all.)
> 
> It doesn't work well this way because we have prototypes with extra attributes,
> e.g:
> 
> __MATHDECL_1 (int, totalorder,, (_Mdouble_ __x, _Mdouble_ __y))
>      __attribute__ ((__const__));
> 
> So, if I do not define __MATHDECL_1 in bits/math-finite.h, this code would end
> up as an invalid code:
> 
> __attribute__ ((__const__));

My proposal is that bits/math-finite.h either shouldn't exist or should 
end up just defining the lgamma / gamma / tgamma inlines.  
bits/mathcalls.h would be included once per type, with the macros 
definitions in effect when it's included depending on "defined 
__FINITE_MATH_ONLY__ && __FINITE_MATH_ONLY__ > 0" (so if that's true some 
functions would be redirected to __*finite versions, if that's false it 
would behave much as it does at present).

-- 
Joseph S. Myers
joseph@codesourcery.com