[fpc-devel] building ppcrossavr, internal error 200309041

[Georg Hieber]

In build 30522 I think I observed a variant of the problem:

The make cycle aborts again when crosscompiling system.pp with the error 
message:

sstrings.inc(1268,3) Error: Local variables size exceeds supported limit
sstrings.inc(1261,18) Fatal: Procedure too complex, it requires too many 
registers

First there was the Internal error 200309041 in generic.inc, line 1917, 
which I "fixed" by putting the procedure in {$ifndef CPUavr} .. {$endif} 
block, after that occurred  the above. I "fixed" this the same way, and 
the rtl compiles.

Please confirm if that is the same issue, or something new.

best regards, Georg



Am 09.04.2015 um 18:38 schrieb Georg Hieber:
> 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
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel