on 2024/1/24 11:11, Peter Bergner wrote:
> On 1/23/24 8:30 PM, Kewen.Lin wrote:
>>> - output_operand_lossage ("invalid %%x value");
>>> + output_operand_lossage ("invalid %%%c value", (code == 'S' ? 'S' :
>>> 'x'));
>>
>> Nit: Seems simpler with
>>
>> output_operand_lossage ("invalid %%%c value", (char) code);
>
> Agreed, good catch.
>
>
>
>
>>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr112886.c
>>> b/gcc/testsuite/gcc.target/powerpc/pr112886.c
>>> new file mode 100644
>>> index 00000000000..4e59dcda6ea
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/powerpc/pr112886.c
>>> @@ -0,0 +1,29 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-require-effective-target power10_ok } */
>>
>> I think this needs one more:
>>
>> /* { dg-require-effective-target powerpc_vsx_ok } */
>
> I agree with this...
>
>
>
>>> +/* { dg-options "-mdejagnu-cpu=power10 -O2" } */
>>
>> ... and
>>
>> /* { dg-options "-mdejagnu-cpu=power10 -O2 -mvsx" } */
>>
>> , otherwise with explicit -mno-vsx, this test case would fail.
>
> But not with this. The -mdejagnu-cpu=power10 option already enables -mvsx.
> If the user explcitly forces -mno-vsx via RUNTESTFLAGS, then let them.
> The options set in RUNTESTFLAGS come after the options in the dg-options
> line, so even adding -mvsx like the above won't help the test case PASS
But this is NOT true, at least on one of internal Power10 machine (ltcden2-lp1).
With the command below:
make check-gcc-c RUNTESTFLAGS="--target_board=unix/-mno-vsx
powerpc.exp=pr112886.c"
this test case fails without the explicit -mvsx in dg-options.
>From the verbose dumping, the compilation command looks like:
/home/linkw/gcc/build/gcc-test-debug/gcc/xgcc
-B/home/linkw/gcc/build/gcc-test-debug/gcc/
/home/linkw/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr112886.c -mno-vsx
-fdiagnostics-plain-output -mdejagnu-cpu=power10 -O2 -ffat-lto-objects
-fno-ident -S
-o pr112886.s
"-mno-vsx" comes **before** "-mdejagnu-cpu=power10 -O2" rather than **after**.
I guess it might be due to different behaviors of different versions of runtest
framework?
So there can be two cases with user explicitly specified -mno-vsx:
1) RUNTESTFLAGS comes after dg-options (assuming same order for -mvsx in
powerpc_vsx_ok)
powerpc_vsx_ok test failed, so UNSUPPORTED
// with explicit -mvsx does nothing as you said.
2) RUNTESTFLAGS comes before dg-options
powerpc_vsx_ok test succeeds, but FAIL.
// with suggested -mvsx, make it match the powerpc_vsx_ok checking and the
case not fail.
As above I think we still need to append the "-mvsx" explicitly. As
tested/verified, it
does help the case not to fail on ltcden2-lp1.
BR,
Kewen
> if we didn't have the powerpc_vsx_ok test. In other words, the -mvsx option
> doesn't help with anything.
>
> All we need is the new powerpc_vsx_ok check and that will guard against the
> FAIL
> in the case the user forces -mno-vsx. In that case, we'll just get an
> UNSUPPORTED
> and that is fine.
>
> Peter
>
>
>
