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 2 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
