complex support when using -std=c++11

2015-11-12 Thread D Haley

Dear List,

I am currently trying to understand an issue to do with complex number 
support in gcc.


Consider the following code:

#include 
int main()
{
float _Complex  a = _Complex_I;

}

Attempting to compile this with  these commands is fine:
$ g++ tmp.cpp -std=gnu++11
$ g++ tmp.cpp

Clang is also fine:
$ clang tmp.cpp -std=c++11

Attempting to compile with c++11 is not:
$ g++ tmp.cpp -std=c++11
In file included from /usr/include/c++/5/complex.h:36:0,
 from tmp.cpp:2:
tmp.cpp: In function ‘int main()’:
tmp.cpp:5:29: error: unable to find numeric literal operator ‘operator""iF’
 float _Complex  a = _Complex_I;
 ^
tmp.cpp:5:29: note: use -std=gnu++11 or -fext-numeric-literals to enable 
more built-in suffixes


I'm using debian testing's gcc:
$ gcc --version
gcc (Debian 5.2.1-17) 5.2.1 20150911
...


I discussed this on #gcc, and it was suggested (or I misunderstood) that 
this is intentional, and the library should not support c-type C++ 
primitives - however I can find no deprecation notice for this, nor does 
it appear that the c++11 standard (as far as I can see from a quick 
skim) has changed the behaviour in this regard.


Is this intended behaviour, or is this a bug? This behaviour was noticed 
when troubleshooting compilation behaviours in mathgl.


https://groups.google.com/forum/?_escaped_fragment_=topic/mathgl/cl4uYygPmOU#!topic/mathgl/cl4uYygPmOU


Thanks.




Re: complex support when using -std=c++11

2015-11-15 Thread D Haley

Dear Marc,

Thanks for the prompt reply. I am not an expert here, so I probably 
don't know the correct solution for gcc. We are using std=c++11 to 
maximise source compatibility for any users seeking to recompile our 
code on whatever compiler/toolchain they have.



As to your suggestions for possible fixes, my thoughts are as follows:

> * _Complex_I is defined as (__extension__ 1.0iF). Maybe __extension__
> could imply -fext-numeric-literals?

I am unsure if such extensions might cause problems elsewhere due to 
preprocessor substitution. This would be my concern here.



> * glibc could define _Complex_I some other way, or libstdc++ could
> redefine it to some other safer form (for some reason __builtin_complex
> is currently C-only).

This seems totally reasonable, but as an end-user , I am not certain if 
this can be achieved within the specifications.  It sounds good though.


Thanks!