On 09/19/17 19:39, Eric Blake wrote: > On 09/19/2017 11:30 AM, Richard Henderson wrote: >> On 09/18/2017 05:46 AM, Laurent Vivier wrote: >>> Redefine make_floatx80() and make_float128() as make_float16(), >>> make_float32() and make_float64() using a variable and not only >>> a cast. > >>> -#define make_floatx80(exp, mant) ((floatx80) { mant, exp }) >>> -#define make_floatx80_init(exp, mant) { .low = mant, .high = exp } >>> +#define make_floatx80(exp, mant) __extension__ \ >>> + ({ floatx80 f80_val = { .low = mant, .high = exp }; f80_val; }) >>> +#define const_floatx80(exp, mant) { .low = mant, .high = exp } > >> >> I don't like this part -- (type){ init } is a standard C99 compound literal. >> There's no point using a gcc extension instead. > > The C99 compound literal is not a const initializer in all situations, > though :( Here's another thread where we had a similar discussion, but > there, the solution was to just make the macro behave as an initializer > (which is C99 compliant, but loses some type safety) instead of relying > on a gcc extension: > > https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg06566.html > > I suspect you're running into the same issues that Laszlo already helped > us understand regarding QLit. >
Thanks for the CC! I don't have much context, but the patch looks quite isolated. I think I agree with Richard here -- I don't think there's any reason to change the replacement text of make_floatx80. The patch names make_float64() as an earlier example (already using __extension__), but I don't understand why make_float64() was written that way. ... It seems to go back to ancient commit f090c9d4ad58 ("Add strict checking mode for softfp code.", 2007-11-18). Was C99 support (esp. compound literals) spotty in gcc back then? Not having much background, I'd suggest the opposite change -- replace the statement-expression in make_float64() with a compound literal. Thanks Laszlo