http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50454
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ktietz at gcc dot gnu.org
--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-19
23:20:33 UTC ---
Looks like something is wrong in the grokdeclarator logic. We do:
if (explicit_int128)
{
if (int128_integer_type_node == NULL_TREE)
{
error ("%<__int128%> is not supported by this target");
ok = 0;
}
else if (pedantic)
{
pedwarn (input_location, OPT_pedantic,
"ISO C++ does not support %<__int128%> for %qs",
name);
if (flag_pedantic_errors)
ok = 0;
}
}
but *only* as part of the conditional:
/* Check all other uses of type modifiers. */
if (unsigned_p || signed_p || long_p || short_p)
This explains why the first specialization alone, which uses only plain
__int128, never triggers any warning or error, with -pedantic or
-pedantic-errors.
Then, as you can see above, in case of -pedantic-errors, ok is set = 0, which
implies, afterward (line 8717), that unsigned_p is set back to false, thus
obviously the following very weird redefinition error with my snippet.
Thus, I think we should first decide whether __int128 and unsigned __int128
should both consistently behave as, currently, __int128 and __int128_t and
__uint128_t, thus no warning or error whatsoever with -pedantic and
-pedantic-errors. Otherwise, have something consistent for __int128 and
unsigned __int128, which, for the latter, doesn't scrap away the unsigned (then
if we fix the latter issue, GCC system_error should work fine automatically)
What do you think? Maybe Kai has also something to say about the logic he meant
to implement, and/or wants to suggest the right place for the check:
if (int128_integer_type_node == NULL_TREE)
{
error ("%<__int128%> is not supported by this target");
ok = 0;
}
which I think we want anyway *somewhere*, both for __int128 and unsigned
__int128, if we don't have it already somewhere else.
