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

paolo.carlini at oracle dot com gcc-bugzilla@gcc.gnu.org
Mon Sep 19 11:44:00 GMT 2011


             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):

  struct limits;

  struct limits<__int128> { };

  struct limits<unsigned __int128> { };

a.cc:8:26: error: ISO C++ does not support ‘__int128’ for ‘type name’
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:

  struct limits;

  struct limits<__int128_t> { };

  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.

More information about the Gcc-bugs mailing list