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