mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in initializations of static variables
Date: Wed, 26 Nov 2014 08:45:53 +0100	[thread overview]
Message-ID: <1416987953.28402.26.camel@eris.loria.fr> (raw)
In-Reply-To: <20141125231925.GB2541@port70.net>

[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]

Hello,

Am Mittwoch, den 26.11.2014, 00:19 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@inria.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 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2014-11-26  7:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25 14:49 Jens Gustedt
2014-11-25 15:25 ` Szabolcs Nagy
2014-11-25 19:21   ` Szabolcs Nagy
2014-11-25 21:23     ` Jens Gustedt
2014-11-25 23:19       ` Szabolcs Nagy
2014-11-26  7:45         ` Jens Gustedt [this message]
2014-11-25 20:08   ` Jens Gustedt
2014-11-26 13:07 Jens Gustedt
2014-12-02 17:49 ` Rich Felker
2014-12-02 19:10   ` Jens Gustedt
2014-12-02 19:42     ` Rich Felker
2014-12-02 22:00       ` Jens Gustedt
2014-12-02 22:47         ` Rich Felker
2014-12-03  9:18           ` Jens Gustedt
2014-12-03 14:38             ` Rich Felker
2014-12-03 15:12               ` Jens Gustedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1416987953.28402.26.camel@eris.loria.fr \
    --to=jens.gustedt@inria.fr \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).