[PATCH 2/4] cimag and friends shouldn't return an lvalue

[PATCH 2/4] cimag and friends shouldn't return an lvalue

[Jens Gustedt]

This is nothing imperative, but is a bit more user friendly, because it
should error out in situations that a user of these macros can't expect
to work.

If __GNU__ is detected, this uses the "__imag__" extension of gcc and
friends. This should be the less costly solution. It should not create a
temporary object, even in absence of optimization. This extension is
arround in all versions of gcc that provide complex arithmetic.
---
 include/complex.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/complex.h b/include/complex.h
index 3e14e04..be5bd7e 100644
--- a/include/complex.h
+++ b/include/complex.h
@@ -101,8 +101,13 @@ double creal(double complex);
 float crealf(float complex);
 long double creall(long double complex);
 
+#ifdef __GNUC__
+#define __CIMAG(x, t) \
+	(__extension__ __imag__ (_Complex t)(x))
+#else
 #define __CIMAG(x, t) \
-	((union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
+	(+(union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
+#endif
 
 #define creal(x) ((double)(x))
 #define crealf(x) ((float)(x))
-- 
1.9.1

Re: [PATCH 2/4] cimag and friends shouldn't return an lvalue

[Rich Felker]

On Tue, Nov 25, 2014 at 03:49:55PM +0100, Jens Gustedt wrote:
> This is nothing imperative, but is a bit more user friendly, because it
> should error out in situations that a user of these macros can't expect
> to work.
> 
> If __GNU__ is detected, this uses the "__imag__" extension of gcc and
> friends. This should be the less costly solution. It should not create a
> temporary object, even in absence of optimization. This extension is
> arround in all versions of gcc that provide complex arithmetic.
> ---
>  include/complex.h | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/include/complex.h b/include/complex.h
> index 3e14e04..be5bd7e 100644
> --- a/include/complex.h
> +++ b/include/complex.h
> @@ -101,8 +101,13 @@ double creal(double complex);
>  float crealf(float complex);
>  long double creall(long double complex);
>  
> +#ifdef __GNUC__
> +#define __CIMAG(x, t) \
> +	(__extension__ __imag__ (_Complex t)(x))
> +#else
>  #define __CIMAG(x, t) \
> -	((union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
> +	(+(union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
> +#endif

Short of a good reason to need the GNU-specific version (like subtle
non-conformance, performance issues, or other problems in the portable
version), it's generally preferred in musl not to have multiple
versions of the same code where one would go largely untested. But
making it a non-lvalue seems like a good idea just to catch bugs.

Rich

Re: [PATCH 2/4] cimag and friends shouldn't return an lvalue

[Jens Gustedt]

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

Am Dienstag, den 02.12.2014, 12:58 -0500 schrieb Rich Felker:
> On Tue, Nov 25, 2014 at 03:49:55PM +0100, Jens Gustedt wrote:
> > This is nothing imperative, but is a bit more user friendly, because it
> > should error out in situations that a user of these macros can't expect
> > to work.
> > 
> > If __GNU__ is detected, this uses the "__imag__" extension of gcc and
> > friends. This should be the less costly solution. It should not create a
> > temporary object, even in absence of optimization. This extension is
> > arround in all versions of gcc that provide complex arithmetic.
> > ---
> >  include/complex.h | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/complex.h b/include/complex.h
> > index 3e14e04..be5bd7e 100644
> > --- a/include/complex.h
> > +++ b/include/complex.h
> > @@ -101,8 +101,13 @@ double creal(double complex);
> >  float crealf(float complex);
> >  long double creall(long double complex);
> >  
> > +#ifdef __GNUC__
> > +#define __CIMAG(x, t) \
> > +	(__extension__ __imag__ (_Complex t)(x))
> > +#else
> >  #define __CIMAG(x, t) \
> > -	((union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
> > +	(+(union { _Complex t __z; t __xy[2]; }){(_Complex t)(x)}.__xy[1])
> > +#endif
> 
> Short of a good reason to need the GNU-specific version (like subtle
> non-conformance, performance issues, or other problems in the portable
> version),

no temporary would be a reason for me, and using the tool that is
forseen by the compiler makers would be another

but I don't have a strong opinion on that

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 --]