www.mikrocontroller.net

Forum: Compiler & IDEs Optimizer fehlerhaft?


Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
Mir ist grad beim Programmieren aufgefallen das sich ein Programm
anders verhält wenn man den Optimizer einschaltet. Ist etwas schwierig
zu erklären wo und wie das genau passiert. Aber vielleicht gibts ja
irgendwelche allgemeinen Regeln anhand derer man das nachvollziehen
kann. Vielleicht könnt ihr mir da weiterhelfen.

Gruß
Markus

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allgemeine Regeln für Probleme mit dem Optimizer? Gibt's bestimmt... zu
Tausenden.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, fang mal an aufzuzählen ;)
Spaß beiseite, hab ich vermutet. Aber wie kann ich an das Problem
rangehen ohne graue Haare zu kriegen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Optimizer sind auch nur Programme und haben als solche
Fehler.
Meistens ist es aber so, dass du irgendwelche C Regeln
verletzt hast, die sich bei einem normalen Debug-Build
nicht auswirken. Erst wenn der Optimizer loslegen darf,
treten die Fehler dann zu Tage, da der Optimizer laut
C-Sprachstandard irgendwelche Annahmen treffen darf,
die du aber ignoriert, bzw. verletzt hast.

Klassische Dinge am PC sind zb:
* Bei einem Debug Build werden zwischen den Variablen
  oft und gerne ein paar Füll-Bytes eingeschoben. Vor
  allem bei Arrays ist das häufig der Fall. Wenn du einen
  Array nur schreibend wenig überläufst, dann merkst du
  das nicht, da die illegalen Zugriffe in diesen Füll-Bytes
  stattfinden. Erst wenn bei einem optimierten Build diese
  Füll-Bytes nicht mehr da sind, verändern sich dann plötzlich
  Variablen wie von Geisterhand
* Oft übersieht man auch, dass laut Sprachstandard lokale
  Variablen nicht initialisiert werden. Bei Debug Builds
  ist es jedoch oft so, dass die Compiler die Variablen mit
  irgendeinem konstanten Wert initialisieren.

Wie schon gesagt: Klar haben auch Optimizer Fehler. Genauso wie
alle Compiler insgesammt den einen oder anderen Fehler haben.
Aber in 99% aller Fälle ist es das vom Programmierer geschriebene
Programm, und nicht der Compiler, das den eigentlichen Fehler
enthält.

Finden kannst du sowas meist nur mit einer Stufenmethode:
Kommentiere aus deinem Programm alles aus und fange bei 0 an.
Danach werden sukzessive Teilbereiche wieder aktiviert bis
sich das erste mal wieder ein Fehler zeigt. Der Fehler muss nicht
zwangsläufig im zuletzt aktivierten Bereich sein, oft ist er
es aber. Zumindest liefert aber der zuletzt aktivierte Bereich
Hinweise, wo den das eigentliche Problem sitzen könnte.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das es nicht am Optimizer selber liegt war mir schon vorher klar, aber
ich dachte mir das lesen mehr ;)

Ich habe einen Pointer deklariert, aber nicht die Größe definiert

hatte das im Programm stehen:

char* s;
itoa(*transmitData, s, 16);

trotzdem finde ich es strange das der fehler ohne optimizer weder beim
compilieren noch bei der programmausführung auftritt. ok, letzteres
kann zufall sein, aber der compiler sollte doch in beiden fällen
meckern. Ohne Optimizer ist der Compiler ohne Error oder Warning
durchmarschiert und mit Optimizer kann dann die Meldung:

warning: 's' is used uninitialized in this function

Autor: ABu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf welcher Platform willst du Kompilierten?
Bei einem MCU lohnt sich meiner Erfahrung nach immer ein Blick auf den
ASM-Code.
Ich hatte auch schon einige Fehler bei denen ich den Comiler verflucht
hab und nach dem ich den ASM-Code angeschaut hab ist mir klar geworden,
dass der Kompiler das was ich da schreibe anders Interpretiert bzw.
Sachen weckoptimiert die ich eigendlich brauch. Da kann man dann z.b.
mit valatile eingreifen.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ne, ich hab die Deklarierung jetzt in char s[2] geändert. Jetzt gehts
klaglos.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> trotzdem finde ich es strange

Dann ist C nicht deine Sprache.
Genau das sind Dinge, die ganz alleine deiner Verantwortung
obliegen.
Weder könnte der Compiler so einen Fehler in allen Fällen
zu Compile-Zeit diesen Fehler detektieren noch wird (aus
Performance-Gründen) zur Laufzeit ein Check eingebaut.
Zur Laufzeit wäre es nämlich ebenso nicht möglich dieses
Problem in allen Fällen zuverlässig zu identifizieren.
In C ist ganz einfach deine Sorgfalt als Programmierer
gefragt und C entlässt dich nicht aus dieser Verantwortung.

> Ohne Optimizer ist der Compiler ohne Error oder Warning
> durchmarschiert und mit Optimizer kann dann die Meldung

