[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 02 Dec 2014 23:00:12 +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
Am Dienstag, den 02.12.2014, 14:42 -0500 schrieb Rich Felker:
> On Tue, Dec 02, 2014 at 08:10:32PM +0100, Jens Gustedt wrote:
> > > Does clang not support the GCC builtin?
> >
> > no, and I don't have the impression they will. They invented their own
> > internals for this, as you can see here.
>
> Yes, but their form is a bug that needs to be removed, so they'll have
> to add something in its place, and __builtin_complex is the natural
> choice. For what it's worth, glibc only supports __builtin_complex and
> just does not define these macros at all if it's not supported.
you mean it is a bug because the two-value-initializer is a constraint
violation? It only is a bug that has to be diagnosed if user code is
using it. Internals as long they are not visible to the user isn't
covered by this, I think. And this is exactly the reason why the
macros have been introduced in C11, to hide such cruft from the user's
eye :)
> > > My preference would be if we could just define CMPLX either in terms
> > > of __builtin_complex,
> >
> > not possible, I think
>
> Well, it's what glibc does. That's not to say it's a good choice, but
> it suggests there could be pressure to get other compilers to support
> it.
and that's then one of the points where they aren't C11 conforming
when compiled with other compilers
> > > and only exposing it in C11 mode.
> >
> > this is already the case. (Or is it C1x that bothers you?)
>
> I did find the 201000L comparison a bit odd (is that the "C1x" thing?)
yes
> but my comment here wasn't in reference to your proposal being
> different from the ideal I'd like to have, just a statement of the
> latter.
ok
> > > _Imaginary_I
> > > is not supported yet at all and would require further changes to this
> > > header to add anyway (this header is responsible for defining it), so
> > > conditioning on its definition is not meaningful.
> >
> > I am not sure of that. It could also come directly from the compiler
> > just as it defines some __SOMETHING__ macros before any include
>
> I don't think so. Consider:
>
> #undef _Imaginary_I
> #include <complex.h>
>
> Perhaps this is non-conforming for technical reasons,
it is non-conforming
> but the standard
> is fairly direct in saying that complex.h defines the _Imaginary_I
> macro rather than just having it predefined.
but it also says
» Implementations that define the macro __STDC_NO_COMPLEX__ need not provide
» this header nor support any of its facilities.
so any of the facilities *may* be provided anyhow. (and since
_Imaginary_I is reserved it is allowed to do that in any case.)
But if you want to avoid that branch, I understand. _Imaginary_I would
be *the* way to solve all of this easily, sigh.
> > > And pre-4.7 versions
> > > of GCC don't support C11 anyway (and even 4.7 and 4.8 are highly
> > > incomplete) so I don't think much is lost if a C11 feature fails to
> > > work on older compilers.
> >
> > as said, there is no intention to support it for older compilers. So I
> > read it that you want me to pull the definition of the __CMPLX
> > versions into the C1x conditional?
>
> I'm not sure I follow what you're saying here. The text you quoted was
> in regards to my hope of just having a single definition, not a
> specific request for any particular changes to your proposed patch.
>
> > > The big question is how this fares for clang
> > > compatibility though. I expect pcc and cparser/firm will provide a
> > > compatible __builtin_complex (if they don't already) as they improve
> > > C11 support.
> > >
> > > > diff --git a/src/internal/libm.h b/src/internal/libm.h
> > > > index ebcd784..f916e2e 100644
> > > > --- a/src/internal/libm.h
> > > > +++ b/src/internal/libm.h
> > > > @@ -155,4 +155,12 @@ long double __tanl(long double, long double, int);
> > > > long double __polevll(long double, const long double *, int);
> > > > long double __p1evll(long double, const long double *, int);
> > > >
> > > > +/* complex */
> > > > +
> > > > +#ifndef CMPLX
> > > > +#define CMPLX(x, y) __CMPLX_NC(x, y, double)
> > > > +#define CMPLXF(x, y) __CMPLX_NC(x, y, float)
> > > > +#define CMPLXL(x, y) __CMPLX_NC(x, y, long double)
> > > > +#endif
> > > > +
> > > > #endif
> > >
> > > This should probably use the unions unconditionally, after including
> > > complex.h and #undef'ing CMPLX[FL], since musl does not require a C11
> > > compiler to build it. Depending on whether a fallback is provided for
> > > old compilers or not, I think your approach could lead to musl being
> > > miscompiled. It probably doesn't happen since CMPLX is no longer
> > > exposed except in C11 mode, and musl is compiled with -std=c99, but
> > > this looks fragile and could cause breakage to go unnoticed if we
> > > switch to preferring -std=c11 some time later. (There's been talk of
> > > preferring -std=c11 if it works.)
> >
> > Hm, clearly not my preference. I think we should use the right tool
> > (which is __builtin_complex for gcc or the bogus initializer for
> > clang) as soon as we have it.
> >
> > This is why I wanted to have the detection of the features as early as
> > possible where it belongs to my opinion, complex.h.
> >
> > They have more chances to optimize things correctly without
> > temporaries even when compiled without optimization.
>
> As stated in another thread, my preference is highly towards not
> having multiple versions of the same code, especially when one or more
> are unlikely to get good testing. The "more chance to optimize"
> argument does not apply unless there really are compilers which
> compile the unions poorly (not counting intentional non-optimizing
> modes) and I'm not aware of any.
ok, I'll prepare a new version according to that
Jens
--
:: 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.
