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

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.

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)?

Would these kind of modifications be accepted into trunk (at least in
principle)? I'll create a git repository for this work.
fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to