|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [PULL 18/76] optionrom: add new PVH option rom |
Date: | Mon, 22 Mar 2021 17:26:36 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |