On 06/06/17 12:41 +0100, Charles Baylis wrote:
On 6 June 2017 at 11:07, James Greenhalgh <james.greenha...@arm.com> wrote:
If we don't mind that, and instead take a GCC-centric view, we could avoid
namespace polution by using the GCC-internal names for the intrinsics
(__builtin_aarch64_...). As those names don't form a guaranteed interface,
that would tie us to a GCC version.
So we have a few solutions to choose from, each of which invokes a trade-off:
1 Use the current names and pollute the namespace.
2 Use the GCC internal __builtin_aarch64* names and tie libstdc++ to GCC
internals.
3 Define a new set of namespace-clean names and complicate the Neon
intrinsic interface while we migrate old users to new names.
I can see why the libstdc++ community would prefer 3) over the other options,
but I'm reticent to take that route as the cost to our intrinsic maintainers
and users looks high. I've added some of the other ARM port maintainers
for their opinion.
Are there any other options I'm missing?
If solving for C++ only is OK, then it might be feasible to do something like:
namespace __arm_neon_for_ext_random {
#include <arm_neon_internal.h> // like arm_neon.h, but without
include guards [*]
}
Then the libstdc++ headers can use "using namespace
__arm_neon_for_ext_random" inside the functions which use NEON
intrinsics.
[*] without include guards so that other header files can use the same
trick in their own namespace.
I'm not sure if this will work for all host compilers, with GCC I
think it's OK because the intrinsics are implemented as inline
functions, rather than #defines, but not all compilers have taken that
approach.
It would be a bit better, but this valid (albeit silly) program would
be rejected:
#define int32x4_t ++/!!!POISONED!!!/++
#include <ext/random>
int main() { }
Users are allowed to use names like int32x4_t for their own macros,
because that's not a name reserved for the implementation.
ARM developers are probably aware of those names and would avoid them,
but developers writing portable code that might get used on ARM are
now also unable to use those names if <ext/random> might use them.
Of course, using names that aren't ALL_CAPS for macros is crazy, but
the standard library has to support craziness as long as it doesn't
violate the standard. That's why including <arm_neon.h> in libstdc++
headers is problematic. I would be prepared to live with it for a
non-standard extension header, but Ulrich makes a good point about
this code maybe going into namespace std one day.
