Hallo zusammen,
ich hab hier ein Problem mit dem avr-gcc 4.7.2. Normalerweise neigt man
ja dazu, vorschnell auf einen Compilerfehler zu spekulieren, und das
Problem liegt dann doch im eigenen Code. Nach Recherche im Internet
neige ich jedoch zu glauben, ich habs hier wirklich mit einem internen
Compilerfehler zu tun.
Mein Code ist syntaktisch korrekt. Die Fehlermeldungen lauten:
1
unabletofindaregistertospillinclass'POINTER_REGS'
1
thisistheinsn:
1
confusedbyearliererrors,bailingout
Angeblich kommt der gcc nicht mit vielen globalen Variablen oder
Inline-Assembler zurecht. Letzteres nutze ich nicht, von Ersterem hab
ich ca. 30 Byte aufgeteilt auf 15 Variablen (In dieser
Übersetzungseinheit). Anscheinend gehen ihm manchmal die Register aus.
Leider hab ich meinen Code nicht zur Hand, würde ihn dann später
nachreichen.
Was mir auffällt:
In einer Funktion nutze ich zu Debugzwecken einen printf() Aufruf. Der
Fehler tritt auf, wenn ich diesen entferne. Mit printf() kompiliert das
Modul ganz normal. Meine Vermutung: Der Call einer externen Funktion
zwingt den gcc, seine Registerverwendung neu zu überdenken.
Allerdings sollte dieser Bug in einer 4.6.x Version des gcc bereits
behoben sein.
Weis da jemand, wie man Abhilfe schafft?
Viele Grüße!
Wenn Du einen Compilerfehler vermutest, nimm doch einfach nen ältern.
Der WINAVR (4.3.3) ist meiner Meinung nach sehr stabil.
Compilerfehler kriegt man in der Regel durch Syntaxfehler, die den
Parser komplett durcheinander bringen.
"confused by earlier errors" klingt sehr danach.
Was hast du für ein Target? Manche Tinys habe gar keinen Ram und müssen
mit ne Hand voll Registern auskommen. Dann könnte sowas vorkommen.
Poste am besten mal die gesamte Compilerausgabe.
Entschuldigung, ganz vergessen:
ATmega1284P, avr-gcc 4.7.2 unter Ubuntu 13.10.
@ Peter Danegger: darum gehts nicht.
Laut Internet ist es ein interner Compilerfehler, der allerdings als
behoben gilt.
Karlo schrieb:> Laut Internet ist es ein interner Compilerfehler
Ach je, wenn ich dem Internet immer alles glauben würde.
Was hindert Dich daran, es mit einem alten 4.3.3-er AVR-GCC zu
überprüfen?
Oder compiliere mal mit -O0.
Die neuen optimieren zwar etwas besser, aber da haben sich eben auch
neue Fehler eingeschlichen.
Wir kennen Deinen Quelltext nicht und können auch nicht aus dem
Kaffeesatz lesen. Du mußt schon selber etwas tun, um den Fehler
einzugrenzen.
Klaus Wachtler schrieb:> Dann nimm halt eine aktuellere Version, und gut iss.
In meiner Version dürfte der Fehler schon nicht mehr auftreten. Tut er
allerdings doch.
@ PeDa: Und dann? Dann seh ich dass er entweder mit dieser Version auch
schon auftrat, oder dass es damals noch funkte. Bringt was?
Mir gings eher darum zu erfahren, was diesen Fehler verursacht und wie
man ihn vermeidet.
Immerhin treiben sich hier ja auch gcc-ler herum.
Da du offensichtlich aber nicht in den Internas steckst und diesen
Fehler auch nicht kennst wirst du hier auch nichts mehr beitragen
können.
Auf eine andere Compiler-Version zu wechseln oder die Optimierungen zu
ändern, darauf bin ich selber auch gekommen, aber danke trotzdem.
Peter Dannegger schrieb:>> Laut Internet ist es ein interner Compilerfehler>> Ach je, wenn ich dem Internet immer alles glauben würde.
In dem Fall stimmt es aber. Diese Meldung ist immer ein Compilerfehler.
Karlo schrieb:> Auf eine andere Compiler-Version zu wechseln oder die Optimierungen zu> ändern, darauf bin ich selber auch gekommen, aber danke trotzdem.
Ja, was für andere Vorschläge hättest du denn genau erwartet? Das dir
mal eben jemand einen patch für deinen Compiler macht?
Träumer...
Oliver
Karlo schrieb:> Mir gings eher darum zu erfahren, was diesen Fehler verursacht
Das kann man nicht so einfach sagen.
Komplexe Systeme haben Unmengen von Möglichkeiten, wie sich Fehler
aufschaukeln können.
Ohne Code geht schon gleich gar nichts.
> Da du offensichtlich aber nicht in den Internas steckst und diesen> Fehler auch nicht kennst wirst du hier auch nichts mehr beitragen> können.
An deiner Stelle würde ich die Klappe nicht so weit aufreissen.
PeDa hat schon Probleme gelöst, von denen du noch nicht mal weist das es
diesen problemkreis gibt, geschweige denn wie man ihn lösen könnte.
Karlo schrieb:> @ PeDa: Und dann? Dann seh ich dass er entweder mit dieser Version auch> schon auftrat, oder dass es damals noch funkte. Bringt was?
Daß du im zweiten Fall einen Compiler hast, mit dem es geht und somit
dein Problem gelöst ist.
Oliver schrieb:> Ja, was für andere Vorschläge hättest du denn genau erwartet? Das dir> mal eben jemand einen patch für deinen Compiler macht?
Mir gings eher darum zu erfahren, was diesen Fehler verursacht und wie
man ihn vermeidet.
> Träumer...
Troll.
> Oliver
Karlo
Karlo schrieb:> Laut Internet ist es ein interner Compilerfehler, der allerdings als> behoben gilt.
Um das sicher zu sagen, müsstest du dir die Details ansehen, sowohl
deines Compilerfehlers als auch der behobenen (siehe Bug-Datenbank
vom GCC).
Wenn du dabei findest, dass er wirklich nach GCC 4.7.2 behoben worden
ist, kannst du ja zumindest mal gegentesten, ob sich der gleiche
Quellcode mit einer neueren Version compilieren ließen.
Johann L. schrieb:> Manchmal hilft -fno-caller-saves>> Ist in der betroffenen Funktion oder in darin geinlinte Funktionen> inline Assembler?
Nein, kein einziges mal.
Allerdings hat das Modul nach außen hin nur eine Funktion die zyklisch
aufgerufen wird. Alle anderen Funktionen (~10) sind static, also
modulintern. Da sie nur einmal aufgerufen werden (von der nach außen hin
sichtbaren Funktion) gehe ich davon aus dass sie alle geinlined werden.
Das müsst ich nachsehen. Der Fehler trat gestern spätabends das erste
mal auf, und wie gesagt, hab ich die Sourcen momentan nicht zur Hand.
@ Jörg Wunsch:
Laut http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39212 gilt er seit
Längerem als Behoben. Aber du hast recht, vielleicht ist es tatsächlich
ein anderer Bug der sich aber mit den selben Meldungen äußert.
Ich werd mal schauen ob ich übers WE einen 4.8.x gebaut kriege, dann
Teste ich mit dem.
Schwer zu sagen. Das Minimalbeispiel ist recht übersichtlich. Ich werd
heut schauen dass ich mein c-File soweit abspecke, dass der Fehler immer
noch auftritt.
Wird bestimmt lustig :/
Wie erwähnt, sogar ein printf() an einer bestimmten Stelle verhindert
den Fehler. Muss wohl Zeile für Zeile rausschmeissen und schaun ob er
auftritt :-)
Karlo schrieb:> Wie erwähnt, sogar ein printf() an einer bestimmten Stelle verhindert> den Fehler.
Das ist wenig überraschend. Da der Compiler beim Aufruf einer Funktion
davon ausgehen muss, dass alle caller-saved Register flöten gehen,
ändert sich die Registervergabe dadurch fundamental.
Eben, war auch meine Vermutung.
Der Rest der Datei ist eben eine mittel-große FSM die nur static
Funktionen aufruft, die wohl geinlined werden.
Mehr dazu hoffentlich heute Abend...
PeDa, wirklich nichts gegen dich, aber was soll das?
Ich weiß wie ich Funktionen deklarieren muss, damit sie nicht ge-inlined
werden.
Wahrscheinlich wird auch der Compilerfehler dann nicht mehr auftreten,
wie bei meinem printf()-call eben auch.
Aber wir (oder ich) versuchen doch hier den Bug zu identifizieren. Wie
A.K. auch vermutet hat es was mit den caller-saved Registern zu tun.
Jetzt muss ich schaun dass ich meine Datei abspeck, aber so, dass der
Fehler immer noch auftritt. Dann kann man schaun ob es wirklich der
selbe Fehler wie im von Johann L. verlinkten Bugreport ist oder ein
andrer.
Wie bereits viel weiter oben erwähnt: wenns mir darum ginge mein c-File
nur irgendwie kompiliert zu kriegen, es gäbe viele Möglichkeiten und ich
kenne diese (Compilerversion, verschiedene Compilerflags, etc.)
Karlo schrieb:> Wie bereits viel weiter oben erwähnt: wenns mir darum ginge mein c-File> nur irgendwie kompiliert zu kriegen, es gäbe viele Möglichkeiten und ich> kenne diese (Compilerversion, verschiedene Compilerflags, etc.)
Dein ursprüngliches Posting und die Überschrift klingen genau danach.
Ist halt immer etwas schwierig, wenn man erst im Nachhinein erklärt, daß
man eigentlich was ganz anderes will. Deshalb vermutlich die Verwirrung.
Karlo schrieb:> PeDa, wirklich nichts gegen dich, aber was soll das?
Ich wollte Dir nur aufzeigen, wie man den Fehler einkreisen kann.
Wenn nach Ändern einer Funktion auf noinline das Compilieren klappt,
dann hat man doch schon einen wichtigen Ansatzpunkt, an welcher Stelle
man suchen muß.
Wenn Du aber alles schon weißt, dann wundert es mich, warum Du das nicht
schon längst probiert hast.
Niemand kann in Deinen Kopf hineinsehen. Daß ein älterer Compiler
(welcher?) und ein -O0 den Fehler nicht ändert, konnte also keiner
wissen.
Ich müßte Dir böse sein, daß Du keinen Deiner bisherigen Lösungsversuche
mitteilst. Aber nicht Du, daß ich Sachen vorschlage, die Du bereits
ausprobiert haben willst.
Ich werd mich jetzt aber hüten, noch weitere Vorschläge zu machen.
Karlo schrieb:> Dann kann man schaun ob es wirklich der> selbe Fehler wie im von Johann L. verlinkten Bugreport ist oder ein> andrer.
Du solltes aber schon nachprüfen, ob der Fehler mit einem aktuellen gcc
auch noch auftritt. Wenn nicht, ist die ganze Aktion ohne jedes
öffenliches Interesse.
Oliver