This is the mail archive of the 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: [RFC] Support for type-generic libm function implementations libm

On Tue, 14 Jun 2016, Paul E. Murphy wrote:

> > What about the ldbl-opt code that wraps complex functions?  Does that need 
> > updating?
> My current understanding is that ldbl-opt is fairly self contained,
> and builds its interesting bits more or less independently of the
> math makefile.  Irrespective, the patch still needs more work
> in fundamental areas.

Well, it includes files carg.c and cargl.c, for example, both of which 
include the corresponding math/ files and do other things before or after 
that inclusion.

> > On whatever platforms you have tested, did you make sure the installed 
> > stripped shared libraries were unchanged (or at least that the relevant 
> > objects were after stripping debug info, if the changes have the effect of 
> > changing the order in which objects are linked into
> I've been working this out and running the tests on x86_64.  The intent
> is these changes *should* be generic.  I've only verified the the correct
> flavor of atan is called.  More complex wrappers deserve more inspection.
> Perhaps adding a few extra test cases is a better way to catch unwanted
> silent conversions.

My point is that as a general principle, certain sorts of cleanup patches 
are expected not to change the generated code, and if your patch is one of 
them, you should do the comparison, and have an explanation for any 
differences found so we can see if they are harmless.  (For example, there 
might be differences because the existing files are unintentionally out of 
sync, or float files are accidentally using double operations at present, 
or if there's inconsistency in how M_* constants are used in float files 
that it doesn't make sense to replicate when making them type-generic.  I 
don't know if there are such issues at present, but those would be 
plausible reasons for making a function type-generic changing the code 
generated for it.)

Joseph S. Myers

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