This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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] Fix libquadmath regression (bootstrap failure) on FreeBSD


On Wed, 19 Jul 2017, Jakub Jelinek wrote:

> >  And can you please push this
> > to glibc as well (which I do not have access to)?
> 
> glibc uses u_int32_t in all the places of *powl.c where libquadmath
> uses uint32_t, and various other files, so I guess it is intentional.

I'd consider it a relic of old fdlibm code, i.e. code (all over libm) that 
hasn't yet been cleaned up to use uintN_t instead of u_intN_t internally 
(but which it would be desirable to clean up like that).

I think it would be desirable to be able to do libquadmath imports via a 
script that automatically applies substitutions to turn glibc code into 
code that can be used in libquadmath.  Right now required substitutions 
would include s/u_int/uint/, and converting L() to apply appropriate 
suffixes, and converting function calls to the *q form, while some other 
substitutions such as s/_Float128/__float128/ would not actually be needed 
for the code to build but would make the results of substitution closer to 
the present libquadmath contents, and so easier to compare.  If then the 
number of substitutions needed can be reduced over time (e.g. defining L() 
as a macro in quadmath-imp.h rather than substituting it in the sources), 
that would be good.  Moving glibc code (across libm, not just ldbl-128) to 
use uintN_t would be in that category.

-- 
Joseph S. Myers
joseph@codesourcery.com


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