Ist es möglich, eine eingeschaltete Compiler-Optimierung oder Debug-Informationen im C-Präprozessor zu erkennen? Die Idee ist, abhängig von der Compilereinstellung den C-Code zu modifizieren, um z.B. Verzögerungsschleifen zu korrigieren, die sich durch Optimierung oder Wegfall von Debug-Infos verändern.
Gast
#3621161
F. P. schrieb: > Die Idee ist, abhängig von der Compilereinstellung den C-Code zu > modifizieren, um z.B. Verzögerungsschleifen zu korrigieren, die sich > durch Optimierung oder Wegfall von Debug-Infos verändern. Die Idee ist nicht gut.
In deinem Ansatz ist der Wurm drin. Zwar kannst du per #ifdef __OPTIMIZE__ oder #ifdef __OPTIMIZE_SIZE__ abtesten, ob Optimierung (auf Größe) aktiviert ist, aber wenn du das brauchst, hast du vermutlich einen Denkfehler im Programm. Erzeugen / Nichterzeugen von Debug-Information wird niemals den von GCC erzeugten Code verändern, d.h. -g2, -gdwarf-3, -g0, -gstrict-dwarf etc. wirkt sich nicht auf den Code aus -- falls doch, ist es ein Bug im GCC.
Schau doch mal bei http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html nach, ob da nicht was passendes für dich ist.
Johann L. schrieb: > #ifdef __OPTIMIZE__ Danke, danach habe ich gesucht!
Ich empfehle, nicht abhängig von Compileroptionen am Code zu ändern, sondern durch #pragma die Compileroptionen zu unterdrücken bzw. so einzustellen, dass der Code korrekt läuft. Beispiel:
1 | |
siehe auch: http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html
Gast
#3621385
F. P. schrieb: > Die Idee ist, abhängig von der Compilereinstellung den C-Code zu > modifizieren, um z.B. Verzögerungsschleifen zu korrigieren Du willst also, das was die Compiler-Optimierung in deinem Code "kaputt" macht, wieder korrigieren... Das Problem sitzt an einer ganz anderen Stelle, nämlich hier: F. P. schrieb: > Verzögerungsschleifen