On 6/5/2022 4:16 pm, Sebastian Huber wrote: > Hello Chris, > > thanks for the tests.
My pleasure. Thank your gcc12. > On 05/05/2022 11:28, Chris Johns wrote: >> On 4/5/2022 3:54 pm, Sebastian Huber wrote: >>> On 04/05/2022 02:14, Chris Johns wrote: >>>> On 3/5/2022 4:56 pm, Sebastian Huber wrote: >>>> Are there any posted test results? >>> >>> I did only local test runs on simulators so far. >>> >> >> I have posted some test results for the erc32 on SIS, zynq on qemu and >> ultrascale on hardware: >> >> https://lists.rtems.org/pipermail/build/2022-May/033152.html >> https://lists.rtems.org/pipermail/build/2022-May/033153.html >> https://lists.rtems.org/pipermail/build/2022-May/033154.html >> >> This covers SPARC on a simulator, ARM 32 bit on qemu and ARM 64bit on >> hardware. >> >> - There are some new warnings which is expected >> >> - erc32 >> >> It has 3 new failures compared to the test results posted by Joel earlier >> this >> month. They are: >> >> crypt01.exe > > The crypt01 is a long running test. OK. >> spintrcritical23.exe > > I see also sporadic failures in the spintrcritical* tests on this BSP > independent of the compiler. > >> minimum.exe > > The minimum test is an issue on all BSPs since the RTEMS tester has no way to > figure out what to do since the test has no output. One option would be to use > ELF files for the tester input with ELF notes for the test state, etc. This is a fantastic is idea. We can also embed more information as we need relating to load considerations, time outs and more. > >> >> - arm >> >> This seems fine. I do not have a base line to compare. The tester seemed to >> crash if the log and log mode options are not specified. >> >> - aarch64 bsps >> >> These BSPs generated lots of warnings in the testsuite due to this line: >> >> https://git.rtems.org/rtems/tree/bsps/aarch64/include/bsp/start.h#n175 >> >> The warning is about comparing arrays. I have not looked deeper. > > This can be fixed by using RTEMS_OBFUSCATE_VARIABLE(). Ah ok. Thanks. >> >> The aarch64 test results are very good. I have not tested the Versal (A72) >> but I >> will tomorrow test libbsd on that that architecture. There are 3 failures: >> >> malloc04.exe >> psxconfig01.exe >> ts-validation-no-clock-0.exe >> >> The only one I am not sure about it the last one. >> >> Conclusion: >> >> I think the results show we can move to gcc12. There are some rough edges >> related to warnings we need to clean up and I am sure they will addressed. > > Ok, good. Lets wait for the GCC 12.1 release. > Sure. >> >> Sebastian, if you wish to make the change I am ok but I ask if you are OK >> with >> the testing solution I posted could you please push that patch and make the >> change on it? > > Which patch and change are you referring to? > The patch you posted is now not valid as I have changed the default files. It is nothing more than that. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel