GCC - Probleme beim optimiert kompilieren
Hallo Liste! Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren. Habe hier eine C++-Datei (2800 Zeilen, 2 große und ca. 15 kleine Funktionen), die sich mit -g wunderbar übersetzen läßt, sobald ich sie aber optimiert übersetzen will, scheitert das (Sowohl mit -O als auch mit -O2). Der Compiler rödelt ewig lange darum, verbraucht immer mehr Speicher und bricht irgendwann ab, weil es keinen Speicher mehr gibt (meine Kiste hat 512 MB + 256 MB Swap). Das ganze ist deshalb so störend, weil die Datei zu einem großen Projekt gehört, wenn ich das optimiert übersetzen will, muß ich den Compiler für das eine Objektfile immer gesondert mit -g aufrufen. Die Routine, wegen der das optimierte Übersetzen scheitert, ist eine Einleseroutine, mit der ein bestimmtes Dateiformat eingelesen werden kann. Zur Verwaltung werden komplexe Datenstrukturen angelegt (Mehrere Maps, sowas wie vector< vector<string*> > etc. ) Kann das ein Problem sein? Bin für Tips dankbar. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Hallo Christoph, Christoph Maurer wrote:
Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren.
Wuerde ich von mir jetzt nicht gerade behaupten, trotzdem eine kurze Antwort von mir auf diese Mail.... :-)
Habe hier eine C++-Datei (2800 Zeilen, 2 große und ca. 15 kleine Funktionen), die sich mit -g wunderbar übersetzen läßt, sobald ich sie aber optimiert übersetzen will, scheitert das (Sowohl mit -O als auch mit -O2). [...]
Ein aehnliches Phaenomen hatte ein Kollege von mir hier am Institut auch schon. Der Code war mit Debugging Flag und auch unoptimiert ohne Probleme zu compilieren, mit Optimierung jedoch ging gar nichts mehr. Das Problem damals waren IIRC verkettete Listen. Er hat das Problem dann mehr oder weniger durch Ausprobieren geloest, sprich: irgendwie muss man he- rausfinden, welcher Teil des Quellcodes beim Optimieren Aerger macht und den dann noetigenfalls abaendern. Das Ganze ist glaube ich eine Wissenschaft fuer sich, ob es da eine allgemeine Herangehensweise gibt, weiss ich nicht. An einer Loesung oder Strategie, das Problem systematisch einzugren- zen, waere ich daher auch interessiert. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH) Hertzstr. 16, D-76187 Karlsruhe, Germany
On Don, 2001-09-13 at 11:50, Thomas Hertweck wrote:
Hallo Christoph,
Christoph Maurer wrote:
Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren.
Wuerde ich von mir jetzt nicht gerade behaupten, trotzdem eine kurze Antwort von mir auf diese Mail.... :-) Dito :)
Ich kenn mich zwar einigermassen mit gcc/g++ aus, doch von den Optimizern habe ich nur wenig Ahnung :(
Habe hier eine C++-Datei (2800 Zeilen, 2 große und ca. 15 kleine Funktionen), die sich mit -g wunderbar übersetzen läßt, sobald ich sie aber optimiert übersetzen will, scheitert das (Sowohl mit -O als auch mit -O2). [...]
Ein aehnliches Phaenomen hatte ein Kollege von mir hier am Institut auch schon. Der Code war mit Debugging Flag und auch unoptimiert ohne Probleme zu compilieren, mit Optimierung jedoch ging gar nichts mehr. Das Problem damals waren IIRC verkettete Listen. Das ist allenfalls der Auslöser nicht aber die Ursache. Die eigentliche Ursache sind Bugs im Compiler. Wo ist nur schwer zu sagen.
Er hat das Problem dann mehr oder weniger durch Ausprobieren geloest, sprich: irgendwie muss man he- rausfinden, welcher Teil des Quellcodes beim Optimieren Aerger macht und den dann noetigenfalls abaendern. Das Ganze ist glaube ich eine Wissenschaft fuer sich, ob es da eine allgemeine Herangehensweise gibt, weiss ich nicht. An einer Loesung oder Strategie, das Problem systematisch einzugren- zen, waere ich daher auch interessiert. Der einzig systematische Weg wäre gcc zu debuggen.
Um Fehler im Compiler einzugrenzen hilft es meist mit Compilerflags zu spielen. Um Workarounds zu finden, hilft einzig Erfahrung und die gcc und binutils Listen zu verfolgen (Was ich jedem, der ernsthaft SW mit gcc und binutils entwickelt, nur dringend nahelegen kann). Um die Auslöser im Quellcode zu finden, ist es sehr hilfreich, betroffenen Code erst "präprozess-ieren" zu lassen (gcc -P -E) und anschliessend getrennt zu übersetzen. Man kann dann oft durch systematisches Löschen von Code im "präprozessierten" Code oft ein minimiertes Beispiel konstruieren, dass es dann entweder erlaubt, einen Workaround zu finden, oder aber den gcc-Spezialisten hilft einen Bug einzukreisen. Im speziellen Fall (komplexe C++-Templates) hilft es oft typedefs, typename oder Klassen zu benutzen, statt kaskadierte Templates zu verwenden. Ansonsten gibt es bei allen gcc Versionen bekannte Fehler. Hier hilft oft ein Blick in die Archive der gcc und binutils Listen. Von gcc-2.95.x ist auch bekannt, dass er, was c++ angeht, zwar deutlich besser als seine Vorgänger ist, doch aber an einigen Stellen (insb. Templates und Namespaces) in Einzelfällen heftige Probleme hat. Das war übrigens auch mit ein Grund, warum RH bei RH-7.x eine inoffizielle, auf damals aktuelle gcc-Entwicklerversionen aufsetzende pre-3.0 Version (jetzt gcc-2.96 genannt) zu verwenden, da die RH-Leute den gcc-2.95.x damals als inakzeptabel empfanden. Die gleichen Probleme mit gcc-2.* waren auch ein Grund, warum gcc-3 entwickelt wurde, der, was den C++ Support angeht, gcc-2.* weit überlegen ist, nur in der Summe (insb auf Nicht-ix86-Architekturen) noch reichlich unausgereift ist. Für aktuelle Entwicklungen unter Linux ist er allerdings durchaus brauchbar (Ich verwende ihn selbst :)) Ralf
Am Don, 13 Sep 2001, schrieb Ralf Corsepius:
On Don, 2001-09-13 at 11:50, Thomas Hertweck wrote:
Hallo Christoph,
Christoph Maurer wrote:
Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren.
Wuerde ich von mir jetzt nicht gerade behaupten, trotzdem eine kurze Antwort von mir auf diese Mail.... :-) Dito :)
Ich kenn mich zwar einigermassen mit gcc/g++ aus, doch von den Optimizern habe ich nur wenig Ahnung :(
Habe hier eine C++-Datei (2800 Zeilen, 2 große und ca. 15 kleine Funktionen), die sich mit -g wunderbar übersetzen läßt, sobald ich sie aber optimiert übersetzen will, scheitert das (Sowohl mit -O als auch mit -O2). [...]
Ein aehnliches Phaenomen hatte ein Kollege von mir hier am Institut auch schon. Der Code war mit Debugging Flag und auch unoptimiert ohne Probleme zu compilieren, mit Optimierung jedoch ging gar nichts mehr. Das Problem damals waren IIRC verkettete Listen. Das ist allenfalls der Auslöser nicht aber die Ursache. Die eigentliche Ursache sind Bugs im Compiler. Wo ist nur schwer zu sagen.
Er hat das Problem dann mehr oder weniger durch Ausprobieren geloest, sprich: irgendwie muss man he- rausfinden, welcher Teil des Quellcodes beim Optimieren Aerger macht und den dann noetigenfalls abaendern. Das Ganze ist glaube ich eine Wissenschaft fuer sich, ob es da eine allgemeine Herangehensweise gibt, weiss ich nicht. An einer Loesung oder Strategie, das Problem systematisch einzugren- zen, waere ich daher auch interessiert. Der einzig systematische Weg wäre gcc zu debuggen.
Um Fehler im Compiler einzugrenzen hilft es meist mit Compilerflags zu spielen.
Gibt es irgendwo eine Liste, welche Flags auf i386 für welche Optimierungsstufe verwendet werden. Bei gcc.gnu.org stehen z.B. für -O ein paar Optionen, dann der Hinweis, daß auf einigen Maschinen auch noch andere Optionen verwendet werden. Das ist bei mir offensichtlich der Fall, da mein Sourcecode mit den aufgelisteten, zu -O gehörenden Flags kompiliert, mit -O aber nicht.
Um Workarounds zu finden, hilft einzig Erfahrung und die gcc und binutils Listen zu verfolgen (Was ich jedem, der ernsthaft SW mit gcc und binutils entwickelt, nur dringend nahelegen kann).
Wieviel geht denn da an Traffic drüber?
Um die Auslöser im Quellcode zu finden, ist es sehr hilfreich, betroffenen Code erst "präprozess-ieren" zu lassen (gcc -P -E) und anschliessend getrennt zu übersetzen. Man kann dann oft durch systematisches Löschen von Code im "präprozessierten" Code oft ein minimiertes Beispiel konstruieren, dass es dann entweder erlaubt, einen Workaround zu finden, oder aber den gcc-Spezialisten hilft einen Bug einzukreisen.
Im speziellen Fall (komplexe C++-Templates) hilft es oft typedefs, typename oder Klassen zu benutzen, statt kaskadierte Templates zu verwenden.
Ansonsten gibt es bei allen gcc Versionen bekannte Fehler. Hier hilft oft ein Blick in die Archive der gcc und binutils Listen.
Kannst Du mir sagen, wo die gehostet werden? Wenn Du es gerade weißt, sonst suche ich selbst...
Für aktuelle Entwicklungen unter Linux ist er allerdings durchaus brauchbar (Ich verwende ihn selbst :))
Das ist interessant, gibt es spürbare Auswirkungen auf die Performance? Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Don, 13 Sep 2001, schrieb Christoph Maurer:
Am Don, 13 Sep 2001, schrieb Ralf Corsepius:
On Don, 2001-09-13 at 11:50, Thomas Hertweck wrote:
Christoph Maurer wrote:
Habe hier eine C++-Datei (2800 Zeilen, 2 große und ca. 15 kleine Funktionen), die sich mit -g wunderbar übersetzen läßt, sobald ich sie aber optimiert übersetzen will, scheitert das (Sowohl mit -O als auch mit -O2). [...] [...] [...] Er hat das Problem dann mehr oder weniger durch Ausprobieren geloest, sprich: irgendwie muss man he- rausfinden, welcher Teil des Quellcodes beim Optimieren Aerger macht und den dann noetigenfalls abaendern. Das Ganze ist glaube ich eine Wissenschaft fuer sich, ob es da eine allgemeine Herangehensweise gibt, weiss ich nicht. An einer Loesung oder Strategie, das Problem systematisch einzugren- zen, waere ich daher auch interessiert. Der einzig systematische Weg wäre gcc zu debuggen.
Um Fehler im Compiler einzugrenzen hilft es meist mit Compilerflags zu spielen.
Gibt es irgendwo eine Liste, welche Flags auf i386 für welche Optimierungsstufe verwendet werden. Bei gcc.gnu.org stehen z.B. für -O ein paar Optionen, dann der Hinweis, daß auf einigen Maschinen auch noch andere Optionen verwendet werden.
Das ist bei mir offensichtlich der Fall, da mein Sourcecode mit den aufgelisteten, zu -O gehörenden Flags kompiliert, mit -O aber nicht.
Okay, das habe ich gefunden, wenn man als Output Assembler-Code produziert (mit -S) und dann mit -fverbose-asm kompiliert, werden im Output-File die Optionen gelistet. In meinem Fall: # GNU C++ version 2.95.2 19991024 (release) (i486-suse-linux) # compiled by GNU C version 2.95.2 19991024 (release). # options passed: -O -Wall -fverbose-asm -fPIC # options enabled: -fdefer-pop -fthread-jumps -fpeephole # -ffunction-cse # -finline -fkeep-static-consts -fpcc-struct-return -fPIC # -fexceptions # -fcommon -fverbose-asm -fgnu-linker -fargument-alias -fident # -m80387 # -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387 # -mschedule-prologue -mcpu=i486 -march=pentium Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On Don, 2001-09-13 at 13:47, Christoph Maurer wrote:
Am Don, 13 Sep 2001, schrieb Ralf Corsepius:
On Don, 2001-09-13 at 11:50, Thomas Hertweck wrote:
Hallo Christoph,
Christoph Maurer wrote:
Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren.
Wuerde ich von mir jetzt nicht gerade behaupten, trotzdem eine kurze Antwort von mir auf diese Mail.... :-) Dito :)
Ich kenn mich zwar einigermassen mit gcc/g++ aus, doch von den Optimizern habe ich nur wenig Ahnung :(
Der einzig systematische Weg wäre gcc zu debuggen.
Um Fehler im Compiler einzugrenzen hilft es meist mit Compilerflags zu spielen.
Gibt es irgendwo eine Liste, welche Flags auf i386 für welche Optimierungsstufe verwendet werden. In gcc.info und im gcc-Quellcode ;)
Bei gcc.gnu.org stehen z.B. für -O ein paar Optionen, dann der Hinweis, daß auf einigen Maschinen auch noch andere Optionen verwendet werden. Ja, die Target-spezifischen.
Diese sind im Quellcode meist in gcc/config/i386/+ zu finden.
Das ist bei mir offensichtlich der Fall, da mein Sourcecode mit den aufgelisteten, zu -O gehörenden Flags kompiliert, mit -O aber nicht. Du kennt gcc -v? Du siehst dann, welche Optionen verwendet werden.
Um Workarounds zu finden, hilft einzig Erfahrung und die gcc und binutils Listen zu verfolgen (Was ich jedem, der ernsthaft SW mit gcc und binutils entwickelt, nur dringend nahelegen kann).
Wieviel geht denn da an Traffic drüber? Meist 10-50 Mails/Tag, aber deutlich weniger als auf der SuSE oder der Kernel-Liste. Das meiste ist allerdings derart speziell, dass es sich meist auf weniger als 2 interessante Mails/Tag reduziert.
Um die Auslöser im Quellcode zu finden, ist es sehr hilfreich, betroffenen Code erst "präprozess-ieren" zu lassen (gcc -P -E) und anschliessend getrennt zu übersetzen. Man kann dann oft durch systematisches Löschen von Code im "präprozessierten" Code oft ein minimiertes Beispiel konstruieren, dass es dann entweder erlaubt, einen Workaround zu finden, oder aber den gcc-Spezialisten hilft einen Bug einzukreisen.
Im speziellen Fall (komplexe C++-Templates) hilft es oft typedefs, typename oder Klassen zu benutzen, statt kaskadierte Templates zu verwenden.
Ansonsten gibt es bei allen gcc Versionen bekannte Fehler. Hier hilft oft ein Blick in die Archive der gcc und binutils Listen.
Kannst Du mir sagen, wo die gehostet werden?
Bei RH ;) Einsprungadressen sollten sich über http://sources.redhat.com, aka. http://sourceware.cygnus.com http://gcc.gnu.org und http://www.gnu.org finden lassen.
Wenn Du es gerade weißt, sonst suche ich selbst... Wo die Archive liegen habe ich gerade nicht parat (Sie haben desöfteren zwischen RH und der FSF gewandert.)
Für aktuelle Entwicklungen unter Linux ist er allerdings durchaus brauchbar (Ich verwende ihn selbst :))
Das ist interessant, gibt es spürbare Auswirkungen auf die Performance? Das ist z.Zt. ein heisses Thema: Stark vereinfacht: Einige.
Die C++-Übersetzungszeiten mit gcc-3.0.x liegen in der Regel deutlich über denen von gcc-2.95.x (Typischerweise Faktor 2-10), die Laufzeitperformance variiert stark, liegt meist aber in der gleichen Größenordnung wie bei gcc-2.95.x, die Größe generierter Objs liegt auch oft deutlich über denen von gcc-2.95.x generierte Objs. Hauptproblem ist aber die C++-ABI-Inkompatibilität zu allen anderen g++-Versionen (==Binär inkompatibel; Problem: KDE/Qt). Hauptvorteil bez. C++ ist die wesentlich bessere Unterstützung der stl, neuer C++-Standards und auch allgemein bessere C++-Unterstütztung. Leider haben aber auch damit einige existierende C++-Libs heftige Probleme (z.B.: KDE/Qt). Ralf
Am Don, 13 Sep 2001, schrieb Ralf Corsepius:
On Don, 2001-09-13 at 13:47, Christoph Maurer wrote:
Am Don, 13 Sep 2001, schrieb Ralf Corsepius:
On Don, 2001-09-13 at 11:50, Thomas Hertweck wrote:
Hallo Christoph,
Christoph Maurer wrote:
Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren.
Wuerde ich von mir jetzt nicht gerade behaupten, trotzdem eine kurze Antwort von mir auf diese Mail.... :-) Dito :)
Ich kenn mich zwar einigermassen mit gcc/g++ aus, doch von den Optimizern habe ich nur wenig Ahnung :(
Der einzig systematische Weg wäre gcc zu debuggen.
Um Fehler im Compiler einzugrenzen hilft es meist mit Compilerflags zu spielen.
Gibt es irgendwo eine Liste, welche Flags auf i386 für welche Optimierungsstufe verwendet werden. In gcc.info und im gcc-Quellcode ;)
Quellcode ist klar, gcc.info ist da nicht sehr detailliert,
Bei gcc.gnu.org stehen z.B. für -O ein paar Optionen, dann der Hinweis, daß auf einigen Maschinen auch noch andere Optionen verwendet werden. Ja, die Target-spezifischen.
Diese sind im Quellcode meist in gcc/config/i386/+ zu finden.
Das ist bei mir offensichtlich der Fall, da mein Sourcecode mit den aufgelisteten, zu -O gehörenden Flags kompiliert, mit -O aber nicht. Du kennt gcc -v? Du siehst dann, welche Optionen verwendet werden.
Eben nicht (zumindest nicht g++ -v), aber ich habe es ja gefunden (siehe andere Mail) Ich komme dem Problem übrigens näher, es liegt wohl an der zu großen Zahl von inline-Funktionen (die wohl aus der STL und der extensiven Benutzung von Template-Konstrukten in besagte Routine rühren). Kann das File auf jeden Fall mit -O2 -fno-inline bzw. -O -finline-limit-1000 kompilieren. Jetzt suche ich noch nach einer Möglichkeit, das irgendwie über eine Direktive oder so einzustellen, da das Makefile mit Makros arbeitet und automatisch generiert wird und ich deshalb keine direkte Möglichkeit habe, die Compiler-Flags für diese eine Datei zu übergeben, will andererseits auch nicht durchgängig mit no-inline arbeiten (inline-limit-1000 wäre vielleicht ok)
Um Workarounds zu finden, hilft einzig Erfahrung und die gcc und binutils Listen zu verfolgen (Was ich jedem, der ernsthaft SW mit gcc und binutils entwickelt, nur dringend nahelegen kann).
Wieviel geht denn da an Traffic drüber? Meist 10-50 Mails/Tag, aber deutlich weniger als auf der SuSE oder der Kernel-Liste. Das meiste ist allerdings derart speziell, dass es sich meist auf weniger als 2 interessante Mails/Tag reduziert.
Okay, das werde ich mir dann mal antun Vielen Dank Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Ralf Corsepius wrote:
[Erklaerungen zu gcc, Optimierproblemen und Compiler Bugs]
Vielen Dank fuer die Erklaerungen.
Die gleichen Probleme mit gcc-2.* waren auch ein Grund, warum gcc-3 entwickelt wurde, der, was den C++ Support angeht, gcc-2.* weit überlegen ist, nur in der Summe (insb auf Nicht-ix86-Architekturen) noch reichlich unausgereift ist.
Mal ne bloede Frage am Rande: Um den Compiler von gcc 3.01 zu bekommen, muss ich Quellcode compilieren, d.h. ich brauche einen funktionierenden Compiler. Ist das nicht eine Art Re- kursion, wenn ich einen Compiler brauche, um einen Compiler zu erstellen? Wie sah denn dann der erste Compiler aus? Das kann ja dann doch kein Quellcode gewesen sein, der uebersetzt werden musste, oder? Aeh, ja, vielleicht steh ich auch grade nur auf dem Schlauch. CU, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH) Hertzstr. 16, D-76187 Karlsruhe, Germany
Am Don, 13 Sep 2001, schrieb Thomas Hertweck:
Ralf Corsepius wrote:
[Erklaerungen zu gcc, Optimierproblemen und Compiler Bugs]
Vielen Dank fuer die Erklaerungen. Dem kann ich mich nur anschließen.
Die gleichen Probleme mit gcc-2.* waren auch ein Grund, warum gcc-3 entwickelt wurde, der, was den C++ Support angeht, gcc-2.* weit überlegen ist, nur in der Summe (insb auf Nicht-ix86-Architekturen) noch reichlich unausgereift ist.
Mal ne bloede Frage am Rande: Um den Compiler von gcc 3.01 zu bekommen, muss ich Quellcode compilieren, d.h. ich brauche einen funktionierenden Compiler. Ist das nicht eine Art Re- kursion, wenn ich einen Compiler brauche, um einen Compiler zu erstellen? Wie sah denn dann der erste Compiler aus? Das kann ja dann doch kein Quellcode gewesen sein, der uebersetzt werden musste, oder? Aeh, ja, vielleicht steh ich auch grade nur auf dem Schlauch.
Das wird so ähnlich sein, wie beim Booten (okay, seltsamer Vergleich, aber im Prinzip müsste es stimmen). Du hast ein winziges Programm, das nichts anderes kann, als ein etwas fähigeres Programm anzustoßen usw. Der "erste" Compiler wird direkt in Maschinensprache geschrieben worden sein, und ein etwas fähigeres Programm erzeugt haben usw. Aber irgendwann muß es mal mit Maschinensprache losgegangen sein. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On Don, 2001-09-13 at 14:03, Christoph Maurer wrote:
Am Don, 13 Sep 2001, schrieb Thomas Hertweck:
Ralf Corsepius wrote:
[Erklaerungen zu gcc, Optimierproblemen und Compiler Bugs]
Vielen Dank fuer die Erklaerungen. Dem kann ich mich nur anschließen.
Die gleichen Probleme mit gcc-2.* waren auch ein Grund, warum gcc-3 entwickelt wurde, der, was den C++ Support angeht, gcc-2.* weit überlegen ist, nur in der Summe (insb auf Nicht-ix86-Architekturen) noch reichlich unausgereift ist.
Mal ne bloede Frage am Rande: Um den Compiler von gcc 3.01 zu bekommen, muss ich Quellcode compilieren, d.h. ich brauche einen funktionierenden Compiler. Ist das nicht eine Art Re- kursion, wenn ich einen Compiler brauche, um einen Compiler zu erstellen? Wie sah denn dann der erste Compiler aus? Das kann ja dann doch kein Quellcode gewesen sein, der uebersetzt werden musste, oder? Aeh, ja, vielleicht steh ich auch grade nur auf dem Schlauch.
Das wird so ähnlich sein, wie beim Booten (okay, seltsamer Vergleich, aber im Prinzip müsste es stimmen). Der Fachbegriff lautet "Bootstrappen" :)
Du hast ein winziges Programm, das nichts anderes kann, als ein etwas fähigeres Programm anzustoßen usw.
Der "erste" Compiler wird direkt in Maschinensprache geschrieben worden sein, und ein etwas fähigeres Programm erzeugt haben usw.
Aber irgendwann muß es mal mit Maschinensprache losgegangen sein. Irgendwann in grauer Vergangenheit vermutlich schon, doch zum "Bootstrappen" des gcc wird mindestens ein installierter KnR-cc benötigt. Auf Linux halt ein älterer gcc :)
Siehe auch ftp://ftp.suse.com/pub/people/aj Ralf
On Don, 2001-09-13 at 09:53, Christoph Maurer wrote:
Hallo Liste!
Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren.
Habe hier eine C++-Datei (2800 Zeilen, 2 große und ca. 15 kleine Funktionen), die sich mit -g wunderbar übersetzen läßt, sobald ich sie aber optimiert übersetzen will, scheitert das (Sowohl mit -O als auch mit -O2). Der Compiler rödelt ewig lange darum, verbraucht immer mehr Speicher und bricht irgendwann ab, weil es keinen Speicher mehr gibt (meine Kiste hat 512 MB + 256 MB Swap). Mit hoher Wahrscheinlichkeit ein Compilerbug.
Das ganze ist deshalb so störend, weil die Datei zu einem großen Projekt gehört, wenn ich das optimiert übersetzen will, muß ich den Compiler für das eine Objektfile immer gesondert mit -g aufrufen.
Die Routine, wegen der das optimierte Übersetzen scheitert, ist eine Einleseroutine, mit der ein bestimmtes Dateiformat eingelesen werden kann. Zur Verwaltung werden komplexe Datenstrukturen angelegt (Mehrere Maps, sowas wie vector< vector<string*> > etc. ) Kann das ein Problem sein? Halte ich für unwahrscheinlich.
Zwar ist vector<vector<string*>> durchaus diskutabel und auch zur Laufzeit nicht unproblematisch, sollte aber normalerweise nicht zu derartigen Compilerproblemen führen. Für wahrscheinlicher halte ich, dass entweder (a) ein Konstrukt (Rekursion in Templates?) in deinem Code einen Bug im Compiler triggert. oder (b) der Compiler tatsächlich extrem viel Speicher zur Übersetzung benötigt (-funroll-loops ?). Beides dürfte auf Compilerbugs hindeuten. Wenn Du einen gcc < 2.95.2 einsetzen solltest, würde ich vor weiteren Schritten auf jeden Fall auf mindestens 2.95.2 upgraden. Solltest Du gcc >= 2.95.2 einsetzen, würde ich erst einmal versuchen, mit --pedantic zu übersetzen, um Code-Fehler auf deiner Seite weitgehend ausschliessen zu können. Es wäre auch sinnvoll mit verschiedenen Optierungsoptionen zu übersetzen (Möglicherweise ist eine einzelne in -O2/-O enthaltene Optimierung die Ursache). Hilft auch das nicht weiter, würde es sich anbieten mal 2.95.3 < gcc < 3.0 oder gcc >= 3.0.1 auszuprobieren. Hilft auch das nicht, wäre ein bug-report (Siehe http://gcc.gnu.org) oder Debugging des Compilers fällig. Ralf
Hallo Ralf! Am Don, 13 Sep 2001, schrieb Ralf Corsepius:
On Don, 2001-09-13 at 09:53, Christoph Maurer wrote:
Hallo Liste!
Hat jemand von Euch detaillierte Kenntnisse zum gcc/g++ und insbesondere dem optimierten Kompilieren.
Habe hier eine C++-Datei (2800 Zeilen, 2 große und ca. 15 kleine Funktionen), die sich mit -g wunderbar übersetzen läßt, sobald ich sie aber optimiert übersetzen will, scheitert das (Sowohl mit -O als auch mit -O2). Der Compiler rödelt ewig lange darum, verbraucht immer mehr Speicher und bricht irgendwann ab, weil es keinen Speicher mehr gibt (meine Kiste hat 512 MB + 256 MB Swap). Mit hoher Wahrscheinlichkeit ein Compilerbug.
Hört sich nicht gut an.
Das ganze ist deshalb so störend, weil die Datei zu einem großen Projekt gehört, wenn ich das optimiert übersetzen will, muß ich den Compiler für das eine Objektfile immer gesondert mit -g aufrufen.
Die Routine, wegen der das optimierte Übersetzen scheitert, ist eine Einleseroutine, mit der ein bestimmtes Dateiformat eingelesen werden kann. Zur Verwaltung werden komplexe Datenstrukturen angelegt (Mehrere Maps, sowas wie vector< vector<string*> > etc. ) Kann das ein Problem sein? Halte ich für unwahrscheinlich.
Zwar ist vector<vector<string*>> durchaus diskutabel und auch zur Laufzeit nicht unproblematisch, sollte aber normalerweise nicht zu derartigen Compilerproblemen führen.
Das es nicht ganz unproblematisch ist, ist mir klar, habe das auch nicht programmiert, muß aber leider damit arbeiten.
Für wahrscheinlicher halte ich, dass entweder (a) ein Konstrukt (Rekursion in Templates?) in deinem Code einen Bug im Compiler triggert.
Ist bis auf die STL-Konstrukte vollkommen ohne Templates.
oder (b) der Compiler tatsächlich extrem viel Speicher zur Übersetzung benötigt (-funroll-loops ?).
Beides dürfte auf Compilerbugs hindeuten.
Wenn Du einen gcc < 2.95.2 einsetzen solltest, würde ich vor weiteren Schritten auf jeden Fall auf mindestens 2.95.2 upgraden.
Nutze 2.95.2
Solltest Du gcc >= 2.95.2 einsetzen, würde ich erst einmal versuchen, mit --pedantic zu übersetzen, um Code-Fehler auf deiner Seite weitgehend ausschliessen zu können. Es wäre auch sinnvoll mit verschiedenen Optierungsoptionen zu übersetzen (Möglicherweise ist eine einzelne in -O2/-O enthaltene Optimierung die Ursache).
Das sind gute Ideen, werde ich mal systematisch austesten, sind ja nicht so viele Optimierungen in -O. Code-Fehler auf unserer Seite halte ich nicht für wahrscheinlich, da die Routine erstens (mit -g kompiliert) schon sehr lange im Einsatz ist, zweitens unter MSVC++ ohne Probleme mit Optimierungen kompiliert.
Hilft auch das nicht weiter, würde es sich anbieten mal 2.95.3 < gcc < 3.0 oder gcc >= 3.0.1 auszuprobieren.
Könnte ich höchstens mal zu Hause testen. Ist es aber nicht so, daß ich dann eine Unmenge anderer Fehler zu erwarten habe.
Hilft auch das nicht, wäre ein bug-report (Siehe http://gcc.gnu.org) oder Debugging des Compilers fällig.
Bug-Report stelle ich mir schwierig vor, da ich denen ja dann wohl den Quellcode zur Verfügung stellen müßte. Bei einer Datei wäre das wohl vertretbar, aber die ist halt Teil eines großen Datenmodells, daß erstens nicht aus der Hand gegeben werden darf (GPL hat sich hier bei uns leider noch nicht durchgesetzt), zweitens kann ich mir nicht vorstellen, daß sich ein gcc-Entwickler da rein denken will. Auf jeden Fall herzlichen Dank für Deine Tips. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
participants (3)
-
Christoph Maurer -
Ralf Corsepius -
Thomas Hertweck