Re: [PATCH 1/4] the CMPLX macros must be usable in initializations of static variables

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 5127 bytes --]

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 <complex.h>
> > > > > 
> > > > > 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 ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]