On Thu, 12 Nov 2015, D Haley wrote:
I am currently trying to understand an issue to do with complex number
support in gcc.
Consider the following code:
#include <complex.h>
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
Not here, I am getting the same error with clang (or "use of undeclared
identifier '_Complex_I'" with libc++). This probably depends more on your
libc.
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
C++11, for some unknown reason, decided to hijack the C header complex.h
and make it equivalent to the C++ header complex. The fact that you are
still getting _Complex_I defined is already a gcc extension, as is
providing _Complex in C++.
The C++ standard introduced User Defined Literals, which prevents the
compiler from recognizing extra suffixes like iF in standard mode (why are
so many people using c++11 and not gnu++11?).
Our support for complex.h in C++11 in gcc is kind of best-effort. In this
case, I can think of a couple ways we could improve this
* _Complex_I is defined as (__extension__ 1.0iF). Maybe __extension__
could imply -fext-numeric-literals?
* 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).
--
Marc Glisse
