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: RISC-V glibc port, v7


Please commit with the changes requested in review of patches 5 and 6 
(note the latter applies to more patches than just patch 6) - and no other 
changes.  Do not send a v8 patch series.  Any further changes should be 
sent separately once the initial port has been committed, and are subject 
to the usual subsystem maintainer rules.

Once you've committed v7 with the fixes noted, here are some further 
questions that may require followup patches:

* An earlier set of test results posted had strfromf failures, which then 
disappeared in a later set of test results without any strfromf-related 
patches that I could see.  My understanding was that those failures 
probably resulted from the RISC-V rule that most floating-point 
instructions with NaN results produce a canonical NaN with positive sign - 
thus, where strfromf converts a float argument to double (in order to use 
printf code that doesn't handle float arguments) it loses the sign of the 
original float NaN.  Did I misunderstand this rule in the RISC-V ISA 
manual?  I was expecting that you'd need e.g. a hook for the strfromf 
conversion from float to double (inline function in a new sysdeps header) 
where the generic version just does a trivial conversion but the RISC-V 
version handles NaNs specially to preserve the sign.

* You're using fmax and fmin instructions to implement the corresponding 
libm functions.  As far as I can see, this would be correct by the 
semantics of those instructions in the v2.2 ISA manual - but the current 
git version of the ISA manual changes the instruction semantics so that 
they would no longer be correct for those functions (and would instead be 
correct for fmaximum_num and fminimum_num, in the proposed changes to TS 
18661-1 to support IEEE 754-2018, but we don't have those functions in 
glibc).  Now, if hardware may implement either v2.2 or v2.3 semantics, 
that makes those instructions fairly useless for glibc, in the absence of 
a way to mark a glibc binary as requiring a particular ISA version; if 
hardware implements only v2.3, the instructions are still inappropriate 
for fmax/fmin/fmaxf/fminf (but could be used in future for fmaximum_num 
and fminimum_num, if and when those are added to C2x and to glibc).

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