r222074 - in /branches/google/gcc-4_9: contrib/...

[brooks@gcc.gnu.org]

Author: brooks
Date: Tue Apr 14 03:49:38 2015
New Revision: 222074

URL: https://gcc.gnu.org/viewcvs?rev=222074&root=gcc&view=rev
Log:
Make libstdc++'s complex and complex.h modular.

In C++11, this was already essentially the case. C++11 simply removes the C99
<complex.h> and does not make its facilities available. That is a fine and
reasonable stance and I've preserved it. I've also removed the unconditional
(and dead) undef that was breaking modular builds of the <complex> header.

The question is what should <complex.h> and <complex> do in C++98. Currently
these two headers conspire to undef 'complex' only when both are included. This
doesn't actually work well as it relies on non-modular behavior of observing
the order of inclusion. My proposed solution is to simply make including both
<complex> and <complex.h> in the same file an error in C++98. This error
remains non-modular, but is phrased in a way that should not preclude building
this code with modules. In a modular build, the polite error simply won't
trigger and instead the user will be faced with a compile error if they ever
try to use 'complex' as something other than a macro expanding to '_Complex'.
Eventually, we can use an explicit conflict marking in a modules map or other
tool to surface this kind of error even to modules builds.


Modified:
    branches/google/gcc-4_9/libstdc++-v3/include/c_compatibility/complex.h
    branches/google/gcc-4_9/libstdc++-v3/include/std/complex

Changes in other areas also in this revision:
Modified:
    branches/google/gcc-4_9/contrib/testsuite-management/aarch64-grtev4-linux-gnu.xfail
    branches/google/gcc-4_9/contrib/testsuite-management/powerpc64le-grtev4-linux-gnu.xfail
    branches/google/gcc-4_9/contrib/testsuite-management/x86_64-grtev4-linux-gnu.xfail