On Sat, Dec 5, 2020 at 6:12 AM Alan Modra <amo...@gmail.com> wrote: > > On Thu, Oct 29, 2020 at 10:10:58PM +1030, Alan Modra wrote: > > Fixes > > FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-not stxvd2x > > FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times mfvsrd 3 > > FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times srdi 3 > > FAIL: gcc.target/powerpc/signbit-2.c scan-assembler-times ld 1 > > FAIL: gcc.target/powerpc/signbit-2.c scan-assembler-times srdi 1 > > on powerpc-linux (or powerpc64-linux biarch -m32). > > David, > This patch is fixing a regression caused by one of your testsuite > patches. Please review. > > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557443.html > > > signbit-1.c is quite obviously a 64-bit only testcase given the > > scan-assembler directives, and the purpose of the testcase to verify > > the 64-bit only UNSPEC_SIGNBIT patterns. It could be made to pass for > > -m32 by adding -mpowerpc64, but that option that isn't very effective > > when bi-arch testing and results in errors on rs6000-aix. And it is > > pointless to match -m32 stores to the stack followed by loads, which > > is what we do at the moment. > > > > signbit-2.c on the other hand has more reasonable 32-bit output. > > > > Regression tested powerpc64-linux biarch. > > > > * gcc.target/powerpc/signbit-1.c: Reinstate lp64 condition. > > * gcc.target/powerpc/signbit-2.c: Match 32-bit output too.
Alan, I agree that signbit-1.c clearly checks for 64-bit only instructions, and signbit-2.c was checking for 64-bit only prior to this patch. The PPC port has an explosion of 128 bit options (float128, ieee128, long double, ieee128 in hardware, float128 in vsx, float128 in quad float library), and less than ideal clarity about the differences. As much as possible, I would like the testcase requirements set correctly, once, and then not repeatedly adjust the testcases manually for targets that we later discover should or should not succeed. We have too many ISA/ABI/OS variations and a lot of testcases. We don't have the resources to continually tweak them. I would like to differentiate among "this works on PPC64LE Linux" versus "this work on Power8" or "Power9" or "Power10" or "MMA" versus "IEEE128" versus "!aix && !darwin". Not substituting PPC64 Linux or Power9 to mean IEEE128. Where possible we should check for the requirements that we are testing, not convenient stand-ins. That being said, it's now clear that there is no target test in the testsuite that captures float128 VSX functionality. So testing float128_sw and lp64 is the best alternative. Or maybe the testcase should test for the VSX level where those instructions were introduced? Thanks for investigating this and creating a patch. The patch is okay. Thanks, David
