Forum: Compiler & IDEs unable to find a register to spill in class ‘POINTER_REGS’
Hi!
Da hier ja ein paar Leute vom avr-gcc Team aktiv sind, hoffe ich hier
Hilfe zu bekommen. Ich bastel gerade an einem Projekt, wo mich derzeit
der o.g. Fehler aufhält. Ich habe nach dem Fehler gesucht und einen Bug
Eintrag gefunden (#39212,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39212). Dieser sollte mit
AVR-GCC 4.5.2 und 4.6.1 behoben sein, bzw. nicht mehr nachvollziehbar
sein. Da ich unter Windows nicht weiter kam, habe ich nun mir Ubuntu
genommen und darauf weiter gemacht. Leider stoße ich dort mit der
Version 4.5.3 auf genau den gleichen Fehler. Nun bin ich etwas ratlos
(vor allem da der Fehler nicht nachvollzogen werden kann).
Ich habe den gesamten Stand mal angehangen, aus dem Grund, wenn ich den
Code irgendwo anpasse oder ändere ist der Fehler weg, tritt aber dann
über kurz oder lang an anderer Stelle wieder auf. Somit ist es schwierig
den Code einzukürzen, weil damit läuft der desto eher fehlerfrei durch.
Somit ist ein kurzes prägnantes Beispiel nicht möglich. Das ist auch mit
ein Grund, dass ich dieses große Projekt nicht bei GCC anhängen möchte.
Zu den Development/Toolchains:
Windows:
AVR Studio 4.19 (build 730)
AVR Toolchain 3.3.0 (AVR-GCC: 4.5.1, AVR-LIBC: 1.7.1)
Linux:
Eclipse
CDT Plugin 6.0.2
AVR Plugin 2.3.4 (AVR-GCC: 4.5.3, AVR-LIBC: 1.7.1)
1 | Building file: ../menu.c
| 2 | Invoking: AVR Compiler
| 3 | avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega16 -DF_CPU=16000000UL -MMD -MP -MF"menu.d" -MT"menu.d" -c -o"menu.o" "../menu.c"
| 4 | ../menu.c: In function ‘menu_cycle’:
| 5 | ../menu.c:492:1: error: unable to find a register to spill in class ‘POINTER_REGS’
| 6 | ../menu.c:492:1: error: this is the insn:
| 7 | (insn 669 493 494 71 ../menu.c:479 (set (reg:QI 18 r18)
| 8 | (mem/c:QI (plus:HI (reg/f:HI 28 r28)
| 9 | (const_int 1 [0x1])) [6 S1 A8])) 858 {*movqi} (nil))
| 10 | ../menu.c:492: confused by earlier errors, bailing out
| 11 | make: *** [menu.o] Error 1
|
Ich werde mich nebenbei mal hinsetzen und versuchen einen neuen Stand
vom avr-gcc und der avr-libc aus den Repositories zu holen und zu
übersetzen.
Grüße,
Muetze1
Bei manchen spill fails hilft ein -fno-caller-saves, vielleicht ja auch
hier. Ein Allheilmittel ist's allerdings nicht.
Hallo Johann,
ja, das hilft mir über den Fehler. Damit kann ich dann zumindest erst
einmal weiter arbeiten. Danke für die schnelle Hilfe.
Falls ich neue Erkenntnisse habe oder der Fehler trotzdem wieder
auftritt, dann melde ich mir hier nochmals.
Danke,
Thomas
Hallo,
so, ich habe nun den Rest des Tages damit zugebracht die folgenden
Pakete zu bauen und zu installieren:
avr-gcc 4.6.2
avr-libc 1.8.0
binutils 2.22
avrdude 5.11 svn 20111019
gdb 7.4
simulavr 1.0
avarice 2.12
Nebenbei dann nochmal Eclipse 3.6 RC 2 und das AVR Plugin neu da mit
rein.
Der Fehler bei den oben angehängten Sourcen bleibt bestehen:
1 | GNU C (GCC) version 4.6.2 (avr)
| 2 | compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9
| 3 | GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
| 4 | Compiler executable checksum: 5597ab2a6a433c5f3ad032ba6eddff9d
| 5 | ../menu.c: In function ‘menu_cycle’:
| 6 | ../menu.c:492:1: error: unable to find a register to spill in class ‘POINTER_REGS’
| 7 | ../menu.c:492:1: error: this is the insn:
| 8 | (insn 672 496 497 71 (set (reg:QI 18 r18)
| 9 | (mem/c:QI (plus:HI (reg/f:HI 28 r28)
| 10 | (const_int 1 [0x1])) [4 S1 A8])) ../menu.c:479 4 {*movqi}
| 11 | (nil))
| 12 | ../menu.c:492: confused by earlier errors, bailing out
|
Aber dafür klappt nun die Integration in Eclipse einwandfrei. Nun habe
ich zumindest eine ordentliche Umgebung ;-)
Mit der genannten Option -fno-caller-saves klappt es dann auch mit dem
4.6.2 wieder. Vielleicht hilft der obige Projektstand ja das Problem im
GCC zu beheben.
Danke,
Muetze1
Thomas K. schrieb:
> Vielleicht hilft der obige Projektstand ja das Problem im
> GCC zu beheben.
Die Aussage allein hilft leider nicht viel.
Könntest du das mit -save-temps und ohne caller-saves erzeugen und das
Modul.i, das den ICE erzeugt, anhängen?
Klar, kein Problem. Setze ich mich heute Abend nach der Arbeit mal ran.
Hi,
ich habe es wie gewünscht erstellt und dann gleich mal nochmal alles
eingepackt. Damit hast du somit auch die .s Dateien und weiteres. Ich
hoffe das so dann hilfreicher.
Grüße,
Thomas
hoioi, du gehtst ja nicht gerade zimperlich mit dem Speicherplatz um ;-)
Der Testfall war ziemlich komplex, konnte aber deutlich vereinfacht
werden:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925#c19
Och naja, Debug Build hat so eine gewisse kleine Überbelegung, aber im
Release passt doch noch alles rein. Und viel fehlt ja auch nicht mehr an
Code. Ich komme aus der App Entwickler Ecke und von daher: Speicher ist
genügend vorhanden. Beim AVR muss ich das wohl nochmal selbst lernen,
wenn es eng wird. Aber der ATMega16 sollte derzeit noch genug Reserven
haben - glaube ich zumindest.
Ansonsten prägnant kurzes Beispiel. Hätte nicht gedacht, dass man es so
klein bekommt. Aber ich denke mal, da fehlt auch das Wissen, was zu dem
Fehler führt. Ich hätte das wohl nie so kurz bekommen.
Danke für deine Hilfe und ich hoffe, dass man den Bug vllt. mal weiter
ausmerzen kann. Sofern es überhaupt ein Bug ist...
Grüße,
Thomas
Thomas K. schrieb:
> Ansonsten prägnant kurzes Beispiel. Hätte nicht gedacht, dass man es so
> klein bekommt. Aber ich denke mal, da fehlt auch das Wissen, was zu dem
> Fehler führt. Ich hätte das wohl nie so kurz bekommen.
Ich hab's auch nur durch Hin- und Herprobieren rausgefunden; mit
Delta-Debugging kenne ich mich leider nicht aus.
> Danke für deine Hilfe und ich hoffe, dass man den Bug vllt. mal weiter
> ausmerzen kann. Sofern es überhaupt ein Bug ist...
Ja klar ist es ein Bug. Egal was man in GCC reinstopft — auf einen ICE
sollte er nie laufen.
Der Fehler ist im komplexesten Part von GCC überhaupt: dem
Register-Allokator, der eine beliebige Anzahl von s.g. Pseudo-Registern
auf den konkreten Registersatz der Hardware abzubilden hat, den
Stackframe verwaltet, Spill-Code erzeugt, usw.
Über diesen Teil von GCC schreibt ein Artikel im GCC-Wiki:
>> Reload is the GCC equivalent of Satan.
und ein anderer:
>> [...] which means reload changes. Do not go there;
>> it cannot be done by mortals.
Ich sollte mir wohl endlich mal Buch über Compilerbau durchlesen fg
Aber alles in allem vielen Dank für deine Hilfe. Ich konnte ja schon
sehen, wie du auch auf der mailing List recht beschäftigt bist. Und auch
danke für die Erklärungen.
Grüße,
Thomas
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|
Thread beobachten
Seitenaufteilung abschalten