On 22/03/21 14:57, Stefano Garzarella wrote:
On Mon, Mar 22, 2021 at 12:52:37PM +0100, Paolo Bonzini wrote:
On 22/03/21 11:59, Stefano Garzarella wrote:
If I build with gcc 10.2.1 20210313 (Alpine 10.2.1_pre2) uint64_t and
UINT64_C(1) have a size of 4 bytes, while UINT64_C(0x2052545020445352)
has a size of 8 bytes:
warning: initialization of ‘char (*)[4]’ from ‘int’ makes pointer
from integer without a cast [-Wint-conversion]
74 | char (*__size1)[sizeof(uint64_t)] = 1;
| ^
warning: initialization of ‘char (*)[4]’ from ‘int’ makes pointer
from integer without a cast [-Wint-conversion]
75 | char (*__size2)[sizeof(UINT64_C(1))] = 1;
| ^
warning: initialization of ‘char (*)[8]’ from ‘int’ makes pointer
from integer without a cast [-Wint-conversion]
76 | char (*__size3)[sizeof(UINT64_C(0x2052545020445352))] = 1;
Looks like long is 4 bytes long with -m16 and -m32, but 8 bytes with
-m64. The large constant is extended to long long because it's the
only way to fit it.
Yeah, but I expected uint64_t to always be on 8 bytes, regardless of the
architecture.
It's somehow using the -m64 definition (long int) instead of the -m32
definition (long long int), even though -m16 is basically "same as -m32
but emitting 16-bit encoded instructions".
Paolo
