SDB:Fehler:GCC
| Getestet mit openSUSE | Empfohlene Artikel | Verwandte Artikel | |||
|
|
|
|
||
Inhaltsverzeichnis
Einen Fehler in GCC melden
Wir brauchen für einen Fehlerbericht über GCC vor allem drei Dinge
- einen Testfall
- einen Testfall
- einen Testfall
Testfall
Ein Testfall ist etwas kurzes und knappes. Es ist nicht: Gehen Sie auf die Seite, laden Sie sich dort das Archiv, kompilieren Sie es und dann sehen Sie den Fehler. Ein guter Testfall besteht aus einer einzigen Datei. Sie haben richtig gehört, eine Datei. Das heißt, eine Datei ohne "includes", weshalb sie vorverarbeitet sein muss. Vorverarbeitet mit:
Oder benutzen Sie -save-temps. C++ vorverarbeitete Dateien heißen quelle.ii.
Weiterhin muss er kurz sein. Er sollte nur den Quelltext enthalten der den Fehler hervorruft. Ohne zusätzliche Funktionen oder Deklarationen, löschen Sie alle nicht notwendigen Blöcke. Fangen Sie mit kompletten Funktionen an, dann die Deklarationen auf der Hauptebene, so dass nur die Funktion übrig bleibt in der der Fehler auftritt. Beseitigen Sie alle unwichtigen Strukturen- und Klassenmitglieder, was eventuell Veränderungen im Code notwendig macht. Alles ist gut, solange der Fehler noch gezeigt wird. Denken Sie daran, dass nur notwendige Funktionen kompiliert werden. Eine statische, nie genutzte Funktion wird von neueren GCC-Versionen nicht kompiliert. Deshalb sollten Sie Funktionen vielleicht nicht-statisch gestalten.
Alles über 200 Zeilen ist voraussichtlich zu groß. Ein Fehlerbericht mit 100 Zeilen ist besser. Alles was mehr als drei Funktionen aufweist ist wahrscheinlich noch nicht bis an die Grenze gekürzt. Versuchen Sie mehr herauszuholen. Das benötigt zwar Zeit, aber wenn Sie es nicht machen, dann müssen wir es machen, und wir sind bei dieser Sache schon der Flaschenhals. Wir werden uns deshalb nicht unbedingt über ihren Fehlerbericht freuen, sollte er zu lang sein.
Allgemeine Hinweise
Wie alle guten Fehlerberichte sollte er in etwa diesem Faden folgen:
- When compiling this:
- <source code> or mention an attachment
- with this command: % gcc [your options] bla.i
- this happens: <outcome>
- with this system: <gcc -v output>
- <uname -a output>
- I instead expect this to happen: <expected outcome>
- because of <reason why you think so>.
Manchmal ist das erwartete Ergebnis offensichtlich und deshalb nicht erwähnenswert. Wenn Sie bspw. einen internen Compiler-Fehler melden, dann ist das eigentlich erwartete Resultat natürlich, dass dieser Fehler nicht passiert, weshalb auch kein Bedarf besteht, dass zu erläutern. Wenn Sie eine fehlerhafte Kompilierung vermuten, dann gestalten Sie den Testfall so, dass er ein paar sichtbare Auswirkungen hat (bspw. ein Abbruch falls das falsche Ergebnis geliefert wird, oder lassen Sie das Ergebnis samt dem erwarteten anzeigen).
Fügen Sie bitte den exakten von ihnen benutzten Befehl hinzu, sowie die Ausgaben von gcc -v und uname -a. Wir wollen nicht compiled with -O2 und dazu eine launige Beschreibung in ihren Worten, sondern viel lieber - weil es einfach machbar und wesentlich exakter ist - eine Beschreibung wie compile with# gcc -c -O2 -fPIC -funny-options bla.i, wobei Sie den Befehl einfach aus der Konsole in den Bericht kopiert haben.
Vergessen Sie auch nicht die weiteren Systemdetails. Erwähnte ich schon die Notwendigkeit eines Testfalls?
Gut zu wissen
Wir benutzen Compiler, die normalerweise im Vergleich zum FSF GCC ein paar Änderungen haben. Trotzdem ist es oftmals der Fall, dass der FSF GCC genau den selben Fehler zeigt. Wenn Sie in der Lange sind, dass zu überprüfen, dann machen Sie das bitte und melden den Fehler direkt im Bugzilla des GCC.
Besuchen Sie auch die Seite http://gcc.gnu.org/bugs.html um mehr Informationen über das Schreiben guter Fehlerberichte zum GCC zu erhalten.