Beim Compilieren von Hit1270.c kommt bei mir ein interner Compiler
Fehler, wenn ich als Optimierung "o3" wähle. Mit Optimierung "os" ist
die Welt in Ordnung.
Umgebung: WindowsXP, AVR Studio 4, aktuelles WinAVR (GCC 4.3.3).
Der Fehler kommt aber auch, wenn ich dem WinAVR einen GCC 4.7.2 unter
schiebe. Als CPU ist ATMega1284 gewählt.
../Hit1270.c:97: error: unrecognizable insn:
(insn 9 8 10 3 ../Hit1270.c:80 (set (reg:HI 18 r18)
(reg:SI 121)) -1 (nil))
../Hit1270.c:97: internal compiler error: in extract_insn, at
recog.c:2048
Ich würde mich freuen, wenn noch jemand versuchen würde, das Programm zu
übersetzen und Erfolg/Misserfolg hier melden würde, damit die
Fehlerursache eingegrenzt werden kann.
Vielen Dank im Voraus,
Georg.
Just for the record (hatte mit Georg bereits vorher gemailt): ich kann
es auf einem GCC 4.5.1 und 4.7.2 unter FreeBSD bzw. Linux nicht
reproduzieren.
Ein interner Compilerfehler sollte natürlich nie passieren.
Andererseits
ist es seltsam, warum er nur bei der Windows-Version auftreten sollte.
Ohne einen reproduzierbaren Fehler ist es aber nicht praktikabel, dass
Georg einen PR bei GCC einreicht, daher nochmal die Bitte an andere,
seinen Test nachzuvollziehen.
Mit welchen Optionen bitte?
Mein "gcc version 4.3.3 (WinAVR 20100110)" kennt kein ATmega1284, ditto
für die offiziellen 4.7 und 4.8.
Und mit 4.7.2-1573 von Atmel compiliert es ganz normal (Win2000):
$ avr-gcc hit1270.c -mmcu=atmega1284 -O3 -S
In file included from hit1270.c:9:0:
./avr/include/util/delay.h:90:3: warning: #warning "F_CPU not defined
for <util/delay.h>" [-Wcpp]
Johann L. schrieb:> Mein "gcc version 4.3.3 (WinAVR 20100110)" kennt kein ATmega1284
Er meint einen ATmega1284P. Mir hatte er noch das Makefile
mitgegeben.
Optionen (aus dem Makefile):
Auch damit bekomme ich keinen ICE hin, weder für WinAVR-20100110 nich
für 4.7.2 (mingw32 oder Atmel) oder 4.8.1 (prerelease).
Der ICE sieht mir eher nach zerschossenem Speicher oder einer kaputten
Installation aus.
Johann L. schrieb:> Der ICE sieht mir eher nach zerschossenem Speicher oder einer kaputten> Installation aus.
Das erklärt natürlich irgendwie die "Selektivität", wenngleich es
dann immer noch verwundert, warum Georg das Problem mit zwei
verschiedenen Compilerversionen bekommt.
./. schrieb:> Vielleicht laeuft der Compiler auf einem alten Pentium.
Albern. Der blöde FDIV-Bug war zwar real, aber praktisch kaum
relevant. Für einen Compiler schon gar nicht. Der F00F-Bug wiederum
hätte ganz gewiss nicht zu einem internal compiler error geführt …
Jörg Wunsch schrieb:> Das erklärt natürlich irgendwie die "Selektivität", wenngleich es> dann immer noch verwundert, warum Georg das Problem mit zwei> verschiedenen Compilerversionen bekommt.
Vielleicht hat Georg ja beim "WinAVR-Unterschieben" (so wie er das oben
nennt) des gcc-4.7.2 einen Fehler gemacht und damit beide Versionen
miteinander derart vermischt, dass beide nicht mehr laufen.
Georg sollte mal erklären, wie er das mit dem Compiler-Austausch
bewerkstelligt hat.
> Albern.
Es gab mindestens eine Version, die eine CPU > Pentium vorausgesetzt
hat.
Was ist daran albern...
Albern finde ich eher den Compiler so zu bauen...
Nur kurz, später am Tag ausführlicher:
Der Rechner ist ein Dual Core E5300 mit 4GB RAM. Den Pentium Bug kann
man also ausschliessen.
Speicherfehler sind unwahrscheinlich, wenn der Fehler an mehreren Tagen
auftritt. Der Compiler läuft nicht immer an den gleichen Adressen.
Der Fehler tritt reproduzierbar auf mit WinAVR-GCC 4.3.3 und zwar nur
mit "o0" bis "o3", nicht mit "os".
Das "Unterschieben" wird auf den Seiten der 4.7.2-mingw32 Version sehr
gut beschrieben. Und damit man gefahrlos zurück kann, gibt es ab XP die
Möglichkeit, den Systemzustand einzufrieren und wieder her zu stellen.
Man kann auch ohne Probleme beide Compiler Versionen in getrennten
Verzeichnissen installieren und dann von der Eingabeaufforderung aus das
Makefile aufrufen.
Ich werde heute Abend mal alles auf dem Rechner der Ehefrau installieren
und dort testen. Momentan bin ich ratlos.
Georg G. schrieb:> Das "Unterschieben" wird auf den Seiten der 4.7.2-mingw32 Version sehr> gut beschrieben.
Um zu sehen, dass du auch tatsächlich den passenden Compiler benutzt,
kannst du in die Compileroptionen noch ein -v mit aufnehmen. Dann
gibt er dir die Version mit aus.
Er findet das include. Sonst würde er meckern, dass er das Include nicht
findet. Ich habe es auch ausprobiert.
Kompilieren mit MCU am Anfang sieht genauso aus wie oben.
Ich habe gerade mal in den Headerfile iom1284p.h gesehen. Die Pins
heißen alle PORTD4 und nicht PD4. Im File iom16.h steht wiederum PD4.
Das ist ja auch merkwürdig. Ist da ein Mischmasch gebaut worden bei dem
GCC hier? Aber das wird jetzt OT.
900ss D. schrieb:> Ist da ein Mischmasch gebaut worden bei dem GCC hier? Aber das wird> jetzt OT.
PORTD4 = bit 4 in Register PORTD
PD4 = bit 4 in PIND, DDRD oder PORTD (generischer Bitname)
Ja, da war mal was, dass bei einigen Controllern manche Definitionen
fehlten.
Versuch doch, seine .i-Datei zu compilieren.
900ss D. schrieb:> Ist da ein Mischmasch gebaut worden bei dem> GCC hier? Aber das wird jetzt OT.
DER Punkt ist einfach zu klären :-)
io.h bindet am Schluss portpins.h ein. Dort steht die Definition.
Allen einen herzlichen Dank für die Anregungen. Der Übeltäter ist
gefunden.
Ich hatte mal die AVR-Toolchain installiert. Die hat offensichtlich
einiges zerwürfelt. Nach Deinstallation ist der Fehler nun verschwunden.
Nun muss ich nur noch Win-AVR davon überzeugen, auch am Ende des Make
den Speicherverbrauch zu melden. Es wird wohl darauf hinauslaufen, alles
komplett neu zu installieren.
Georg G. schrieb:> auch am Ende des Make den Speicherverbrauch zu melden.
Dürfte eine Frage deines Projekt-Makefiles sein. Das, welches du mir
mitgegeben hast, hat das ja getan.
