Hi Carl,
>> I'd expect the "-runnable" test case focuses on testing for run. Normally,
>> the one without "-runnable" would focus on testing for compiling (scan some
>> desired insn), but this altivec-1.c and altivec-1-runnable.c seems to test
>> for different things, maybe we should separate them into different names
>> if they don't test for a same test point.
>
> The altivec-1-runnable.c and altivec-2-runnable.c tests were added for various
> built-ins that didn't have any test cases. There wasn't an intention that
> there was
> any connection to the existing altivec-*.c test files. I started creating
> runnable
> when I started adding support for built-ins that we claimed to support but
> had never
> actually been implemented. I created runnable tests to make sure my
> implementation
> actually worked. I continued to add runnable tests for built-ins
> that existed but didn't have a test case. Adding runnable tests did find a
> couple
> of issues where the existing implementation had a bug.
>
> That all said, if we want tochange the name of altivec-1-runnable.c and
> altivec-2-runnable.c a different naming scheme that is fine with me. Perhaps
> we should
> finish fixing the header for this test file, then do altivec-1-runnable, and
> then
> a final patch that does all the file renaming?
Yes, that's what I preferred, maybe something like altivec-run-n.c or
altivec-runnable-n.c to avoid the possible confusion.
>>> That said, I don't like not having a -mdejagnu-cpu=... here.
>>> I think for our server cpus, this is fine, but on an embedded system
>>> with a old ISA default for -mcpu=... (so we be doing a dg-do compile),
>>> just adding -maltivec to that default may not make much sense for that
>>> default and probably should be an error. Maybe something like:
>>
>> Yes, for some embedded cpus, there will be some error messages, but since
>> we have powerpc_altivec_ok effective target, the error would make that
>> effective target checking fail so I'd expect it'll stop it being tested
>> (unsupported).
>>
>>>
>>> /* { dg-do run { target vmx_hw } } */
>>> /* { dg-do compile { target { ! vmx_hw } } } */
>>> /* { dg-require-effective-target powerpc_altivec_ok } */
>>> /* { dg-options "-O2 -mdejagnu=power7" } */
>>>
...
> We had -mdejagnu=power8 before, but it looks like we want to go to power7 now.
>
> It sounds like we want the following:
>
> /* { dg-do run { target vmx_hw } } */
> /* { dg-do compile { target { ! vmx_hw } } } */
> /* { dg-options "-O2 -mdejagnu=power7" } */
> /* { dg-require-effective-target powerpc_altivec } */
As mentioned above, I'd expect powerpc_altivec can stop this being tested
without altivec feature support, so IMHO an explicit cpu type isn't necessary
(though I'm not opposed to specifying it), btw, s/-mdejagnu/-mdejagnu-cpu/.
BR,
Kewen
