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 2/8] float128: Add _Float128 make bits to libm.


On Fri, 9 Dec 2016, Tulio Magno Quites Machado Filho wrote:

> "Gabriel F. T. Gomes" <gftg@linux.vnet.ibm.com> writes:
> 
> > From: "Paul E. Murphy" <murphyp@linux.vnet.ibm.com>
> >
> > This adds the appropriate common bits for a platform to
> > enable float128 and expose ABI.
> 
> Joseph, I'd like to clarify one thing:
> In a previous thread you mentioned that you'd review one patch of a
> patchset after fixing/committing the previous patch.
> 
> In this patchset, you replied directly to patch #3, without making comments to
> patch #1 and #2.  Does that mean they look good for you?

No.  There can be cases where dependencies among patches in a series, and 
the likelihood of issues with one patch requiring changes to subsequent 
patches, can mean that latter patches are more reviewable once earlier 
patches have passed their final review.  And it may well end up that this 
series is like that.  But for the series posted on 9 Nov I didn't do that.  
Instead, I did an initial general pass over the whole patch series to 
identify the most obvious issues - with all patches rather than just the 
first ones, so all patches can be updated accordingly for the next 
iteration of the series.

I did comment on patch 2 - in my general comments on patch 0, relating to 
having the correct, consistent API/ABI exposed for the new types through 
the whole patch series, which affect patch 2 as well as other patches.

https://sourceware.org/ml/libc-alpha/2016-11/msg00361.html
https://sourceware.org/ml/libc-alpha/2016-11/msg00370.html

(Note also the point there that when it comes to such things involving 
long lists of functions for the new type - in the cases where it's 
unavoidable to have such long lists, as opposed to the cases where 
existing lists for existing types can be macroized - one can have more 
confidence in the completeness of the list if the patch series as a whole 
has passed testing with existing libm tests enabled for the new type, so 
showing through the testsuite that all the expected functions are indeed 
exported for that type.)

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