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):
1 | CFLAGS += -Wall -gdwarf-2 -std=gnu99 -save-temps -DF_CPU=16000000UL -O3 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums |
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.
Vielleicht laeuft der Compiler auf einem alten Pentium. Da passieren schonmal merkwuerdige Dinge.
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.
Ich habe hier gerade einen GCC-4.3.3 unter Cygwin am laufen.
1 | $ avr-gcc --version |
2 | avr-gcc (Memsic 20120521) 4.3.3 |
3 | Copyright (C) 2008 Free Software Foundation, Inc. |
4 | This is free software; see the source for copying conditions. There is NO |
5 | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
Wenn ich das wie folgt kompiliere, dann entsteht kein interner Compiler Fehler. Die Optionen habe ich oben aus Jörg seinem Posting.
1 | $ avr-gcc hit1270.c -mmcu=atmega1284p -O3 -S -Wall -gdwarf-2 -std=gnu99 -save-temps -DF_CPU=16000000UL -funsigned-char |
2 | -funsigned-bitfields -fpack-struct -fshort-enums |
3 | hit1270.c: In function 'cmd_write': |
4 | hit1270.c:41: error: 'PD4' undeclared (first use in this function) |
5 | hit1270.c:41: error: (Each undeclared identifier is reported only once |
6 | hit1270.c:41: error: for each function it appears in.) |
7 | hit1270.c:42: error: 'PD2' undeclared (first use in this function) |
8 | hit1270.c:42: error: 'PD5' undeclared (first use in this function) |
9 | hit1270.c:44: error: 'PD6' undeclared (first use in this function) |
10 | hit1270.c: In function 'data_write': |
11 | hit1270.c:55: error: 'PD4' undeclared (first use in this function) |
12 | hit1270.c:56: error: 'PD5' undeclared (first use in this function) |
13 | hit1270.c:57: error: 'PD2' undeclared (first use in this function) |
14 | hit1270.c:59: error: 'PD6' undeclared (first use in this function) |
Kann es sein, dass die -mmcu-Option zuerst stehen muss, damit er das passende #include auch findet?
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.
1 | $ avr-gcc -mmcu=atmega1284p hit1270.c -O3 -S -Wall -gdwarf-2 -std=gnu99 -save-temps -DF_CPU=16000000UL -funsigned-char |
2 | -funsigned-bitfields -fpack-struct -fshort-enums |
3 | hit1270.c: In function 'cmd_write': |
4 | hit1270.c:41: error: 'PD4' undeclared (first use in this function) |
5 | hit1270.c:41: error: (Each undeclared identifier is reported only once |
6 | hit1270.c:41: error: for each function it appears in.) |
7 | hit1270.c:42: error: 'PD2' undeclared (first use in this function) |
8 | hit1270.c:42: error: 'PD5' undeclared (first use in this function) |
9 | hit1270.c:44: error: 'PD6' undeclared (first use in this function) |
10 | hit1270.c: In function 'data_write': |
11 | hit1270.c:55: error: 'PD4' undeclared (first use in this function) |
12 | hit1270.c:56: error: 'PD5' undeclared (first use in this function) |
13 | hit1270.c:57: error: 'PD2' undeclared (first use in this function) |
14 | hit1270.c:59: error: 'PD6' undeclared (first use in this function) |
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.
Jörg Wunsch schrieb: > > Versuch doch, seine .i-Datei zu compilieren. Siehe unten:
1 | $ avr-gcc -mmcu=atmega1284p hit1270.i -O3 -S -Wall -gdwarf-2 -std=gnu99 -save-temps -DF_CPU=16000000UL -funsigned-char |
2 | -funsigned-bitfields -fpack-struct -fshort-enums |
3 | ../Hit1270.c:22: warning: 'txt_color' defined but not used |
4 | ../Hit1270.c:23: warning: 'chapos' defined but not used |
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.