[fpc-devel] Updating compiler test suite for limited AVR features

[Florian Klämpfl]

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.