Am 09.09.19 um 18:20 schrieb Christo Crause:
I ran the compiler test suite for the avr-embedded target to see how a modification I made impacts things. There are however so many compilation failures (over 1100) due to unsupported features (floating point support, sysutils, variants, classes etc.) that it is difficult to spot relevant failures. Filtering out floating point testing can be done by checking for the FPUNONE definition. I'm not sure whether it is possible to filter out tests for other features, particularly functionality that maps to a runtime error if EXCLUDE_COMPLEX_PROCS is defined. I can scan through all the tests searching for floating point types and ifdef the floating point code using ifndef FPUNONE. Other tests involving unsupported keywords/units can be skipped by adding %SKIPCPU=AVR to these tests, but this is in my mind not a future proof way of filtering functionality to test. > I also want to add timeouts (say 60s) for the more intensive tests such as test/tindex.pp. Some tests may require reducing the test space so that a simulator can complete the tests in a reasonable time, i.e. test/cg/tmoddiv2.pp performs several sets of 20000 random tests, but takes an enormous amount of time to run through a simulator. Obviously this is an important test to prove correctness of integer math, but I would like to reduce the loop count to 200 for AVR so that the test can complete in about a minute or two.
This is fine. But just reduce the loops for 8 Bit CPUs. It is most likely that they are slow. A timeout is imo not a good idea. Better reduce the number of iterations.
Does anyone have better ideas on how to filter out tests for unsupported features that will be future proof (i.e. if functionality is added to AVR then the relevant tests would automatically be active)?
Not really, I think the only clean way is to check for the appropriate feature flags.
Would these kind of modifications be accepted into trunk (at least in principle)? I'll create a git repository for this work.
The feature based ones imo yes as well as the reduction of loops for small CPUs.
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
