Hi da. Habe ab und an das Problem das mein WinAVR z.B. if/then Konstrukte weg optimiert obwohl er es nicht sollte. Beispiel habe ich gerade nicht zur Hand, da keine Zeit um einen Code so umzuschreiben das es veröffentlichbar und zugleich ersichtlich ist. Ich denke das Problem hatten schon einige das plötzlich was nicht mehr funktionierte und ein Zweig nicht mehr assembliert wurde. Da es mich so langsam nervt irgendwelche Funktionen in einzelne .c Dateien zu extrahieren die ich nicht optimieren lasse suche ich derzeit nach einer Lösung für das Problem. Wie sieht es denn bei Codevision oder IAR in dem Falle aus? Funktioniert es da besser? Evtl. kann das ja jemand beantworten. Gruß Björn
Gast
#2516016
Du schiebst da etwas auf einen Compilerfehler was du 99.9% dein Fehler ist. Wenn sich das Verhalten deines Programms wegen der Optimierung ändert sind das entweder Timingprobleme, Nachlässigkeit mit volatile oder Stack oder Heap-Speicher-Schweinereien. If/else wird nicht wegoptimiert, wenn es nicht wegoptimiert werden kann.
Gast
#2516030
Björn G. schrieb: > Da es mich so langsam nervt irgendwelche Funktionen in einzelne .c > Dateien zu extrahieren die ich nicht optimieren lasse suche ich derzeit > nach einer Lösung für das Problem. Du solltest in dem "wegoptimierten" Zweig halt auch etwas tun, was Einfluß auf die weitere Programmausführung hat.
Björn G. schrieb: > Da es mich so langsam nervt irgendwelche Funktionen in einzelne .c > Dateien zu extrahieren die ich nicht optimieren lasse suche ich derzeit > nach einer Lösung für das Problem. Die Lösung ist, herauszufinden, welchen Fehler du machst und ihn zu beheben. Der Compiler optimiert nicht einfach so Sachen weg, die benötigt werden. > Wie sieht es denn bei Codevision oder IAR in dem Falle aus? > Funktioniert es da besser? Es funktioniert auch bei GCC sehr gut, daher liegt die Vermutung nahe, daß du etwas falsch machst. Ohne ein Beispiel wird dir aber keiner sagen können, was der konkrete Fehler ist.
Björn G. schrieb: > Wie sieht es denn bei Codevision oder IAR in dem Falle aus? > Funktioniert es da besser? Vielleicht funktioniert den Code damit weil diese Compiler weniger optimieren. Aber dadurch wird dein Code nicht korrekt: Du verschiebst das Problem nur nach hinten anstatt es zu lösen. Löse das Problem, um es los zu werden. Verschiebe es nicht an eine andere Stelle. > Evtl. kann das ja jemand beantworten. Beachte Warnungen des Compilers und schreibe robusten Code. Was zählt, ist der Code, der ausgeführt wird und nicht der Code, den irgendein Debugger anzeigt oder nicht anzeig, siehe [[Compilerfehler#Die häufigsten Nicht-Fehler]]. Mir ist kein Fehler im WinAVR bekannt, der zur kompletten, unerlaubten Entfernung eines if-else Zweiges führt. Ist der Code wirklich weg? Oder wird er nur nicht ausgeführt? Mit Code meine ich auch Code und nicht irgendne mehr oder weniger sinnfreie Debugger-Ansicht.
Gast
#2516388
Björn G. schrieb: > Habe ab und an das Problem das mein WinAVR z.B. if/then Konstrukte weg > optimiert obwohl er es nicht sollte. Was ist denn "dein" WinAVR? Ansonsten wurde schon alles gesagt. avr-gcc optimiert keine if/the-Konstrukte weg, die nachweislich durchlaufen werden müssen, um das zu tun, was im Programm steht. Punkt. Oliver
Der AVR-GCC optimiert gnadenlos mehrfache Einlesungen derselben Variable weg, wenn diese nicht volatile definiert ist. Z.B. wenn Dein if/else in einer Schleife erfolgt. Peter
Gast
#2516626
Peter Dannegger schrieb: > Der AVR-GCC optimiert gnadenlos mehrfache Einlesungen derselben Variable > weg, wenn diese nicht volatile definiert ist. wozu er auch berechtigt ist, denn so wurde es ihm ja erklärt.
Peter Dannegger schrieb: > Der AVR-GCC optimiert gnadenlos [...] weg Übersetzung "gnadenlos": Der Compiler übersetzt den Code so, daß das Ergebnis den Erfordernissen des C-Standards und der Implementierung entspricht. Die Implementierung (hier avr-gcc) legt Dinge fest, die im Standard "Implementation defined" sind, wie etwa die Größe des Typs int.
Gast
#2516798
Björn G. schrieb: > Ich denke das Problem hatten schon einige das plötzlich was nicht mehr > funktionierte und ein Zweig nicht mehr assembliert wurde. Um das noch zu beantworten: Nein. Oliver
Björn G. schrieb: > Hi da. > > Habe ab und an das Problem das mein WinAVR z.B. if/then Konstrukte weg > optimiert obwohl er es nicht sollte. > Beispiel habe ich gerade nicht zur Hand, da keine Zeit um einen Code so > umzuschreiben das es veröffentlichbar und zugleich ersichtlich ist. Um die Beiträge der anderen mal etwas deutlicher auszudrücken: Bring und ein Beispiel bei dem das wirklich der Fall ist, damit der Fehler im Compiler ausgemerzt werden kann - bedenke dabei, die angesprochenen Punkte: Dein Code muss natürlich (nach C-Standard) auch das tun können, was du von ihm verlangst...
Gast
#2522511
Björn G. schrieb: > Wie sieht es denn bei Codevision oder IAR in dem Falle aus? Um das auch noch zu beantworten: Wenn du von diesen die kommerzielle Version gekauft hast, dann kannst du solche Fragen dem dortigen Support stellen. Die beantworten das dann professionell ;) Oliver
Björn G. schrieb: > Ich denke das Problem hatten schon einige das plötzlich was nicht mehr > funktionierte und ein Zweig nicht mehr assembliert wurde. Ja, das passiert schonmal. In der Regel ist das dann ein logischer Fehler, z.B. ein Ausdruck ist immer wahr oder immer falsch. Also einfach nochmal den wegoptimierten Teil gründlich anschauen, dann merkt man schnell seinen Fehler. Z.B. ein | an einer Stelle, wo ein & hin sollte. Ich nutze das manchmal sogar aus, um Code zeitweise zu löschen.
1 | |
entfernt den Test und führt den if-Zweig immer aus (der else-Zweig wird auch gelöscht). Bzw. umgekehrt:
1 | |
Das fehlende volatile löscht den Code auch nur dann, wenn das Verschieben vor die Schleife immer wahr bzw. immer falsch ergibt. Peter