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

[Paolo Bonzini]

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