Bug 17877

Summary: __extension__ should apply to long long constants
Product: gcc Reporter: algrant
Component: cAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: gcc-bugs
Priority: P2    
Version: 3.4.2   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:

Description algrant 2004-10-07 08:45:00 UTC
__extension__ applies to use of the "long long" type but not
to long long constants.  So in --ansi --pedantic
  __extension__ long long n = __extension__ 3ll;
warns about the constant.

The intention behind the use of __extension__ in <stdint.h> is
clearly to provide 64-bit types in such a way that diagnostics are
not provoked by defining them in terms of 'long long'.  However,
use of INT64_C does provoke a diagnostic, which is unreasonable
(the user is not supposed to care how INT64_C is implemented).
This could be avoided if __extension__ applied to ll constants.
Comment 1 Andreas Schwab 2004-10-07 09:33:56 UTC
But C89 doesn't have <stdint.h> and INT64_C. 
Comment 2 algrant 2004-10-07 09:48:46 UTC
Right, use of it in C89 is an extension.  That's the whole point,
and is why __extension__ is used in it.  But it only works for the
types, not the constants.

Someone clearly thinks "long long" should be available in C89
--ansi --pedantic, via __extension.  So the long long constant
syntax should also be available via __extension, to be consistent.
Comment 3 Joseph S. Myers 2004-10-07 10:38:33 UTC
Subject: Re:  New: __extension__ should apply to long long
 constants

On Thu, 7 Oct 2004, algrant at acm dot org wrote:

> __extension__ applies to use of the "long long" type but not
> to long long constants.  So in --ansi --pedantic
>   __extension__ long long n = __extension__ 3ll;
> warns about the constant.

Much the same applies to the macro I in <complex.h>, and an alternative 
possible solution would be not to warn if such constants arise from the 
expansion of macros in system headers.  In any case, this is already 
reported as bug 7263.

Comment 4 Andrew Pinski 2004-10-07 12:16:26 UTC

*** This bug has been marked as a duplicate of 7263 ***