Hi, welche GCC Version ist momentan empfehlenswert, wenn man wenig Wert auf Ueberraschungen wie explodierende Binarygroesse oder kaputte Optimierungen legt? :-)
Postix schrieb: > welche GCC Version ist momentan empfehlenswert, wenn man wenig Wert auf > Ueberraschungen wie explodierende Binarygroesse oder kaputte > Optimierungen legt? :-) für welchen Platform denn?
Für eine brauchbare Antwort sollte man schon die Zielplattform wissen. Ansonsten: 42
Naja, neuere Versionen haben in aller Regel alte Bugs repariert und bessere Optimierung als ältere Versionen. Dafür können sie natürlich neue Bugs haben, die möglicherweise noch keiner entdeckt hat. Ältere Versionen haben teilweise Bugs, die in neueren Versionen repariert sind (aber für die man vielleicht einen Workaround nehmen kann, da man sie kennt), daführ fehlen Optimierungen, die erst später hinzugekommen sind, denn im Gegensatz zu Bugfixes werden die oft nicht zurück portiert. 4.8.0 ist meines Wissens die neueste Version, 4.7.3 ist die letzte auf der 4.7er Linie.
Johann L. schrieb: > Auch die 4.8.1 gibt es schon (seit Mai) OK, da habe ich die Ankündigung davon verpasst. Danke für die Korrektur.
Wie Joerg gut erraten hat, war die Frage fuer AVR gemeint. Und ich habe genau hier schon mehrfach von Problemen mit neueren Versionen gelesen, bei denen es zu wesentlich groesserem und/oder langsamerem Code gekommen ist. Als Grund wurde da zum Beispiel genannt, dass Optimierungen fuer die "grossen" CPUs mitunter bei den kleinen Controllern zum gegenteiligen Effekt fuehren - ergo die neueste Version nicht unbedingt automatisch die beste Version ist.
Hab gerade eine 4.8.1 Toolchain gebaut und kann nur sagen: Spitze, was da rauskommt! BTW, AVR's verschiedenen Typs sind nicht wirklich unterschiedlich. Ok, ganz kleinen ( oder ganz alten) mangelt es an Pointer-Registern, aber vor dem Problem steht auch der Assembler-Handoptimierer. GCC ist vor allem total emotionslos, wenn es darum geht überflüssige CALL's rauszuschmeißen, d.h. man kann schön modular programmieren (gerne auch in Klassen) und im .lss File ist von Overhead keine Spur mehr. Zwischendurch (Übergang zu 4.x und 4.6.x) gab's mal unrühmliche Versionen, aber 4.8.1 ist Top. Einzig die "Installation" aus den Sourcen ist nicht jedermanns Sache.
Bleibt die Frage, was dir eine Antwort nutzt. Baust du dir deine avr-toolchains selber? Oliver
Die letzte habe ich zwangsweise selbst gebaut. Ist schon eine Weile her, aber zum Beispiel die Patches fuer 0b...-Definitionen haben bei der alten Version gefehlt und die neue Version fuer MacOS hat viel zu grossen Code erzeugt. Wenn's geht werde ich jetzt wieder auf eine offizielle Version wechseln - aber manchmal geht es halt nicht. Vom avrdude habe ich auch eine eigene Version, die Apples USB3-Bug umgeht. :-/
Postix schrieb: > Und ich habe genau hier schon mehrfach von Problemen mit neueren > Versionen gelesen, bei denen es zu wesentlich groesserem und/oder > langsamerem Code gekommen ist. Schau dir deren Datum bzw. GCC-Version an: das dürfte allesamt auf (viel) ältere Versionen bezogen gewesen sein. Seit Johann viele Details im AVR-Frontend mal überarbeitet hat (also seit GCC 4.7), dürfte der Großteil dieser Berichte der Vergangenheit angehören. Postix schrieb: > Vom avrdude habe ich auch eine eigene Version, die Apples USB3-Bug > umgeht. :-/ -v, bitte.
Hallo Joerg, das wurde hier mal diskutiert: Beitrag "Mac mit USB 3.0 und USB ASP" Diskutiert eigentlich nicht, aber der Post hat mir geholfen.
OK, daran kann ich natürlich AVRDUDE-seitig auch nicht viel ändern. Ihr solltet das vielleicht mal Thomas Fischl rüberbringen, und eigentlich müsste auch mal jemand Apple einen Bugreport schreiben.
Bastler schrieb: > Hab gerade eine 4.8.1 Toolchain gebaut und kann nur sagen: Spitze, was > da rauskommt! Ich habe mir die dieses Wochenende auch gebaut (schoener Schei...). Aber das Resultat begeistert mich nicht so, ich laufe in folgenden Fehler: --- Source/Screen/Setup/Channel.cpp: In member function 'virtual void Screen_Setup_Channel::display()': Source/Screen/Setup/Channel.cpp:189:1: internal compiler error: in push_reload, at reload.c:1360 } ^ libbacktrace could not find executable to open --- Die 4.8.0 hat das gleiche Problem. :-( Mit welchen Optionen hast du deinen gcc gebaut?
pst schrieb: > Mit welchen Optionen hast du deinen gcc gebaut? Das dürfte wenig von den Build-Optionen abhängen. Ein internal compiler error ("ICE") ist etwas, was nicht auftreten sollte, aber hin und wieder eben doch passiert. Sein Auftreten wird in der Regel durch eine bestimmte Konstellation im Sourcecode getriggert, der da gerade compiliert wird. Sinnvoll wäre es also, wenn du das auf das minimale Stückchen Sourcecode runterbrichst, mit dem der Fehler noch auftritt, und dann damit einen Bugreport öffnest.
Jörg Wunsch schrieb: > OK, daran kann ich natürlich AVRDUDE-seitig auch nicht viel ändern. > > Ihr solltet das vielleicht mal Thomas Fischl rüberbringen, und > eigentlich müsste auch mal jemand Apple einen Bugreport schreiben. Der USB-Bug war Apple uebrigens durchaus bekannt, auf der USB-Mailingliste wurde er diskutiert, wenn auch nicht mit Bezug auf AVRDude.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.