[fpc-devel] building ppcrossavr, internal error 200309041

Georg Hieber georg at ghgrp.com
Thu Apr 9 23:38:25 CEST 2015


Florian, thanks for the explanation.

I will then use the same workaround, i.e. comment out offending procedures.

For the time being, I won't file a bug report, as you say it does not 
make much sense. I will, however, keep track of the behaviour, and if 
one day I see a certain pattern, I will document it.

best regards, Georg

Am 09.04.2015 um 12:29 schrieb Florian Klämpfl:
> 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.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




More information about the fpc-devel mailing list