On 04.09.2017 17:02, Peter Maydell wrote:
> On 4 September 2017 at 15:09, Laurent Vivier <laur...@vivier.eu> wrote:
>> You can:
>>
>> either replace the "#define floatx80_pi make_floatx80(...)" by a "const
>> floatx80 floatx80_pi = make_floatx80_init(...)"
>>
>> or replace all the macros in the m68k/fpu_helper.c array by
>> make_floatx80_init(...)
>
> Taking a step back, what's different about floatx80 and float12
> that means they need separate _init and non-init versions of
> the macros, when for float16/float32/float64 we instead have
> #define make_float32(x) __extension__ ({ float32 f32_val = {x}; f32_val; })
> #define const_float32(x) { x }
>
> ? Could we move to consistency for the macro naming we're using?
>
> thanks
> -- PMM
>
I don't have insight on the reasoning, but float128 suffers from the
same reason as float80.
static const float128 fpu_rom123[128] = {
[0] = make_float128(0, 12)
};
target/m68k/fpu_helper.c:58:1: error: initializer element is not constant
target/m68k/fpu_helper.c:58:1: error: (near initialization for
'fpu_rom123[0]')
rules.mak:66: recipe for target 'target/m68k/fpu_helper.o' failed
make[1]: *** [target/m68k/fpu_helper.o] Error 1
On the other hand, something like this builds:
static const float16 fpu_rom123[128] = {
[0] = make_float16(0)
};
signature.asc
Description: OpenPGP digital signature
