From patchwork Tue Aug 2 23:12:59 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Paul E. Murphy" X-Patchwork-Id: 14261 Received: (qmail 9238 invoked by alias); 2 Aug 2016 23:13:06 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 9226 invoked by uid 89); 2 Aug 2016 23:13:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=worlds, ldbl-opt, ldblopt, __gnuc_prereq X-HELO: mx0a-001b2d01.pphosted.com X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: murphyp@linux.vnet.ibm.com Subject: Re: [PATCHv2 03/11] Support for type-generic libm function implementations libm To: Joseph Myers References: Cc: libc-alpha@sourceware.org From: "Paul E. Murphy" Date: Tue, 2 Aug 2016 18:12:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16080223-0028-0000-0000-0000054B35ED X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005546; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000177; SDB=6.00739137; UDB=6.00347468; IPR=6.00511728; BA=6.00004637; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012130; XFM=3.00000011; UTC=2016-08-02 23:13:01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16080223-0029-0000-0000-00002E0E4A04 Message-Id: <3a418cdb-ecc4-db97-ebba-bbe516188325@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-02_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1606300000 definitions=main-1608020231 On 08/02/2016 04:53 PM, Joseph Myers wrote: > On Fri, 1 Jul 2016, Paul E. Murphy wrote: > >> +#if M_LIBM_NEED_COMPAT (carg) >> + declare_mgen_libm_compat (__carg, carg) >> #endif > > This sort of thing is not conventionally indented. > >> diff --git a/sysdeps/generic/math-type-macros.h b/sysdeps/generic/math-type-macros.h >> new file mode 100644 >> index 0000000..3befde1 >> --- /dev/null >> +++ b/sysdeps/generic/math-type-macros.h > > How would you envisage additional types being handled? Overriding the > header with a variant that duplicates its contents but with extra types > being handled doesn't seem like a good idea. Maybe there should actually > be a header per type, which then includes the generic type-independent > header, or something like that? I think more rationale is needed for the > design relating to this header, anyway. Note, in this example __cfloat128 is supplied indirectly through complex.h via a typedef in a machine specific header. This is another discussion once the _Float128 patches are ready for a meaningful discussion. (As a further digression, I am able to build and test as _Float128 and _Complex _Float128 using your _FloatN patches for GCC without issue.) My initial thought was a simple header which could be compiled on any machine provided sufficient GCC support for the requested type. So, you would keep tacking on patches similar to the above. However, __float128 may be too simple an example to generalize from. My other assumption is long double is the only type which will have such convoluted aliasing and versioning requirements. Likewise, the only reason this lives in sysdeps is to enable ldbl-opt to inject the necessary macros to generate correctly versioned symbols on such machines. Maybe we get the best of both worlds if this file moves into math/, and create headers of the form math-type-macros-{float,double,ldouble}.h which would exclusively define the M_* macros, and optionally declare_mgen_alias, declare_mgen_libm_compat. math-type-macros.h would supply default versions of the latter two macros if none are provided by the type. > >> +#if M_TYPE == M_FLOAT >> +# define M_PFX FLT >> +# define M_LIT(c) c ## f >> +/* Use the double version instead. */ >> +# define M_MLIT(c) c >> +# define M_SUF(c) c ## f >> +# define M_FUNC(c) c ## f >> +# define FLOAT float >> +# define CFLOAT __complex__ float >> +# define M_HUGE_VAL HUGE_VALF > > Somewhere there needs to be a comment explaining the semantics of every > one of these macros. Especially, I can't tell what the difference of > intent between M_SUF and M_FUNC is (which places should use one, which > should use the other). In one place you call M_SUF (__atan2), in another > you define M_ATAN2 to M_FUNC (__ieee754_atan2) - why the difference > between M_SUF and M_FUNC there? In hindsight, they should be merged into one to apply the correct literal suffix, and function suffix. diff --git a/sysdeps/generic/math-type-macros.h b/sysdeps/generic/math-type-macros.h index 3befde1..b92a379 100644 --- a/sysdeps/generic/math-type-macros.h +++ b/sysdeps/generic/math-type-macros.h @@ -22,6 +22,7 @@ #define M_FLOAT 1 #define M_DOUBLE 2 #define M_LDOUBLE 3 +#define M_FLOAT128 4 #if M_TYPE == M_FLOAT # define M_PFX FLT @@ -51,6 +52,24 @@ # define FLOAT long double # define CFLOAT __complex__ long double # define M_HUGE_VAL HUGE_VALL +#elif M_TYPE == M_FLOAT128 +# define M_PFX FLT128 +# define M_MLIT(c) c ## f128 +# define M_SUF(c) c ## f128 +# define M_FUNC(c) c ## f128 +# define M_HUGE_VAL HUGE_VAL_F128 + +# include +# if !__GNUC_PREREQ (7, 0) +# define M_LIT(c) c ## q +# define FLOAT __float128 +# define CFLOAT __cfloat128 +# else +# define M_LIT(c) c ## f128 +# define FLOAT _Float128 +# define CFLOAT __complex__ _Float128 +# endif + #else # error Error: M_TYPE is not a known floating point type #endif @@ -98,8 +117,8 @@ /* Rules for aliasing the currently generated math files. */ -/* Aliasing rules for float are straight forward. */ -#if M_TYPE == M_FLOAT +/* Aliasing rules for float{,128} are straight forward. */ +#if M_TYPE == M_FLOAT || M_TYPE == M_FLOAT128 # define declare_mgen_alias(from, to) weak_alias (M_SUF (from), M_SUF (to)) #endif --