This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Joseph Myers <joseph@codesourcery.com> writes:

> 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.

Ack.
Reported as https://sourceware.org/bugzilla/show_bug.cgi?id=23292

>> > 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).

Interesting...
I'm working on this.

-- 
Tulio Magno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]