[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141203143852.GI4574@brightrain.aerifal.cx>
Date: Wed, 3 Dec 2014 09:38:52 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/4] the CMPLX macros must be usable in
initializations of static variables
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 <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.
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
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.
