[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141125192150.GA2541@port70.net>
Date: Tue, 25 Nov 2014 20:21:51 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in
initializations of static variables
* Szabolcs Nagy <nsz@...t70.net> [2014-11-25 16:25:00 +0100]:
> * Jens Gustedt <Jens.Gustedt@...ia.fr> [2014-11-25 15:49:39 +0100]:
> > -#define __CMPLX(x, y, t) \
> > - ((union { _Complex t __z; t __xy[2]; }){.__xy = {(x),(y)}}.__z)
>
> hm the compound literal is not a constant expression
>
> > +#define __CMPLX(x, y, t) ((t)(x) + _Complex_I*(t)(y))
> >
>
> this is only correct if the compiler supports annex g kind of
> imaginary type, otherwise it is incorrect for infinites
it seems gcc added __builtin_complex but there is no easy way to check
for the availability of such builtin (other than checking >= gcc 4.7)
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01600.html
i guess we could use the builtin with gcc version check 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)
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.
