[PATCHv2,03/11] Support for type-generic libm function implementations libm

  On 08/02/2016 04:53 PM, Joseph Myers wrote:
> On Fri, 1 Jul 2016, Paul E. Murphy wrote:
> 
>> +#if M_LIBM_NEED_COMPAT (carg)
>> +  declare_mgen_libm_compat (__carg, carg)
>>  #endif
> 
> This sort of thing is not conventionally indented.
> 
>> diff --git a/sysdeps/generic/math-type-macros.h b/sysdeps/generic/math-type-macros.h
>> new file mode 100644
>> index 0000000..3befde1
>> --- /dev/null
>> +++ b/sysdeps/generic/math-type-macros.h
> 
> How would you envisage additional types being handled?  Overriding the 
> header with a variant that duplicates its contents but with extra types 
> being handled doesn't seem like a good idea.  Maybe there should actually 
> be a header per type, which then includes the generic type-independent 
> header, or something like that?  I think more rationale is needed for the 
> design relating to this header, anyway.

Note, in this example __cfloat128 is supplied indirectly
through complex.h via a typedef in a machine specific
header.  This is another discussion once the _Float128
patches are ready for a meaningful discussion. (As
a further digression, I am able to build and test as
_Float128 and _Complex _Float128 using your _FloatN
patches for GCC without issue.)


My initial thought was a simple header which could be
compiled on any machine provided sufficient GCC support
for the requested type.  So, you would keep tacking on
patches similar to the above.  However, __float128 may
be too simple an example to generalize from.

My other assumption is long double is the only type
which will have such convoluted aliasing and versioning
requirements.

Likewise, the only reason this lives in sysdeps is to
enable ldbl-opt to inject the necessary macros to
generate correctly versioned symbols on such machines.

Maybe we get the best of both worlds if this file moves
into math/, and create headers of the form
math-type-macros-{float,double,ldouble}.h which would
exclusively define the M_* macros, and optionally
declare_mgen_alias, declare_mgen_libm_compat.
math-type-macros.h would supply default versions of
the latter two macros if none are provided by the
type.

> 
>> +#if M_TYPE == M_FLOAT
>> +# define M_PFX FLT
>> +# define M_LIT(c) c ## f
>> +/* Use the double version instead.  */
>> +# define M_MLIT(c) c
>> +# define M_SUF(c) c ## f
>> +# define M_FUNC(c) c ## f
>> +# define FLOAT float
>> +# define CFLOAT __complex__ float
>> +# define M_HUGE_VAL HUGE_VALF
> 
> Somewhere there needs to be a comment explaining the semantics of every 
> one of these macros.  Especially, I can't tell what the difference of 
> intent between M_SUF and M_FUNC is (which places should use one, which 
> should use the other).  In one place you call M_SUF (__atan2), in another 
> you define M_ATAN2 to M_FUNC (__ieee754_atan2) - why the difference 
> between M_SUF and M_FUNC there?

In hindsight, they should be merged into one to apply the correct literal
suffix, and function suffix.