[fpc-devel] building ppcrossavr, internal error 200309041

Florian Klämpfl florian at freepascal.org
Thu Apr 9 17:29:37 CEST 2015


Am 07.04.2015 um 23:54 schrieb Georg Hieber:
> Hello,
> As during the last days a lot of changes occurred to files related to the avr port - btw., thanks to
> everybody! - I wanted to build the latest SVN version (30489). Doing "make clean all
> OS_TARGET=embedded CPU_TARGET=avr", the compiler builds, but when compiling system.pp, compilation
> aborts with "sstrings.inc(835,1) Fatal: Internal error 200309041". A few days ago, on 29.3., the
> make went through without errors.
> 
> I had this problem before, and changing the optimization level changes the behavior. If I hand
> compile system.pp with -O1, the error in sstrings.inc dissapears, but it appears as
> "text.inc(1232,1) Fatal: Internal error 200309041". I also had this error before, and as a
> workaround to at least compile system.pp I disabled textio. That way at least I get a system.o to
> work with, but somewhere there is a problem.

I know about this and it is a fundamental problem with the current register allocator. Currently,
the register allocator cannot handle CPUs with non-orthogonal register sets. However, the AVR
register set is non-orthogonal regarding the instructions operating on constants. (andi, ldi etc.)
The register allocator does not handle this properly when spilling, it might select a register for
spilling which does not simplify the register allocation graph. To overcome this, parts of the
register allocator need to be rewritten.

So far, I just comment the procedures causing an ie 200309041 on avr in my working copy. They are
normally complex procedures dealing with int64/currency and are unlikely to be used in avr code.

> 
> I am a bit reluctant to file a bug report about this as apparently it changes between SVN versions.

Since it changes where it appears, I think a bug report is not very useful indeed. OTOH, if you want
to document the problem, feel free to submit one but it won't change the situation as the problem is
known, see above.

> 
> Another question: is it true that the compiler build cycle needs the last stable version (2.6.4) to
> start, and won't work with a newer one (3.1.1)?
> 

Yes. Starting with 3.1.1 works most of the time though but it is not guranteed.



More information about the fpc-devel mailing list