On Thu, 25 Jan 2018, vladimir.mezent...@oracle.com wrote: > From: Vladimir Mezentsev <vladimir.mezent...@oracle.com> > > Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and > sparc64-unknown-linux-gnu. > No regression. New tests now passed. > There is a performance degradation for complex double type:
This is, of course, something to consider for GCC 9; it's not suitable for the current development stage. Could you provide a more extended writeup of the issue (starting with the argument for it being a bug at all), the approach you took and the rationale for the approach, when you resubmit the patch for GCC 9 stage 1? > * libgcc/config/sparc/sfp-machine.h: New Are you introducing a requirement for all architectures to provide sfp-machine.h? If so, did you determine that SPARC was the only one lacking it? If not the only one lacking it, you need to make sure that you do not break any existing architecture in GCC. What about architectures using non-IEEE formats? soft-fp is not suitable for those, but you mustn't break them. Remember that e.g. TFmode can be IBM long double, and other ?Fmode similarly need not be IEEE; the name only indicates how many bytes are in the format, nothing else about it. What about powerpc __divkc3? What was the rationale for using soft-fp rather than adding appropriate built-in functions as suggested in a comment? These are the sorts of issues you need to cover in your patch write-up, to demonstrate that you have allowed for the range of targets supported in GCC, have taken care to avoid breaking them and have made deliberate choices that are appropriate in each case (but might not be the same for every target). > +static inline int get_cde(int c, int d) Lots of the new functions need comments on them to explain their semantics. Also, the formatting needs fixing to follow the GNU Coding Standards ("static inline int" on its own line, space before '('). > + if (cde != 0) { Similarly, bad formatting, "{" goes on the next line. -- Joseph S. Myers jos...@codesourcery.com