From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6653 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in initializations of static variables Date: Tue, 2 Dec 2014 17:47:54 -0500 Message-ID: <20141202224754.GK29621@brightrain.aerifal.cx> References: <1417007215.28402.107.camel@eris.loria.fr> <20141202174940.GB29621@brightrain.aerifal.cx> <1417547432.4936.1103.camel@eris.loria.fr> <20141202194210.GF29621@brightrain.aerifal.cx> <1417557612.4936.1138.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1417560501 17332 80.91.229.3 (2 Dec 2014 22:48:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Dec 2014 22:48:21 +0000 (UTC) Cc: musl@lists.openwall.com To: Jens Gustedt Original-X-From: musl-return-6666-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 02 23:48:14 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XvwEw-0004jZ-C6 for gllmg-musl@m.gmane.org; Tue, 02 Dec 2014 23:48:14 +0100 Original-Received: (qmail 6021 invoked by uid 550); 2 Dec 2014 22:48:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 6013 invoked from network); 2 Dec 2014 22:48:12 -0000 Content-Disposition: inline In-Reply-To: <1417557612.4936.1138.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6653 Archived-At: On Tue, Dec 02, 2014 at 11:00:12PM +0100, Jens Gustedt wrote: > 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 :) Well, maybe, if they handle it via warning suppression in the system header path. But this seems fragile. > > > > 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 Then what about something like #if __clang__ // && __clang_major__*100+__clang_minor__ <= xxxxx // use clang compound literal hack #elif __GNUC__*100+__GNUC_MINOR__ >= 407 // use __builtin_complex #else // use _Complex_I with mult and add #endif or alternatively: #if __clang__ // && __clang_major__*100+__clang_minor__ <= xxxxx // use clang compound literal hack #else // use __builtin_complex #endif I somewhat prefer the latter since the _Complex_I form is never really correct (INF/NAN issues) and it gives better fallback behavior assuming other compilers will implement __builtin_complex but might not identify themselves as "GNU C >= 4.7". It also produces an error on compilers that can't give the right behavior for INF/NAN rather than silently miscompiling the code. > > > > _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 Because of the _-prefixed namespace? Per my understanding, it's conforming to #undef macros provided by the standard headers in many cases. Eliminating a function-like macro to get at the underlying function is one such usage mentioned in the standard, but I think there are others too. > > 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. Yes, I really wish GCC would support it, especially since Annex G _requires_ _Imaginary_I, and glibc falsely advertises Annex G support via the __STDC_IEC_559_COMPLEX__ macro despite not having _Imaginary_I. But the glibc folks seem to think this is a non-issue and I haven't seen any interest in fixing it on the GCC side. Rich