On 11 June 2014 00:03, Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon > <christophe.l...@linaro.org> wrote: >> This is patch series is a more complete version of the patch I sent >> some time ago: >> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00624.html >> >> I have created a series of patches to help review. The 1st one adds >> some documentation, the common .h files defining helpers used in the >> actual tests, and two real tests (vaba and vld1) to show how the >> various macros are used. >> >> The next patches add other tests (grouped when they use a common >> framework). >> >> Looking at the .exp file, you'll notice that the tests are performed twice: >> * once using c-torture-execute to make sure they execute correctly >> under various levels of optimization. In this case dejagnu >> directives embedded in each .c test file are ignored. >> >> * once using gcc-dg-runtest, which enables compiling with various >> optimization levels and scanning the generated assembly for some >> code sequences. Currently, only the vadd test contains some >> scan-assembler-times directives, as an example. We can add such >> directives to other tests later. > >> >> Regarding the results of these tests on target >> arm-none-linux-gnueabihf, note that: >> * vclz tests currently fail at optimization levels starting with -O1 >> * vqadd test fails when compiled with -Os >> * vadd scan-assembler fails for vadd.i64 (because the compiler uses >> core registers instead of Neon ones. Not sure if this should be >> considered as a bug or if the test should be changed) >> * this gives 1164 PASS and 18 FAIL >> > > I am a bit ambivalent between getting folks to add scan-assembler > tests here and worrying between this and getting the behaviour > correct. Additionally if you add the complexity of scanning for > aarch64 as well this starts getting messy. >
This feature wasn't in my testsuite originally, I added it recently after your suggestion. Indeed it's getting messy, not sure what the best way to proceed (and that's why I only added the scan-assembler as an example in one test :-) > At this point I'm going to wait to see if any of the testsuite > maintainers step in and comment and if not I'll start looking at this > properly early next week. > OK thanks. Christophe.
