On Thu, Apr 14, 2022 at 01:56:39PM -0300, Alexandre Oliva wrote: > On Apr 14, 2022, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Sat, Apr 17, 2021 at 06:19:02AM -0300, Alexandre Oliva wrote: > >> On Apr 12, 2021, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > >> > On Fri, Apr 02, 2021 at 01:52:59PM -0300, Alexandre Oliva wrote: > >> >> Several compile tests that use the __ieee128 type do not ensure it is > >> >> defined. This patch adds -mfloat128 to their command lines, and > >> >> disregards the warning that may be issued by it. > >> > >> > But they do make sure it is defined, they use -mcpu=power9 (etc.). What > >> > is different in your setup that that does not work? > >> > >> I suppose it's either -mno-altivec -mno-vsx in our self-specs, > > > Yes, that is a problem. > > Sorry, that message from last year was an unfounded suspicion of mine > based on incorrect information. Indeed, -mcpu=power9 combined with > -mno-vsx raise an error.
Lol, the dates line up very well, I didn't realise it was from 2021 :-) > The relevant fact, described in yesterday's message, is that -mfloat128 > is not enabled by default, even with -mcpu=power9, except on target > variants that define TARGET_FLOAT128_ENABLE_TYPE to nonzero. As you > stated, its overall default is zero (though GNU/Linux overrides it to > nonzero), so the existing tests do not conform with the machine's > defaults in assuming -mfloat128 is enabled by -mcpu=power9. First off, vxworks.h should not disable it again. Then, this needs to be fixed, indeed. But that would be a code fix, not a testsuite workaround. If you use -mcpu=power9 it should support QP float. Segher
