qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 18/76] optionrom: add new PVH option rom


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]