4. Compiler Optimierung deine Erfahrungen

Compiler Optimierung deine Erfahrungen

  • R

    Hallo zusammen

    Beinahe wäre ich in die Klapsmüle gekommen. Denn folgendes Problem hat mich fast um den Verstand gebracht.

    Im Debug Modus lief alles ok. Im Release Modus konnte ich das Projekt ohne Fehler Linken und Compilieren. Aber als ich das Programm ausführte führte dies immer zu einem "Access violation". Was ist das los!!?

    Nun habe ich rausgefunden, dass wenn ich die Compiler Optimierung, was standard auf schnellstmöglichen Quelltext erzeugen steht, entferne läuft das Projekt auch wieder unter Release. Bis ich das gefunden habe! 😡

    Wie ist so eure Erfahrung mit der Compiler Optimierungen?

    Gruss Renato

    0
  • Mod

    Robbiani schrieb:

    Wie ist so eure Erfahrung mit der Compiler Optimierungen?

    Sie decken häufig Programmierfehler auf. Da endet ein fehlerhaftes Programm gerne mal in einer Access violation, statt von (schlecht gemachten) Debugmodi vertuscht werden.

    0

  • Welchen Compiler benutzt du (klassisch/clang)?
    Welche IDE benutzt du (RAD Studio, C++ Builder)?

    Wir benutzen das RAD Studio 10.1 Berlin und ich bin der festen Überzeugung, dass der clang Compiler im Release Modus Mist baut. Wir hatten das schon mehrer Male, dass der Compiler fehlerhaften Code erzeugt, teilweise waren die Bugs so himmelschreiend offensichtlich, dass ich mich frage, wie die Version es durch die Qualitätskontrolle geschafft hat. Oder ob überhaupt eine Qualitätskontrolle stattfindet.

    Dummerweise habe ich mir die Cases nicht notiert oder den Quelltext gesichert, der den Fehler produziert. Muss ich unbedingt machen.

    Mal abwarten, wie es mit dem RAD Studio 10.3 wird.

    0
  • R

    Ja das habe ich ganz vergessen.

    Ich arbeite mit RAD-Studion 10.2. Das Problem trifft sowohl bei 32 wie bei 64 Bit auf.

    Gruss Renato

    0
  • ?

    Da wird dir so jetzt keiner helfen können. Du musst den Fehler genauer einkreisen. Danach können wir über Compiler-Bugs spekulieren.

    0
  • R

    Ich habe den Fehler bereits gefunden. Daher brauche ich keine Hilfe.

    Ich wollte nur eine Diskussion Starten um eure Erfahrungen mit dem Compiler-Optimierung zu erfahren. Das ist alles.

    Gruss Renato

    0

  • Dann korrigiere mal den Schreibfehler im Titel... (und zusätzlich einen etwas eingängigeren Titel wählen).

    0
  • M

    Naja, ausgehend von deiner bisherigen Beschreibung, hast du einfach zu wenig Ahnung und dein Programm ist fehlerhaft. Das hat mit Optimierungen soweit nichts zu tun, ohne Optimierungen ist die Wahrscheinlichkeit in deinem Fall einfach etwas höher, dass es zufälligerweise durchläuft. Das gibts auch andersrum, wenn das Programm im Release scheinbar ohne Probleme funktioniert, und im Debug dann crasht.

    Ansonsten sind Compiler Bugs extrem unwahrscheinlich, aber nicht unmöglich. Wir sind bei VS schon über mehrere Compilerbugs gestolpert, vor allem mit VS 2015.

    0

  • Robbiani schrieb:

    Ich wollte nur eine Diskussion Starten um eure Erfahrungen mit dem Compiler-Optimierung zu erfahren.

    Meiner Erfahrung nach optimieren moderne Compiler ziemlich gut.

    0

  • Robbiani schrieb:

    Ich habe den Fehler bereits gefunden. Daher brauche ich keine Hilfe.

    Ich wollte nur eine Diskussion Starten um eure Erfahrungen mit dem Compiler-Optimierung zu erfahren. Das ist alles.

    Gruss Renato

    Kannst du den Codeausschnitt bitte posten? Oder wenigstens beschreiben, was zu dem Fehler geführt hat? Das gibt anderen Benutzern die Möglichkeit, ihren Code auf den gleichen Fehler zu prüfen.

    0
  • ?

    Im Debug Modus lief alles ok. Im Release Modus konnte ich das Projekt ohne Fehler Linken und Compilieren. Aber als ich das Programm ausführte führte dies immer zu einem "Access violation". Was ist das los!!?

    Wo passiert denn die Access Violation? Ist der Code an der Stelle WIRKLICH 100% verifiziert in Ordnung oder du nur denkst das sollte so sein

    Nun habe ich rausgefunden, dass wenn ich die Compiler Optimierung, was standard auf schnellstmöglichen Quelltext erzeugen steht, entferne läuft das Projekt auch wieder unter Release. Bis ich das gefunden habe!

    die verschiedenen Varianten erzeugen anderen Code und haben auch andere Verhaltensweise z.B. per-default-Null Initialisierung von Variablen im bestimmten Scopes usw.

    Es ist sehr wahrscheinlich das der Fehler in dem Source zu finden ist und bisher eben nicht aufgetaucht ist - daher sind auch Multi-Kompiler/Platform Builts sehr hilfreich

    Es ist klar das Kompiler auch Fehler haben - aber man muss klar differenzieren zwischen Kompilier-, Code-Generier-Fehler - die letzteren sind böse und gefährlich und davon gibt es nicht ganz so viele

    Dein "Fix" ist eher ein karschieren des Problems

    0
  • ?

    leider ist der In-Debug-gehts-in-Release-nicht-Fehler so ein sehr typischer Anfänger(oder es wurde zu spät im Release getestet)-Fehler - unabhängig von deiner Erfahrung ist das so der Standard-Mystisch-Fehler

    deswegen sind hier einige nicht von dem Kompilerfehler überzeugt und wollen mehr über die Access Violation Stelle wissen

    Ich hab auch schon genug mit Software zu tun gehabt die nur als Debug-Built funktioniert hat und alle sich sicher waren das es ein Kompilerfehler ist - schlussendlich waren es immer haufen von nicht initialisierten Variablen - speziell Pointer die dann Random oder definiertte Abstürze verursacht haben

    Der 1. Denkfehler ist immer: Weils im Debug läuft ist alles OK

    0

  • Man sollte sich grundsätzlich angewöhnen, Zeigervariablen bereits beim Anlegen immer mit 0 zu intialisieren und am besten auch noch auf 0 setzen, wenn man den Speicher, auf den diese verweist, wieder freigibt.

    int *a = 0;

a = new int;

*a = 4711;

delete a;
a=0;
    0

  • Ohne Code ist das doch alles nur Spekulation...

    0
Anmelden zum Antworten