https://bugs.kde.org/show_bug.cgi?id=447989
--- Comment #9 from Paul Floyd <pjfl...@wanadoo.fr> --- (In reply to David Benjamin from comment #8) > Regarding the generating the expected files by running the test, I assume > those just record what my patch does. I.e. if my patch were wrong, the wrong > things would get recorded in expectations. I've run my test against > BoringSSL's use of these instructions, so I'm fairly confident it's correct. > But it seems to me we can do better: just synthesize the expected output by > running the instructions directly, without involving valgrind at all. Yes. Generally for the error detecting tools the stderr.exp file checks that the errors are detected (and that there are no false positives). The 'none' tests ensure that the opcodes are handled and they usually 'printf' random values that get fed into the FP or crypto opcodes. Running the standalone exe to generate the stdout.exp files is probably the best. There are some rare cases when it needs to be done with Valgrind (usually when the exe using client requests to change code paths). > I don't suppose this exists? (If not, no big deal. Like I said, I've already > manually tested this against BoringSSL.) There are some perl scripts for testcase generation. For instance see none/tests/amd64/gen_insn_test.pl Otherwise I just use a lot of copy and paste. > Regarding where to put the tests, these are indeed Armv8.2 instructions, but > I noticed fp_and_simd_v82's prerequisite is actually the fphp (floating > point half-precision) extension. These instructions are from a separate > extension. My test device happens to have both but, in principle, they're > orthogonal. > > Should I still put them in fp_and_simd_v82 or make a new one? I'm guessing a > new one would be preferable, though this would get pretty large fast. Arm, > alas, has lots and lots of extensions. E.g. I noticed that the Armv8.0 > cryptography instructions are just in the plain fp_and_simd test, with no > prereq, but not all Armv8.0 chips have those instructions. (It's pretty rare > to omit them, but I think the Raspberry Pis don't?) > > If I make a new one, should I just copy all the various helper macros at the > top of that file, or try to extract them somewhere? Seems they're in a few > places already. I'm not really an ARM expert. It sounds like it would be best to create a new test and refactor the helpers into a single header. For the extensions and -march (and -mcpu -mthumb -marm) it's all a bit of a mess. For instance see https://bugs.kde.org/show_bug.cgi?id=454346. All I ran really say is that it worked for the original environment used for the arm64 port (qemu afaict) and it works on my Pi 5, the sourceware buildbot farm and the few other aarch64 machines that I have access to. -- You are receiving this mail because: You are watching all bug changes.
