For better reliability and maintenance in the future for Valgind's Linux TileGx platform, we need add instruction set tests in none/tests/<archname>/*.c. Reproducible: Always
Ping. Any progress here?
It's being worked on. A patch will be posted soon.
Where is the patch? We've added the port on your promise to provide insn set tests shortly thereafter. Those have not materialised. Nor has a nightly build to observe the quality of the port. Please let us know if you're no longer able to maintain the port.
Created attachment 93488 [details] attachment-9713-0.html I has worked with Liming Sun at ezchip on this. He is going to upload the patch based on our last conversation. I can ping him if he did not yet. Sorry about the delay. On Jul 5, 2015 6:22 PM, "Florian Krohm" <florian@eich-krohm.de> wrote: > https://bugs.kde.org/show_bug.cgi?id=345921 > > Florian Krohm <florian@eich-krohm.de> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |florian@eich-krohm.de > > --- Comment #3 from Florian Krohm <florian@eich-krohm.de> --- > Where is the patch? We've added the port on your promise to provide insn > set > tests shortly thereafter. Those have not materialised. Nor has a nightly > build > to observe the quality of the port. > Please let us know if you're no longer able to maintain the port. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
Created attachment 93498 [details] valgrind-tilegx-instruction-test.patch
Created attachment 93499 [details] valgrind-VEX-tilegx-instruction-test.patch
Thanks Zhi-Gang's help these changes. Regression results seem ok (below). == 1066 tests, 33 stderr failures, 1 stdout failure, 1 stderrB failure, 3 stdoutB failures, 6 post failures == gdbserver_tests/hgtls (stdoutB) gdbserver_tests/mcinvokeWS (stdoutB) gdbserver_tests/mcinvokeWS (stderrB) gdbserver_tests/nlpasssigalrm (stderr) gdbserver_tests/nlvgdbsigqueue (stderr) gdbserver_tests/nlvgdbsigqueue (stdoutB) memcheck/tests/err_disable1 (stderr) memcheck/tests/err_disable2 (stderr) memcheck/tests/err_disable3 (stderr) memcheck/tests/fprw (stderr) memcheck/tests/inlinfo (stderr) memcheck/tests/inltemplate (stderr) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/lks (stderr) memcheck/tests/mallinfo (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin6-fp (stderr) memcheck/tests/recursive-merge (stderr) memcheck/tests/sendmsg (stderr) memcheck/tests/sh-mem-random (stdout) memcheck/tests/sh-mem-random (stderr) memcheck/tests/sh-mem (stderr) memcheck/tests/test-plo-yes (stderr) memcheck/tests/undef_malloc_args (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/xml1 (stderr) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) none/tests/async-sigs (stderr) none/tests/libvexmultiarch_test (stderr) none/tests/linux/mremap4 (stderr) none/tests/linux/mremap5 (stderr) none/tests/linux/mremap6 (stderr) helgrind/tests/tc22_exit_w_lock (stderr)
How are the changes in VEX related to the testcases? In none/tests/tilegx: When I run the gen_test.sh script it generates a bunch of insn_test_XXXXX.c files. I presume these are the testcases you want to compile, link and run. To do that you need to add a .vgtest file for every such testcase and an .stdout.exp (and/or .stderr.exp) file. I guess your gen_test.sh script can be easily convinced to provide those as well. As to the regression results... they do not look OK to me. There are many failing testcases that only fail on your platform. Take a look at the nightly regression (posted to the testresults mailing list) to get a feeling for what tests are fragile (in the sense that they fail on other platforms as well -- possibly intermittently).
(In reply to Florian Krohm from comment #8) > How are the changes in VEX related to the testcases? > > In none/tests/tilegx: > When I run the gen_test.sh script it generates a bunch of insn_test_XXXXX.c > files. I presume these are the testcases you want to compile, link and run. > To do that you need to add a .vgtest file for every such testcase and an > .stdout.exp (and/or .stderr.exp) file. I guess your gen_test.sh script can > be easily convinced to provide those as well. > > As to the regression results... they do not look OK to me. There are many > failing testcases that only fail on your platform. Take a look at the > nightly regression (posted to the testresults mailing list) to get a feeling > for what tests are fragile (in the sense that they fail on other platforms > as well -- possibly intermittently). The VEX change is to address an issue of tilegx porting. We could commit this separately. Basically fix a bug fir some simd instructions. The gen_test.sh should be called directly. Make check or make regtest will invoke it. And *.vgtest *.stdout.exp etc will be generated as well.
(In reply to Zhi-Gang Liu from comment #9) > (In reply to Florian Krohm from comment #8) > > How are the changes in VEX related to the testcases? > > > > In none/tests/tilegx: > > When I run the gen_test.sh script it generates a bunch of insn_test_XXXXX.c > > files. I presume these are the testcases you want to compile, link and run. > > To do that you need to add a .vgtest file for every such testcase and an > > .stdout.exp (and/or .stderr.exp) file. I guess your gen_test.sh script can > > be easily convinced to provide those as well. > > > > As to the regression results... they do not look OK to me. There are many > > failing testcases that only fail on your platform. Take a look at the > > nightly regression (posted to the testresults mailing list) to get a feeling > > for what tests are fragile (in the sense that they fail on other platforms > > as well -- possibly intermittently). > > The VEX change is to address an issue of tilegx porting. We could commit > this separately. Basically fix a bug fir some simd instructions. > > The gen_test.sh should NOT be called directly. Make check or make regtest will > invoke it. And *.vgtest *.stdout.exp etc will be generated as well.
I will commit the VEX patch first, since it is a chante to Tilegx Valgrind, not part of the instruction test. But credit to Liming Sun, who found this issue during the instruction set test.
"valgrind-VEX-tilegx-instruction-test.patch" was commit to VEX @r3161
Any more comments on the tilegx instruction test patch "valgrind-tilegx-instruction-test.patch" post by Liming Sun. I had tried it, the make check invoke a test code generator, which generates insn_XX.c for instruction XX, there are about total 600 or 700 total insn_XX.c and their coresponding *.vgtest, *.stdout.exp generated. The new changes did not introduce any new test failure. If no other comments, I will merge this patch tonight or tomorrow.
Committed the patch "valgrind-tilegx-instruction-test.patch" -r15466 Credit to Liming Sun for this work.
This should have been closed back in 2015, and tilegx support has since been pulled.