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 > > 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 ::