From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6670 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: Wed, 3 Dec 2014 09:38:52 -0500 Message-ID: <20141203143852.GI4574@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> <20141202224754.GK29621@brightrain.aerifal.cx> <1417598311.4936.1220.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=us-ascii X-Trace: ger.gmane.org 1417617573 19888 80.91.229.3 (3 Dec 2014 14:39:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 14:39:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6683-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 03 15:39:26 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 1XwB5S-0006WB-4U for gllmg-musl@m.gmane.org; Wed, 03 Dec 2014 15:39:26 +0100 Original-Received: (qmail 26528 invoked by uid 550); 3 Dec 2014 14:39:05 -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 26482 invoked from network); 3 Dec 2014 14:39:05 -0000 Content-Disposition: inline In-Reply-To: <1417598311.4936.1220.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:6670 Archived-At: On Wed, Dec 03, 2014 at 10:18:31AM +0100, Jens Gustedt wrote: > Hello, > > Am Dienstag, den 02.12.2014, 17:47 -0500 schrieb Rich Felker: > > On Tue, Dec 02, 2014 at 11:00:12PM +0100, Jens Gustedt wrote: > > 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. > > I agree with your analysis, we should avoid using _Complex_I, here. > > For the implementation I don't agree completely. Version number games > are not the right thing for clang, they don't support this, in a sense > in the same way that you don't want a macro that identifies musl. OK. I had it commented just as a suggestion that we could do some detection for clang versions that need the clang-specific compound literal hack if/when there are versions that no longer need it. In any case right now it would just be #ifdef __clang__ I think. > But still, I'd like to have a version with _Imaginary_I, see below. I'd like to have it in mind for the future, but putting it in the file is confusing since it can't be used without further changes to the file. > > > > > > _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? > > Yes, an implementation simply *mustn't* touch any identifier that > starts with underscore and capital letter. Period. Or other reserved identifiers? I think you're just saying things that you're explicitly allowed to #undef are special, and otherwise reserved identifiers are not admissible for #undef. In any case this isn't a really important matter. > > > 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. > > argh, I wasn't aware of that, what a mess. yes _Imaginary and all that > comes with it is really an important feature of that Annex, e.g > functions returning _Imaginary values when known to have such values. > > So I keep my claim for a first case version with _Imaginary_I up :) > we should encourage compiler implementors to provide this feature. > > I looked a bit around and I found that > - Keil supports imaginary > - for Cray compilers 1.0i is pure imaginary and not complex, but they > don't explain exactly what happens if you use this in arithmetic Perhaps we should redefine _Complex_I as (0.0f+1.0fi) so that it's clearly complex even if the compiler has 1.0fi as a pure-imaginary type. Rich