Das liegt daran, dass auf deinem Compiler erst der Optimizer eine
Datenfluss-Analyse macht und es dabei erst auffält, dass da was
nicht stimmen kann.
Was du daraus mitnehmen solltest: Warnungen ernst nehmen.
Nicht umsonst gilt bei Industrieprogrammierern: Der Code
muss in allen Optimierungsleveln, fehler- UND warnungsfrei
comililiert werden können. Oft gibt es auch externe Tools
die den Code auch noch auf häufige Programmierfehler
durchchecken. 'lint' ist ein prominentes Beispiel dafür.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C ist auch nicht wirklich meine bevorzugte Sprache. Aber man wird ja
geradezu dazu gezwungen C zu können weil es die einzige Sprache ist
(von Assembler mal abgesehen) die es für fast jedes System gibt.

Mittlerweile hab ich schon gehört das beim Compilieren ohne Optimizer
auch einige Überprüfungen weggelassen werden um die Compilierung zu
beschleunigen. Daher können also solche Unterschiede kommen.

Ich gebe zu das ich weder ein C Freak bin noch unbedingt einer werden
will, aber ich will es gut genug können um damit über die Runden zu
kommen. Desshalb pack ich es hin und wieder mal aus

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"trotzdem finde ich es strange das der fehler ohne optimizer weder beim
compilieren noch bei der programmausführung auftritt."

Die Pointer-Variable ist bei dir nicht initialisiert. Sowas merkt der
Compiler, wie du ja gesehen hast. Aber das merkt er als Nebeneffekt
einer Datenflussanalyse. Die kostet Zeit und wird eigentlich mit dem
Ziel der Optimierung durchgeführt. Folglich kommt die Meldung nur bei
eingeschalteter Optimierung.

Und dass sich solcherart fehlerhafte Programme mit und ohne Optimierung
völlig anders verhalten ist ganz normal. Ohne Optimierung landen
Variablen immer im Speicher, mit Optimierung oft im Register, was bei
fehlender Initialisierung gänzlich andere Werte zur Folge hat.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, wie gesagt. Ich hab mittlerweile erfahren das der Compiler ohne
Optimizer auch noch diverse andere Prüfungen weglässt. Man sollte also
hin und wieder mal einen Compilerlauf mit Optimizer machen um auch
solche Fehler frühzeitig zu finden

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwann machst du solch läppische Fehler von Haus aus
nicht mehr.
Denn dann hast du dir das Ritual eingelernt, dich bei einem
Pointer zuallererst mal zu fragen, ob und wo dieser Pointer
hinzeigt und wenn du das nicht mehr im Kopf hast zu überprüfen
ob mit dem Pointer alles mit rechten Dingen zugeht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man sollte also
> hin und wieder mal einen Compilerlauf mit Optimizer machen um auch
> solche Fehler frühzeitig zu finden

Meine ganz persönliche Meinung: man sollte immer mit Optimizer
compilieren, andernfalls debugst du einen komplett anderen
Maschinencode und debugst daher effektiv zweimal.  Gewöhn dich
stattdessen an die Artefakte der Optimierung (Variablen leben
nicht mehr über die gesamte Lebensdauer einer Funktion bzw.
wenn sie in Registern leben, werden diese anders wiederbelegt;
Der Programmablauf kann ,,springen'', da der Compiler Code
anders sortieren darf; nicht [mehr] benötigte Ergebnisse werden
auch nirgends mehr gespeichert) und debugge gleich das Endergebnis.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"man sollte immer mit Optimizer compilieren"

Bei GCC/ARM nicht uneingeschränkt zu empfehlen. Der Optimizer
reorganisiert den Code derart, dass man bei Source-Code-Debugging
bisweilen wild im Quellcode herumspringt.

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist etwas Offtopic,aber naja...

Was ist mit dem aktuellen DevC++ für Windows?Eigentlich eine prima
Sache,nur leider ist es scheinbar nicht möglich einen Final-Build ohne
Debug-Infos zu machen.Die Einstellungen der IDE bezüglich Debuginfo
einbinden ignoriert das System scheinbar und wenn man den
Compiler/Linker von der Commandozeile aufruft das selbe.Ein kleines
Programm ist immer >450kb gross.Und selbst nach einem Strip-Durchlauf
ist die Exe noch 2xxKB gross.

Unter VC 6.0 konnte man immerhin ein Fenster mit einer 4kb Exe-Datei
erzeugen (mit etwas Linker-Tuning)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Optimizer
> reorganisiert den Code derart, dass man bei Source-Code-Debugging
> bisweilen wild im Quellcode herumspringt.

Logisch, RISC halt.  Deshalb ja auch mein "Get used to it.".  Du
debuggst eben sonst wirklich etwas völlig anderes, und damit
ist die Sache ziemlich wertlos.

Been there, done that.  Motorola m88k.  Auch eine echte RISC-
Maschine.  Da hüpfte der Zeiger im Emacs auch nur so auf und
ab im Quellcode.  Man gewöhnt sich dran, wenn man einmal weiß,
wie das zusammenhängt.  (In diesem Fall dürfte es das Ineinander-
schachteln von Speicher- und Registeroperationen sein, da ein
RISC-Prozessor typisch locker während eines Speicherzyklus noch
eine komplette Registerrechnung mit abarbeiten kann.)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.