avr-gcc: interner Compilerfehler? Was tun?

[Karlo (Gast)]

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:

unable to find a register to spill in class 'POINTER_REGS'

this is the insn:

confused by earlier errors, bailing out

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!

[Peter D. (peda)]

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.

[Rangi J. (rangi)]

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.

[Karlo (Gast)]

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.

[Klaus W. (mfgkw)]

Karlo schrieb:
> der allerdings als
> behoben gilt.

Dann nimm halt eine aktuellere Version, und gut iss.

[Peter D. (peda)]

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.

[Karlo (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Oliver (Gast)]

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

[Karl H. (kbuchegg)]

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.

[Rolf Magnus (Gast)]

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.

[Karlo (Gast)]

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

[Johann L. (gjlayde)]

Manchmal hilft -fno-caller-saves

Ist in der betroffenen Funktion oder in darin geinlinte Funktionen 
inline Assembler?

[Jörg W. (dl8dtl) (Moderator)]

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.

[Karlo (Gast)]

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.

[Johann L. (gjlayde)]

Vielleicht ist es ja der da:

http://gcc.gnu.org/PR58545

[Karlo (Gast)]

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

[(prx) A. K. (prx)]

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.

[Oliver (Gast)]

Karlo schrieb:
> Ich werd
> heut schauen dass ich mein c-File soweit abspecke, dass der Fehler immer
> noch auftritt.

Vielleicht nimmt dir das hier dabei etwas Arbeit ab:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58545

Oliver

[Oliver (Gast)]

Ich seh gerade, Johann war schon hier ;)

Oliver

[Karlo (Gast)]

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...

[Peter D. (peda)]

Karlo schrieb:
> die wohl geinlined werden.

Kann man verbieten.
Entweder:
-fno-inline-small-functions

oder:

// force no inlining:
#define NIL(x)   x __attribute__ ((noinline)); x

NIL( void foo(void) )
{
  // code
}

[Karlo (Gast)]

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

[Rolf Magnus (Gast)]

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.

[Peter D. (peda)]

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.

[Oliver (Gast)]

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