Hi, Am Mittwoch, den 03.12.2014, 09:38 -0500 schrieb Rich Felker: > On Wed, Dec 03, 2014 at 10:18:31AM +0100, Jens Gustedt wrote: > > > #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. so you want to see this changed explicitly, the day they support this? on that day the correct version will most certainly look like #ifndef __has_builtin #define __has_builtin(x) 0 // Compatibility with non-clang compilers. #endif #if __clang__ && !__has_builtin(__builtin_complex) // use clang compound literal hack #else // use __builtin_complex #endif so we could have that from the start and not talk about it anymore :) > > 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. most reserved identifiers are only so, provided you include this or that header, e.g bool, false and true. The _Something identifiers are always reserved, they are reserved for language specific features, not library. > In any case this isn't a really important matter. agreed > > > > 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. yes, good idea, also it makes it explicit for the eye that this is a complex value. For me, having a heavily biased math background, reading 0.0i as complex is still counterintuitive. 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 ::