[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 26 Nov 2014 08:45:53 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in
initializations of static variables
Hello,
Am Mittwoch, den 26.11.2014, 00:19 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@...ia.fr> [2014-11-25 22:23:03 +0100]:
> > right for all such compilers is quite a pain. I'll see what clang
> > offers, here.
> >
>
> clang has
>
> static double _Complex z = (double _Complex){x, y};
yes, I noticed that in the mean time, too
> which is problematic because it is a language extension that
> gcc and other c11 compilers wont support most likely
we'd have to do case analysis according to the compiler, anyhow, since
there will be some time that other compilers implement
__builtin_complex, or which would even be better, _Imaginary.
> (a compound literal (T){x,y} is a constraint violation for
> scalar T, so a sensible c11 compiler will emit diagnostics)
>
> > > and fall back
> > > to the compound literal version otherwise (it wont work as static
> > > initializer then, but right now the biggest user of CMPLX is most
> > > likely musl src/complex/* which dont need it to be constant expr
> > > but does rely on proper semantics for infinites and signed zeros)
> >
> > If that is so, I'd be in favor of having and using an internal macro
> > that uses the compound literal. The compilation of the library
> > shouldn't depend too much on compiler versions.
> >
>
> it used to be an internal macro, but i thought it makes sense
> to use the new CMPLX instead when it was added to complex.h
>
> but if CMPLX semantics cannot be guaranteed with c99 features
I suppose that these were added to the standard, because such a
feature needs compiler extensions
> then probably we should go back to the internal macro (and not
> define CMPLX at all in complex.h if the semantics is wrong)
I would much be in favor of that, we shouldn't put the quality of the
library implementation in danger just because of some border cases for
this macro. So I prepare a patch in that sense?
Below you see what I have currently, but I don't like it at all.
Jens
#define __CMPLX_NC(x, y, t) (+(union { _Complex t __z; t __xy[2]; }){.__xy = {(x),(y)}}.__z)
#if defined(_Imaginary_I)
# define __CMPLX_I(x, y, t) ((t)(x) + _Imaginary_I*(t)(y))
#else
# define __CMPLX_I(x, y, t) ((t)(x) + _Complex_I*(t)(y))
#endif
#if defined(__clang__)
/* Clang allows initializer lists for complex numbers and compound
literals for the initialization of static variables. */
# define __CMPLX(x, y, t) (+(_Complex t){ (x), (y) })
#elif defined(__GNUC__)
# if (__STDC_VERSION__ >= 201112L)
# define __CMPLX(x, y, t) __builtin_complex((t)(x), (t)(y))
# elif (__GNUC__ >= 3)
# define __CMPLX(x, y, t) \
(__builtin_constant_p(x+y) ? __CMPLX_I(x, y, t) : __CMPLX_NC(x, y, t))
# endif
#endif
#ifndef __CMPLX
# define __CMPLX(x, y, t) __CMPLX_I(x, y, t)
#endif
#define CMPLX(x, y) __CMPLX(x, y, double)
#define CMPLXF(x, y) __CMPLX(x, y, float)
#define CMPLXL(x, y) __CMPLX(x, y, long double)
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
