[Bug c++/50454] New: Unexpected problems with -pedantic / -pedantic-errors and __int128 and unsigned __int128 specializations

["paolo.carlini at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454

             Bug #: 50454
           Summary: Unexpected problems with -pedantic / -pedantic-errors
                    and __int128 and unsigned __int128 specializations
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: paolo.carlini@oracle.com


Consider the following, with -pedantic-errors (-pedantic triggers a warning):

template<typename>
  struct limits;

template<>
  struct limits<__int128> { };

template<>
  struct limits<unsigned __int128> { };

a.cc:8:26: error: ISO C++ does not support â__int128â for âtype nameâ
[-pedantic]
a.cc:8:10: error: redefinition of âstruct limits<__int128>â
a.cc:5:10: error: previous definition of âstruct limits<__int128>â

The first and second error lines are certainly incorrect. If I remove the
second specialization the error goes away completely. GCC system_header appear
to help, but then soon the problem resurfaces, eg, together with PCHs.

As an additional data point, the following appears to work, no errors or
warnings with either option:

template<typename>
  struct limits;

template<>
  struct limits<__int128_t> { };

template<>
  struct limits<__uint128_t> { };

(and I'm using it for the time being for PR40856), but still isn't entirely OK,
I can still trigger errors post 40856 for the following user code snippet
compiled with -std=gnu++0x -pedantic-errors on, eg, x86_64-linux (at least
-pedantic is fine in this case)

#include <limits>

static_assert(std::numeric_limits<__int128_t>::is_specialized == true, "");
static_assert(std::numeric_limits<__uint128_t>::is_specialized == true, "");

Something is definitely fishy here, considering in particular that, I'm told,
__int128_t should be just a typedef for __int128, likewise __uint128_t for
unsigned __int128.