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 am a bit reluctant to file a bug report about this as apparently it changes between SVN versions.

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

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.

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

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

Yes, this is the same issue.

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.

The pattern is simple: procedures with high register pressure calling procedure taking a lot of parameters in combination with code which generates instructions working with constants.

I am currently working on improving the avr cg so it wastes less registers, this might help. Though it does not solve the problem but it only hides it.

As long as this remains an issue in 64bit - operations it is of little relevance for an 8bit microcontroller that spends most of it's life shuffling bytes and words. I would not put too much effort into that, at least not if a real solution, i.e. rewriting the related parts of the register allocator is somewhere in the pipeline.

There is another phenomenon (that actually might be just another side of the same coin) that bothers me more and that I call "detours": a calculation result is first copied to a second register (and maybe even a third) before finally stored at it's final destination, memory or function result. This is not broken code, but it unnecessarily increases both code size and execution time. I have seen that in one of your last fixes you already changed something in that respect ("remove useless mov instructions"). I will try to reproduce my former observations with the latest version, and if this issue persits, report.