[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1417619535.4936.1328.camel@eris.loria.fr>
Date: Wed, 03 Dec 2014 16:12:15 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in
initializations of static variables
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 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
