Laurent Vivier <laur...@vivier.eu> writes: > Le 09/01/2018 à 15:14, Peter Maydell a écrit: >> On 9 January 2018 at 14:12, Aurelien Jarno <aurel...@aurel32.net> wrote: >>> On 2018-01-09 13:27, Laurent Vivier wrote: >>>> Le 09/01/2018 à 13:22, Alex Bennée a écrit : >>>>> It's not actively built and when enabled things fail to compile. I'm >>>>> not sure the type-checking is really helping here. Seeing as we "own" >>>>> our softfloat now lets remove the cruft. >>>> >>>> I think it would be better to fix the build break than to remove the >>>> type-checking tool. >>>> >>>> but that's only my opinion... >>> >>> I agree with that. Those checks are useful for targets which call host >>> floating point functions for some instructions. This is ugly, but that's >>> what is still done for at least x86 for the trigonometrical functions. >>> The check prevents assigning a float or double value to a softfloat type >>> without calling the conversion function. >> >> Is gcc's codegen still bad enough that we have to default to not >> using the type-checking versions? If so, maybe we could at least >> enable the type-checking on an --enable-debug build, so it doesn't >> bitrot all the time. > > What means "bad enough"? for some targets it works fine. > > The problem with that is if it is not enabled all the time it becomes > broken really quick... > > BTW, if it doesn't break Alex's work I'm volunteer to fix > USE_SOFTFLOAT_STRUCT_TYPES build.
Be my guest - I suspect getting that merged would be on a faster path than the rest of the softfloat re-factoring patch series (unless the relative silence means everyone is happy with it ;-). By the way I mentioned in my header mail that the types are included from bswap.h so it would be nice to move the softfloat types somewhere where they could be more easily included to avoid triggering a re-build every time softfloat.h is touched. -- Alex Bennée
