Announcement: there is an English version of this forum on Hallo, Was ist denn mit dem avr-gcc 12.x passiert? Da geht ja fast nichts. Der Compiler scheitert am primitivsten Programmcode und meldet internen Compiler Fehler. Weder die main.cpp noch die Print.cpp hat einen Klammerfehler. Vorallendingen sind das immer so Zufälle. Andere größere Programme kompilieren ohne Probleme. Dann will man nur einmal ein Problem eines Anfängers durchnudeln lassen und plötzlich geht nichts. Ich habe aber 2 Sketche die immer Fehler melden. Im Anhang. Ändere ich für den ersten Sketch die Einstellung auf C++17 statt C++20 dreht "er" völlig durch. Jetzt frage ich mich, hat noch jemand mit dem avr-gcc 12.x. irgendwelche komischen Probleme? Weil nehme ich den avr-gcc 11.3. mit gleichen Einstellungen läuft alles.
:
Gesperrt durch Moderator
Ist das einer von deinen selbstgebauten avr-gccs? Oliver
Hallo, ja ist es. Alle 3 Fehler treten jedoch auch mit der Toolchain von Zak Kemble auf. Falls das jemand mit der Arduino IDE nachvollziehen möchte, im Anhang die lokale platform.txt.
:
Bearbeitet durch User
Du hast vermutlich versucht einen Sketch von Ilja Richter zu compilieren. Die sind unverdaulich.
Das Problem aus Beispiel 1 ist schon vor einigen Monaten als Bug gemeldet worden. Da scheint es auch einen Patch zu geben: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
:
Bearbeitet durch User
Hallo, Danke für den Link. Ist schon lustig. Bug 107035: Status: RESOLVED DUPLICATE of bug 105753 Bug 105850: Status: RESOLVED DUPLICATE of bug 105753 Bug 105753: Status: UNCONFIRMED Kann man damit rechnen das der gcc 12.3. den Patch enthält? Noch eine Frage. Ist der Fehlercode "... avr-dimode.md:2705" ein Sammelbegriff für alle interne Compilerfehler?
Veit D. schrieb: > avr-dimode.md:2705 Das ist eine Datei und Zeilennummer https://github.com/gcc-mirror/gcc/blob/master/gcc/config/avr/avr-dimode.md
Hallo, Danke nur gibt es leider keine Zeile 2705. Was mich auch etwas wundern würde, weil laut meiner Erinnerung alle bisherigen internal compiler errors immer avr-dimode.md:2705 angezeigt haben. Kann ja nicht sein das alle Fehler auf die gleiche Zeile zeigen. Oder?
Veit D. schrieb: > Hallo, > > Danke für den Link. Ist schon lustig. > Bug 107035: Status: RESOLVED DUPLICATE of bug 105753 > Bug 105850: Status: RESOLVED DUPLICATE of bug 105753 > Bug 105753: Status: UNCONFIRMED Naja, das gleiche Problem wurde halt dreimal gemeldet, und die zweite und dritte Meldung wurden als Duplikate markiert und deshalb mit Verweis auf die erste geschlossen. > Kann man damit rechnen das der gcc 12.3. den Patch enthält? Ich würde eher nicht damit rechnen, da der Bug ja immer noch als UNCONFIRMED markiert und niemandem zugewiesen ist. Außerdem ist 13 als Zielversion hinterlegt.
Hallo, muss nochmal darauf zurückkommen, weil gcc 13.1 rausgekommen ist. https://gcc.gnu.org/gcc-13/changes.html Lese ich das richtig das sich für AVR nichts geändert hat? Damit das neue AVR Backend weiterhin kaputt ist?
Veit D. schrieb: > muss nochmal darauf zurückkommen, weil gcc 13.1 rausgekommen ist. GCC 13 ist ja noch garnicht released? https://gcc.gnu.org/gcc-13/ >> As of this time no releases of GCC 13 have yet been made. > https://gcc.gnu.org/gcc-13/changes.html > Lese ich das richtig das sich für AVR nichts geändert hat? Offenbar. > Damit das neue AVR Backend weiterhin kaputt ist? Was meinst du denn mit "kaputt"? An PR105753 scheint sich nix geändert zu haben, falls du das meinst. Änderungen an dessen Status würden auch nicht in den Release Notes kundgetan werden.
sketch schrieb: > Du hast vermutlich versucht einen Sketch von Ilja Richter zu > compilieren. Die sind unverdaulich. <edit> Licht aus! Spot an! Ja, frueher™ war es hier lustiger. </edit> Irgendwo habe ich auch einen gcc12.2.irgendwas. Ich hab mir Sorgen gemacht und nachgesehen. Es ist doch nur ein *-*-*-*-gcc-11.2.1-1.2-win32-x64.zip. Nochmal Glueck gehabt.
:
Bearbeitet durch User
Johann L. schrieb: > Veit D. schrieb: >> muss nochmal darauf zurückkommen, weil gcc 13.1 rausgekommen ist. > > GCC 13 ist ja noch garnicht released? ...ok, der Repo wurde bereits gebrancht und master ist jetzt auf v14.0.0. Release von v13 steht also kurz bevor.
Das Problem tritt mit der C-Funktion aus dem Testcase des PR105753 auf in: 12.2 13.0.1 14.0.0 Mit dem Patch von Johann L. geht 14.0.0. wieder. Interessanterweise compiliert die Testfunktion digit_sum() aus dem Testcase, wenn man sie als Template schreibt (btw: das ist mir schon öfters aufgefallen. Da ich jedoch hauptsächlich generischen Code schreibe, scheinen bei mir diese ICE nur sehr selten getriggert zu werden).
Hallo, genau Johann das meinte ich. Den internen Compilerfehler bekomme ich meistens mit ganz einfachen kurzen Programmen, wie die 2 kleinen Programme Eingangs zeigen. Je größer das Programm umso seltener. Betrifft avr-gcc 10, 11 und 12, wobei die Häufigkeit mit dem 12er gefühlt zugenommen hat. Mich wundert nur das gerade Compiler Errors nicht so ernst genommen werden. Irgendwelche Optimierungen sind doch eher zweitrangig.
Veit D. schrieb: > Den internen Compilerfehler bekomme ich meistens mit ganz > einfachen kurzen Programmen, wie die 2 kleinen Programme > Eingangs zeigen. Das ist jetzt aber in schlechter Witz. Wie soll das jemand ohne das Arduino-Zeugs nachvollziehen? Selbst Leute, die sich mit Arduino auskennen sind nicht in der Lage, für auftretende Fehler Testcases zu erzeugen. Dann postest zu Seitenweise Kommandos die auszuführen sind, die irdendwelche Libs enthalten die nicht zu den Tools gehören wie core_arduino_avr_mega_cpu_atmega2560_991b95454a2889a3c3f3cd19c290e476.a Selbst wenn du die mitlieferst is das ein Grad an Obfuscation, den man keinem zumuten kann.
Hallo, Johann, jetzt mal ehrlich, deine Antwort ist nichts weiter wie eine Hasspredigt. Du kannst mir vorwerfen und einfordern das ich das alles nochmal sauber zum nachvollziehen aufbereiten soll. Das würde ich einsehen. Aber dieses Anti Arduino kannste sein lassen. Die core... .a wird beim kompilieren erzeugt und ist rein temporär. Liegt alles im Temp Ordner von Windows. Jeder der sich halbwegs mit der IDE auskennt kann das nachvollziehen. Das ist kein Hexenwerk. Außerdem sind die gemeldeten Fehler auf bugzilla nicht alle Arduino lastig. So ... abgeschüttelt, tief Luft geholt und aufbereitet. Man nehme: - Standard IDE 1.8.19, am Besten gleich die Portable .zip - Entpacken - im Ordner "arduino-1.8.19" einen Ordner namens "portable" anlegen. - einmal IDE starten und wieder beenden. - im Pfad ...\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.6\ wo die board.txt und platform.txt u.a. liegen eine Datei namens "platform.local.txt" erstellen In der platform.local.txt sind nur abweichende Änderungen zur Originaleinstellung. In dieser Datei braucht man als Basis nur 3 Zeilen. Pfad zu deiner Toolchain ändern.
1 | compiler.path=C:\avrToolchain\avr-gcc-12.2.0_mingw32_binutils2.40_avrLibc2.1GitHub/bin/ |
2 | compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++17 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto |
3 | compiler.cpp.extra_flags=-fno-sized-deallocation -Wall -Wextra |
Das wars. Für alle Ausgaben im IDE Fenster unter IDE > Datei > Voreinstellungen Ausführliche Ausgaben während: beide Haken rein Compiler-Warnungen: Alle Testprogramm.
1 | struct Daten |
2 | {
|
3 | int8_t dir; |
4 | int32_t rel; |
5 | };
|
6 | Daten enc; |
7 | |
8 | void setup (void) |
9 | {
|
10 | Serial.begin(9600); |
11 | Serial.println(F("\nuC Reset")); |
12 | Serial.println(enc.dir); |
13 | Serial.println(enc.rel); |
14 | }
|
15 | |
16 | void loop (void) |
17 | { } |
Alle erzeugten Dateien landen im Windows Temp Ordner. C:\Users\Worker\AppData\Local\Temp\arduino_build_247795 Die letzte Nummer ändert sich immer. Der Pfad steht im IDE Ausgabefenster ganz unten 4. letzte Zeile. Wenn ich das Bsp. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753#c10 kompiliere erhalte ich
1 | during RTL pass: combine |
2 | C:\Arduino IDE Portable\Mega2560\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.6\cores\arduino\main.cpp: In function 'main': |
3 | C:\Arduino IDE Portable\Mega2560\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.6\cores\arduino\main.cpp:51:1: internal compiler error: in add_clobbers, at config/avr/avr-dimode.md:2705 |
4 | 51 | } |
5 | | ^ |
6 | libbacktrace could not find executable to open |
7 | Please submit a full bug report, with preprocessed source (by using -freport-bug). |
8 | See <https://gcc.gnu.org/bugs/> for instructions. |
9 | lto-wrapper.exe: fatal error: C:\avrToolchain\avr-gcc-12.2.0_mingw32_binutils2.40_avrLibc2.1GitHub/bin/avr-gcc returned 1 exit status |
10 | compilation terminated. |
11 | c:/avrtoolchain/avr-gcc-12.2.0_mingw32_binutils2.40_avrlibc2.1github/bin/../lib/gcc/avr/12.2.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed |
12 | collect2.exe: error: ld returned 1 exit status |
13 | exit status 1 |
14 | Fehler beim Kompilieren für das Board Arduino Mega or Mega 2560. |
Die Toolchain baut irgendwas falsch zusammen. Denn im Sketch selbst gibt es keinen Klammerfehler. Bei meinem Bsp. wird ja ein Klammerfehler in einer Print.h gemeldet. Die ist aber absolut fehlerfrei, sonst würde dieses Standard Arduino Headerfile nie funktionieren. Edit: Wenn das immer noch zu kompliziert sein sollte würde ich dir sogar ein komplettes Portables Paket schnüren. Damit habe ich kein Problem.
:
Bearbeitet durch User
Wenn der Fehler in Verbindung mit Arduino auftritt, und du ihn nicht mit einem einfachen, freistehenden Beispielcode provozieren kannst, dann wäre der Bugreport vielleicht besser bei Arduino aufgehoben – wenn es sich um ein Problem beim Compiler handelt, können die dann ja das erforderliche, freistehende Codebeispiel für einen Bugreport bei den Compilerleuten erstellen und hinschicken. Dass bei Letzteren keiner Lust hat, sich durch das Arduino-Geraffel zu graben um zu schauen, was letztlich zum Fehler führt, ist irgendwie nachvollziehbar, finde ich.
@Veit D. ich bin jetzt kein Arduino Experte, und mag mit meiner Aussage falsch liegen, aber Du solltest der Fehlermeldung: <c> lto-wrapper.exe: fatal error /../../../../avr/bin/ld.exe: error: lto-wrapper failed <\c> nachgehen. Alles andere sind ja nur Folgefehler. Kannst Du das Programm lto-wrapper.exe Aufrufen und mal mit \? oder -h oder --help checken, was es macht und eventuell im Web danach suchen, wozu es gut ist! Markus Eventuell dieser Link: https://github.com/arduino/arduino-builder/issues/332
:
Bearbeitet durch User
Hallo, ja ich weiß, der Eine mag kein PlatformIO, der andere kein Microchip Studio, der Nächste kein Arduino. Man kann es niemanden recht machen. Ist mir alles klar. Nur Arduino ist nichts weiter wie eine große Ansammlung an Klassen und Headerfiles was man im Gesamten als Framework bezeichnet wird um die gewollte Abstraktion hinzubekommen. Wenn ich selbst so viele Klassen programmieren würde die alle miteinander verzahnt sind und bekomme diesen Compiler Error würde ich genauso doof dastehen ohne zu wissen woran es liegt. Aber gut was solls. Bringt ja nichts darüber zu streiten. Bei Arduino bin ich abgeblitzt, weil das nicht deren mitgelieferte Toolchain ist. Die IDE wird mit avr-gcc 7.3.0 ausgeliefert. Ich habe mein Bsp. mit dem struct ohne -flto Option kompiliert. Das kompiliert ohne Compiler Error aber mit vielen Warnungen. Gibt es einen Zusammenhang zwischen den Warnungnen und dem was -flto macht? Angenommen man kann die Warnungen beheben, könnte das dem Compiler helfen? Das Bsp. von https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753#c10 kompiliert ohne -flto Option ohne jede Warnung. Hilft uns die neue Erkenntnis weiter? lto-wrapper.exe bringen alle Toolchains mit. Liegt im Toolchain Pfad \...\libexec\gcc\avr\... Dem kann ich so alleine keine Information entlocken. Das Tool benötigt die gcc Umgebung. > lto-wrapper.exe: fatal error: environment variable COLLECT_GCC must be set > compilation terminated.
Bist Du aus dem u.g. Link https://github.com/arduino/arduino-builder/issues/332 schlauer geworden? Markus
Veit D. schrieb: > Johann, jetzt mal ehrlich, deine Antwort ist nichts weiter wie eine > Hasspredigt. ??? Das hat doch nix mit Hass zu tun. > Man nehme: [...] Du willst es einfach nicht verstehen. Niemand, der sich um GCC Bugs kümmert, würde sich irgendein Zeugs installieren und durch irgendwelche Build-Prozesse und zig Module durchwühlen, gegen die dann gelinkt wird. Wobei du das "würde" streichen kannst: Keiner wühlt sich da durch. Isso. Punkt. > Wenn ich das Bsp. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753#c10 > kompiliere erhalte ich [...] Zu dem geposteten Code heißt es weiter unten: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753#c13 > * While you failed to provide anything meaningful to the bug report > (your code snippet is not self-contained valid C code; [...] Dabei wurde weiter oben geschrieben, dass der Testfall von "User99627" auch ohne LTO funktioniert; was bedeutet, es genügt ein Precomilat nebst einem einzigen avr-g++ Aufruf um das Problem nachzustellen. Es bringt doch nix, den Bugtracker mit Zeig zu fluten, das keiner braucht und keinem weiterhilft. Bei jedem ICE wird ein Link zu https://gcc.gnu.org/bugs/ ausgegeben, wo man detailierte Bug-Reporting Anweisungen erhält. Insbesondere: * What we need * What we do not want * Detailed bug reporting instructions Ich weiß jetzt nicht was daran unklar ist.
Johann L. schrieb: > Ich weiß jetzt nicht was daran unklar ist. Gerade die "detailed bug reporting instructions" sind ein Teil Open-Source-Doku die extrem gut ausgearbeitet sind, es steht alles drin und man kann Schritt für Schritt "abschreiben"/nachmachen. <stänkermodus> (Das was diese unsäglichen Youtube-Video-Tutorials versuchen zu erreichen) </stänkermodus> Bin diesen Weg auch schonmal gegangen, nachdem ich es lange geschoben habe, weil ich dachte viel zu kompliziert - workaround reicht.
Veit D. schrieb: > Ich habe mein Bsp. mit dem struct ohne -flto Option kompiliert. Das > kompiliert ohne Compiler Error aber mit vielen Warnungen. Gibt es einen > Zusammenhang zwischen den Warnungnen und dem was -flto macht? Angenommen > man kann die Warnungen beheben, könnte das dem Compiler helfen? Die Warnungen sind ein seit langem bekanntes Problem, was Du mit
1 | --param=min-pagesize=0 |
beheben kannst.
Markus W. schrieb: > Bist Du aus dem u.g. Link > > https://github.com/arduino/arduino-builder/issues/332 > > schlauer geworden? > > Markus Ne, weil das aus 2019 mit dem hier nichts zu tun hat. Meine IDE ist auf dem aktuellen Stand.
Hallo, @ Johann: Dann war deine erste Aussage wahrscheinlich missverständlich ausgedrückt für mein Verständnis. Wenn die Compiler-Leute generell Arduino nicht anfassen ist das eine verständliche Aussage. Damit bin ich beim letzten Punkt. Bugreport. Q: What we need? A: Arduino IDE Das beißt sich ja nun wie wir festgestellt haben. Bugzilla soll nicht geflutet werden. Bugreport mit Arduino guckt sowieso niemand an. Also was machen? @ Wilhelm: Was bewirkt denn "--param=min-pagesize=0" genau? Oder anders gefragt was ist das Problem bei der Meldung "array subscript 0 is outside array bounds of 'volatile uint8_t [0]' [-Warray-bounds]" ? Weil mit Arrays haben die Codezeilen bezüglich der Warnung nichts zu tun.
Veit D. schrieb: > Wenn die Compiler-Leute generell Arduino nicht > anfassen ist das eine verständliche Aussage. Das hat mit Arduino überhaupt nichts zu tun. Die Compiler-Leute und auch sonst niemand fasst einen Bug-report an, der nur auf Beispielen basiert, für die erhebliche externe Abhängigkeiten benötigt werden. Ob das jetzt Arduino oder irgend ein anderes Framework ist, spielt keine Rolle. Veit D. schrieb: > Bugreport mit Arduino guckt sowieso niemand an. > Also was machen? Beispiel liefern, welches den Bug ohne Abhängigkeit zu Arduino oder anderem darstellt. Oliver
Veit D. schrieb: > Was bewirkt denn "--param=min-pagesize=0" genau? > Oder anders gefragt was ist das Problem bei der Meldung > "array subscript 0 is outside array bounds of 'volatile uint8_t [0]' > [-Warray-bounds]" ? > Weil mit Arrays haben die Codezeilen bezüglich der Warnung nichts zu > tun. Richtig, die Fehlermeldung ist sehr irreführend. Es geht hier darum, dass der gültige Adressraum der AVR-Architektur tatsächlich bei der Adresse 0 (Seite 0) beginnt.
Hallo, @ Oliver: Der Fehler tritt nur bei Verwendung der Arduino IDE auf. Da muss ich auf einen Zufall warten bis er außerhalb der Arduino IDE irgendwann auftritt. Wir wissen ja jetzt das der Linker ein Problem hat. Generell auf die Option -flto verzichten ... muss ich überlegen. @ Wilhelm: Danke, dann werde ich diese Option verwenden.
Veit D. schrieb: > Wir wissen ja jetzt das der Linker ein Problem hat. Der Fehler steckt im Compiler, nicht im Linker. Daher sollte sich der in deinem Beispiel compilierte Sourcecode aus den Arduino-Quellen herauslösen lassen, und den Bug dann auch ohne Arduino-Umgebung auslösen. Der Code müsste dann noch auf das wesentliche eingedampft werden. Das wäre jetzt deine Aufgabe. Oliver
Oliver S. schrieb: > Veit D. schrieb: >> Wir wissen ja jetzt das der Linker ein Problem hat. > > Der Fehler steckt im Compiler, nicht im Linker. Ja; der Linker-Plugin bricht natürlich ab, wenn der Compiler den er aufgerufen hat, nen Fehler meldet. > Daher sollte sich der in deinem Beispiel compilierte Sourcecode aus > den Arduino-Quellen herauslösen lassen, und den Bug dann auch ohne > Arduino-Umgebung auslösen. Vermultich nicht. Der Fehler tritt ja im LTO auf, d.h. der Linker-Plugin ruft den Compiler mit dem Bytecode aller involvierten Module auf. Nach den obigen Logs zu urteilen sind das ca. 25 Module zuzüglich der Quellen des Anwenders. > Der Code müsste dann noch auf das wesentliche eingedampft werden. > Das wäre jetzt deine Aufgabe. Ein Großteil des Arduino-Zeugs wird vermutlich garnicht gebraucht. PR105753 tritt ja im Zusammenhang mit 24- und 32-Bit Division / Modulo auf, was z.B. in den Print-Routinen verwendet wird. Eine Möglichkeit zum Reduzieren ist C-Reduce: https://embed.cs.utah.edu/creduce/ Ist aber etwas Aufwand. Und wenn man zu viel reduziert, dann fängt C-Reduce an zu obfuskieren; Variablen und Klassennamen sind dann nur noch einbuchstabig. Was die > 25 Arduino-Module angeht, so kann man versuchen, welche wegzulassen. Nur wenn der Linker dann meckert braucht man es. Aber der Fehler tritt ja bereits vor dem finalen Linken auf. Was verwundert, ist dass es bislang noch **niemand** der Arduinoleute geschafft hat, einen gültigen GCC Bugreport zu fabrizieren. Wenn der Fehler bei Verwendung von LTO bei N Modulen auftritt, dann braucht man zur Reproduktion natürlich N Module bzw. präprozessierte Quellen. Und einen Linkaufruf:
1 | avr-g++ -mmcu=atmega328 -flto ... -fpreprocessed modul1.ii -o modul1.o |
2 | avr-g++ -mmcu=atmega328 -flto ... -fpreprocessed modul2.ii -o modul2.o |
3 | ... |
4 | avr-g++ -mmcu=atmega328 -flto ... -fpreprocessed modulN.ii -o modulN.o |
5 | avr-g++ -mmcu=atmega328 -flto ... -o final.elf modul1.o modul2.o ... |
Dürfte doch kein Hexenwerk sein?
Hallo, wegen dem Bugreport. Was ist mit .i von preprocessed file (*.i*) gemeint? Ist damit das Intel Format gemeint welches eigentlich die Endung .hex hat? Also eigentlich wird nur das fertig kompilierte File benötigt welches mit konkreten Option erzeugt werden muss? Wegen dem angedachten Einzelmodultest muss ich mal schauen ob ich das hinbekomme. Bin nicht so der Kommandozeilenfreak. Lasst mich mal probieren.
Veit D. schrieb: > @ Wilhelm: Danke, dann werde ich diese Option verwenden. Wenn Johann L. gerade eingereichter Patch angenommen wird, brauchst Du das am 14.0.0 ggf. nicht mehr, dann ist diese Option bei avr-gcc immer gesetzt. Insofern hat Dein "Gejammer" hier die notwendige Aufmerksamkeit generiert, die mein PR nicht erfahren hatte ;-)
Veit D. schrieb: > Was ist mit .i von preprocessed file (*.i*) gemeint? Du hast vielleicht schon mal in einer C++ Quelle Direktiven wie #include, #define, #if oder #ifdef gesehen. Das sind Anweisungen an den Präprozessor, bestimmte Textersetzungen vorzunehmen. Das Ergebnis dieser Textersezuung nennt man Präcompilat. Semantisch ist es das gleiche wie das originale .c, .cpp, .S oder was auch immer, aber eben mit durchgeführten Textersetzungen. Üblicherweise brauch man dieses Präcompilat nicht, und es wird vom Compiler in einer temporären Datei gespeichert, die entfernt wird wenn nicht mehr gebraucht. Oder effizienter, die Datei wird per Pipe an den nächsten Compile-Prozess geleitet. Oder noch effizienter, Präprozessor und Compiler sind im gleichen Programm implementiert, bei GCC zum Beispiel in cc1 für C oder cc1plus für C++. tl;dr: Präcompilar bekommst du normalerweise nicht zu sehen und braucht es auch nicht. Mit -save-temps kann man das Präcompilar speichern lassen, die Dateiendung ist dabei *.ii für C++ Quellen. Weil .ii semantisch gleichbedeutend mit .cpp ist aber nur eine einzige Datei, ist sie besser für Bugreports geeignet: So brauch jemand, der nen Bug nachstellt, nicht einen Zoo von Headern in allmöglichen Pfaden zu haben, den du dann auch zum Bugreport anhängen müsstest. Mit einem .ii ist ein Bug also viel einfacher zu reproduzieren. Ein .ii enthält noch #line Direktiven, damit sich eine mögliche Diagnostic, die der Compiler ausgibt, auf den Ort der ursprünglichen Datei beziehen, nicht auf die Zeilennummer des Präcompilats. Wenn diese #line Direktiven stören, kann man sie einfach entfernen. Manchmal ist es auch angenehmer, fehlende Definitionen oder Deklarationen händisch nachzurüsten. Anstatt etwa einen Testfall mit dem kompletten Inhalt von #include <stdint.h> zu beaufschlagen, nur um uint8_t nutzen zu können, kann man stattdessen auch
1 | typedef __UINT8_TYPE__ uint8_t; |
:
Bearbeitet durch User
Wilhelm M. schrieb: > Wenn Johann L. gerade eingereichter Patch angenommen wird, [...] Hab ich nicht vor. Ich hab momentan und auf absehbare Zeit keine Resourcen dazu.
:
Bearbeitet durch User
Johann L. schrieb: > Wilhelm M. schrieb: >> Wenn Johann L. gerade eingereichter Patch angenommen wird, [...] > > Hab ich nicht vor. Ich hab momentan und auf absehbare Zeit keine > Resourcen dazu. Es ging hierum: https://gcc.gnu.org/bugzilla/attachment.cgi?id=54912&action=diff
Wilhelm M. schrieb: > Es ging hierum: > https://gcc.gnu.org/bugzilla/attachment.cgi?id=54912&action=diff Ja, schon klar. So'n Patchlet zu machen geht ja auch flott. Das wars dann aber auch was ich momentan liefern kann. Müsste sich also jemand finden, der das gegen die Testsuite testet, nen Review anleiert (und durchbekommt) etc. Das Patch hat ja keine Höhe (< 10 Zeilen), sollte also kein Problem sein, wenn jemand ohne Copyright Assignment das zum Review gibt oder als Autor eigetragen wird.
Hallo, Danke Johann, ich denke damit lässt sich arbeiten. :-)
Hallo, habe eine Batch geschrieben und es stellt sich heraus das es wohl mit der hook.c ein Problem gibt wegen einem undefiniertem Symbol. Soll ich noch irgendwas testen? Oder kann ich das .ii File vom gesamten Programm vielleicht mit dem hook.c.ii File als BugReport erstellen?
Veit D. schrieb: > Hallo, > > habe eine Batch geschrieben und es stellt sich heraus das es wohl mit > der hook.c ein Problem gibt wegen einem undefiniertem Symbol. Soll ich > noch irgendwas testen? Oder kann ich das .ii File vom gesamten Programm > vielleicht mit dem hook.c.ii File als BugReport erstellen? Und wo taucht da jetzt der Bug aus PR105523 auf?
Hallo, um den geht es eigentlich nicht. Weil den Fehler sieht man nur wenn man -flto weglässt. Das kam durch Zufall hier dazu. Hier geht es die ganze Zeit um den internen Compiler Error. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 Johann hatte gesehen das Problem(e) vorm Linken auftreten, also habe ich Einzeltests durchgeführt.
Veit D. schrieb: > Hallo, > > um den geht es eigentlich nicht. Weil den Fehler sieht man nur wenn man > -flto weglässt. Das kam durch Zufall hier dazu. > Hier geht es die ganze Zeit um den internen Compiler Error. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 > Johann hatte gesehen das Problem(e) vorm Linken auftreten, also habe ich > Einzeltests durchgeführt. Und wo tritt der in Deinem Beispiel auf?
Hallo, ich habe doch erklärt was ich gemacht habe. Wo liegt jetzt das Problem? Ansonsten liest du bitte nochmal den Eingangspost. Das gesamte Programm ist die Datei gcc_BugReport_01.ino.cpp.ii Kurzfassung. mit -flto ... Compiler Error ohne -flto ... kein Compiler Error dafür array subscript 0 is outside ... Warnung
:
Bearbeitet durch User
Veit D. schrieb: > habe eine Batch geschrieben und es stellt sich heraus das es wohl mit > der hook.c ein Problem gibt wegen einem undefiniertem Symbol. Soll ich > noch irgendwas testen? Oder kann ich das .ii File vom gesamten Programm > vielleicht mit dem hook.c.ii File als BugReport erstellen? Den Fehler kann ich nicht nachvollziehen mit deinem Testfall gcc_BugReport_01.ino.cpp.ii, weder mit -flto, noch mit -fno-lto, und auch nicht zusammen mit -ffat-lto-objects:
1 | avr-g++ ~/Downloads/gcc_BugReport_01.ino.cpp.ii -c -save-temps -g -Os -Wall -Wextra -std=gnu++17 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -mmcu=atmega2560 -fno-sized-deallocation |
Versuch hab ich mit v14.0, wo PR105753 noch nicht behoben ist. Ich seh in dem .ii auch nix, was den PR triggern könnte, der ja mit div+mod zu tun hat: Setup und loop enthalten nur Methodenaufrufe von Print, und Print implementiert nix in der Klassendefinition, also auch dort kein div oder mod. Veit D. schrieb: > Hier geht es die ganze Zeit um den internen Compiler Error. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 > dass Problem(e) vorm Linken auftreten, also habe ich > Einzeltests durchgeführt. Der ICE triff vorm Linken auf, aber nach dem ersten Aufruf zum Linken. Wir haben folgende Schritte: Compile.1) .cpp Module präprozessieren zu .ii. Compile.2) .ii compilieren zu .o mit LTO Bytecode. Link.1) Alle .o und .a dem Linker übergeben. Link.2) Linker ruft LTO Plugin auf, aller Bytecode wird extrahiert und dem LTO Compiler übergeben. Link.3) Der LTO-Compiler compiliert LTO Bytecode zu "normalem" .o ohne Bytecode. Link.4) "normale" .o's und Libs .a werden zum .elf gelinkt. * Dein .ii kann einen ICE nachvollziehen, der in Schritt Compile.2 auftritt. * Bei dir tritt der ICE in Schritt Link.3 auf. * Um Schritt Link.3 ausführen, muss vorher Schritt Link.1 ausgeführt worden sein. * Um Schritt Link.1 auszuführen, brauchst vermutlich mehr als ein .o; insbesondere brauch du was, das 32-bit oder 24-bit div+mod verwendet, also z.B. die Implementation von class Print. * Um das Leben komplizierter zu machen, erstellt Arduino nicht nur .o, sondern macht stattdessen eine .a draus on-the-fly. Um einen fürn Bugreport annehmbaren Buildprozess zu erhalten, vereinfachst du den Prozess so, dass die notwendigen .o direkt in Link.1 reingefüttert werden. Zum Beispiel kannst du versuchen
1 | g++ [options] -v -save-temps -flto main.cpp Ardu1.cpp Ardu2.cpp ... Ardu125.cpp |
Dann unnötoge Module weglassen. Wenn der Bug immer noch auftritt, ists ok. Wenn er nicht mehr auftritt oder du einen Linkerfehler wegen undefined reference bekommst, hast du was weggelassen, was für den Bug gebraucht wird.
Hallo, Danke für deine Zeit. Ich versuche es hinzubekommen.
Hallo, kennt sich jemand mit Batch Programmierung unter Windows aus? Ich schaffe es nicht mehrere .cpp Dateien hintereinander anzugeben. Wird doch eigentlich nur mit Leerzeichen hintereinander geschrieben? Mit einer einzeln ist alles i.O. Ich habe alles für mehr Überblick schon vereinfacht. :-)
Kannst du nicht von Kommanozeile aus so aufrufen?
1 | avr-g++ [options] *.cpp -o result.elf |
Hallo, das kann ich besser mit der Batch und Auswahlnummer machen. Ich brauch Ellenlangpfade zu den Modulen. Ergebnis mit .elf wie vorher. Es kommt dabei kein Compiler Error. Außer mit hooks.c und dem fehlenden __empty Symbol. Danach habe ich die paar Zeilen aus dem Arduino Sketch direkt in eine mainModify.cpp geschrieben. Erzeugt auch keinen Fehler. Lasse ich eine Serial.print Ausgabezeile weg (enc.dir oder rel.rel) dann kompiliert das in der Arduino IDE ohne Fehler. Ich kann es jedoch bis jetzt außerhalb von Arduino nicht nachstellen. Edit: ich versuche alle Module aus der IDE rauszuziehen und in einen gemeinsamen Ordner zu legen und nochmal versuchen alle gemeinsam zu kompilieren ...
:
Bearbeitet durch User
Hallo, also ich komme mit dem testen außerhalb der IDE nicht weiter. *.cpp funktioniert nicht, Dateien werden nicht gefunden. Was ich probieren wollte alle Module rauszuziehen um zu testen funktioniert auch nicht. Zu viele Abhängigkeiten. Am Ende fehlt dann die stdlib usw. Ein Fass ohne Boden. Funktioniert so nicht. Wenn ich mehr als 2 Module angebe erhalte ich auf der Kommandozeile
1 | gcc version 12.2.0 (GCC) |
2 | avr-g++: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files |
3 | compilation terminated. |
4 | Drücken Sie eine beliebige Taste . . . |
Ich fasse einmal zusammen. Wenn ich den Testsketch mit der Arduino IDE mit Option -v -save-temps kompilieren lasse, kann das trotzdem niemand von den Compilerbauern nachvollziehen, weil in den erzeugten Dateien das Problem nicht drin steht. Korrekt? Ich habe nochmal den Ordner der beim kompilieren mit der IDE im temp Ordner angelegt wird rangehangen. Den leeren libraries Ordner habe ich im .zip gelöscht. core ... einzelne Module preproc ... ??? sketch ... das eigentliche Programm
:
Bearbeitet durch User
Veit D. schrieb: > Wenn ich mehr als 2 Module angebe erhalte ich auf der Kommandozeilegcc > version 12.2.0 (GCC) > avr-g++: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with > multiple files > compilation terminated. > Drücken Sie eine beliebige Taste . . . Das ist einer der Bereiche, in dem ganz sicher gilt: Kaum macht man es richtig, schon funktionierts. Oliver
Veit D. schrieb: > also ich komme mit dem testen außerhalb der IDE nicht weiter. *.cpp > funktioniert nicht, Dateien werden nicht gefunden. Mit -save-temps bekmmst du nen Zoo von .ii. Die haben, was Compilieren angeht, keine weiteren Abhängigkeiten von Headern. Also kannst du schon mal alle Optionen wie -I, -isystem, -D, -U etc. weglassen, weil diese nur den Präprozessor betreffen. Das einzige was nicht passieren kann, sind Linkerfehler aufgrund fehlender Symbole, im Endeffekt also fehlender Module, weil der Fehler ja vor dem eigentlichen Linken stattfindet. > Was ich probieren wollte alle Module rauszuziehen um zu testen > funktioniert auch nicht. Zu viele Abhängigkeiten. > Am Ende fehlt dann die stdlib usw. Ein Fass ohne Boden. stdlib wird doch erst fürs Linken gebraucht, der Fehler tritt aber doch beim LTO-compile auf, also vor dem Linken. Und verwechsle nicht "Linken" mit Aktionen, die zur LinkZEIT ausgeführt werden, wie eben das Compilieren von LTO Bytecode zu Objectcode (Aufruf von lto1.exe). > Ich fasse einmal zusammen. Wenn ich den Testsketch mit der Arduino IDE > mit Option -v -save-temps kompilieren lasse, kann das trotzdem niemand > von den Compilerbauern nachvollziehen, weil in den erzeugten Dateien das > Problem nicht drin steht. Korrekt? Natürlich ist es irgendwo in der Arduino-Quellen. Die Standard-Libs enthalten nämlich keinen LTO-Bytecode, also kann das Problem nicht daher kommen. Ich bekomme 2 undefined references, einmal für init, einmal für digitalWrite. Es fehlen also noch Module; Arduino-Programme haben doch immer eine init? Den ICE bekomm ich mit deinem arduino_build_962106.zip zum Beispiel so:
1 | > jar xf arduino_build_962106.zip |
2 | > cd arduino_build_962106 |
3 | > avr-gcc-14 -fpreprocessed sketch/*.ii core/*.ii -O2 -mmcu=atmega328 -save-temps -dumpbase "" -flto -Wl,--defsym,init=0 -Wl,--defsym,digitalWrite=0 -Wl,--gc-sections |
4 | during RTL pass: combine |
5 | C:\Arduino IDE Portable\Mega2560\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.6\cores\arduino\IPAddress.cpp: In member function 'printTo': |
6 | C:\Arduino IDE Portable\Mega2560\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.6\cores\arduino\IPAddress.cpp:113:1: internal compiler error: in add_clobbers, at config/avr/avr-dimode.md:2705 |
7 | 0x7fe390ff3d8f __libc_start_call_main |
8 | ../sysdeps/nptl/libc_start_call_main.h:58 |
9 | 0x7fe390ff3e3f __libc_start_main_impl |
10 | ../csu/libc-start.c:392 |
11 | Please submit a full bug report, with preprocessed source (by using -freport-bug). |
12 | Please include the complete backtrace with any bug report. |
13 | See <https://gcc.gnu.org/bugs/> for instructions. |
14 | lto-wrapper: fatal error: avr-gcc-14 returned 1 exit status |
15 | compilation terminated. |
16 | .../bin/../lib/gcc/avr/14.0.0/../../../../avr/bin/ld: error: lto-wrapper failed |
17 | collect2: error: ld returned 1 exit status |
Die Pfade sind natürlich Käse weil in den ii's noch #line Direktiven drinne sind. Mit -Os gibt's kein ICE, und mit
1 | avr-objdump -d a.out | avr-c++filt |
siehst du, welche Funktionen wirklich gebraucht werden. Wie zu erwarten ist es u.a. Print-Zeugs, was divmod verwendet. Ohne LTO bekomm ich dann auch nen ICE, der auf Print hindeutet, und tatsächlich lässt sich der ICE dann triggern mit einer einzigen Translation Unit:
1 | > avr-gcc-14 core/Print.cpp.ii -mmcu=atmega328 -O2 |
Den Puff in Print.cpp.ii kann man dann von Hand aufräumen und / oder mit C-Reduce nen kleineren Testfall generieren, was dann zu sowas wie dem einfachen Testfall im PR105753 führen dürfte.
:
Bearbeitet durch User
...der ICE in Print.cpp wird mit dem im PR105753 vorgeschlagenen Patch behoben. Lässt man C-Reduce auf das Print.cpp.ii los, wird nach paar Sekunden folgendes ausgespuckt:
1 | // -c -O2
|
2 | char a; |
3 | int b; |
4 | unsigned long d; |
5 | unsigned e() |
6 | {
|
7 | do
|
8 | {
|
9 | char c = d % b; |
10 | d /= b; |
11 | a = c; |
12 | } while (d); |
13 | return 0; |
14 | }
|
Was dann i.W. wie der Testfall im PR ist. Wer's nachvollziehen will, hier ist der verwendete "interestingness test" für C-Reduce:
1 | #!/usr/bin/bash
|
2 | |
3 | avr-g++-14 Print-ii.cpp -mmcu=atmega328 -Os -fsyntax-only -Wall -Wextra -Werror >& say1.txt |
4 | |
5 | if [ $? = 1 ]; then |
6 | exit 1 |
7 | fi
|
8 | |
9 | avr-g++-14 Print-ii.cpp -mmcu=atmega328 -O2 -c -Wall -Wextra >& say2.txt |
10 | |
11 | if [ $? = 0 ]; then |
12 | exit 1 |
13 | fi
|
14 | |
15 | grep 'internal compiler error: in add_clobbers, at config/avr/avr-dimode.md:2705' say2.txt > /dev/null |
Der erste Test mit "-fsyntax-only -Os" stellt einfach nur sicher, dass creduce nix produziert, was Warnings wirft, weil es blöde ist, wenn ein Testfall nur so vor Warnings strotzt. Das grep stellt dann sicher, dass der reduzierte Fall noch den ICE wirft.
Johann L. schrieb: > Lässt man C-Reduce auf das Print.cpp.ii los, wird nach paar Sekunden > folgendes ausgespuckt:// -c -O2 > char a; > int b; > unsigned long d; > unsigned e() > { > do > { > char c = d % b; > d /= b; > a = c; > } while (d); > return 0; > } > > Was dann i.W. wie der Testfall im PR ist. ... und das war doch sehr erwartbar, weil natürlich so eine Formatierung ein Integer in eine char-Sequenz umformen muss. Einiges an Arbeit für wenig Erkenntnis, außer das der TO nun endgültig erkennt, dass das Arbeiten mit Arduino-IDE @ Windows einfach eine Strafe ist. Hoffentlich steigt er nun auf *nix um, was aber wiederum nicht sehr erwartbar ist.
Veit D. schrieb: > kennt sich jemand mit Batch Programmierung unter Windows aus? Dazu muß man sich nichtmal besonders tief auskennen, um zu erkennen, was du falsch gemacht hast. Das würde auch mit eine bash oder so nicht funktionieren. Schlichte vollständige Idiotie deinerseits: fehlendes Quoting für Sachen, die das CLI als Trenner wahrnimmt, also insbesondere Whitespaces... Du kannst mit der Kommandozeile nicht wirklich. Wohl weder unter Windows noch unter Linux, sonst wärest du selber zumindest stutzig geworden und hättest die Scheiße bereinigt, lange bevor du das Forum mit deiner dramatischen Inkompetenz nervst...
Wilhelm M. schrieb: > Einiges an Arbeit für wenig Erkenntnis Es ging nicht um den Testfall; den gab's ja schon in Minimalform im PR. Sondern zu zeigen, wie man von einem unter Arduino auftretenden Problem zu einem MCVE kommt. Ich würd aber'n Keks drauf wetten, dass am nächsten GCC PR den ein Arduianer eröffnet, mal wieder nicht mehr klebt als kilobyte-weise Arduino Buildlogs, mit denen keine Wutz was anfangen kann.
Hallo, ich blicke echt nicht mehr durch. Johann, was du so alles testest hat meinen tiefsten Respekt, leider kann ich das schon lange nicht mehr nachvollziehen. Ich verstehe es einfach nicht. Tut mir leid. Was bedeutet "ICE" und was bedeutet "MCVE"? Jetzt sieht es ja so aus als ob ein Fehler in der Print Klasse steckt der nun ab gcc 12 ans Licht kommt. Nur sehe ich den Fehler in der Print.cpp nicht. Zudem sich damit nicht erklären lässt, warum nur eine Serial Ausgabe eines struct Members kompiliert und beide nicht. Das bricht ab
1 | struct Daten { |
2 | int8_t dir; |
3 | int32_t rel; |
4 | };
|
5 | Daten enc; |
6 | |
7 | void setup (void) { |
8 | Serial.begin(9600); |
9 | Serial.println(F("\nuC Reset")); |
10 | Serial.println(enc.dir); |
11 | Serial.println(enc.rel); |
12 | }
|
13 | |
14 | void loop (void) |
15 | { } |
und das kompiliert ohne Abbruch.
1 | struct Daten { |
2 | int8_t dir; |
3 | int32_t rel; |
4 | };
|
5 | Daten enc; |
6 | |
7 | void setup (void) { |
8 | Serial.begin(9600); |
9 | Serial.println(F("\nuC Reset")); |
10 | Serial.println(enc.dir); |
11 | }
|
12 | |
13 | void loop (void) |
14 | { } |
Laut meiner Logik dürfte wenn dann nichts von beiden kompilieren. Ich verstehe das Problem bis jetzt nicht. Was ist laut Eurer Meinung an der Print.cpp falsch? Soll ich den Bugreport machen oder nicht? @ c-hater: Würdest du mich erhellen und zeigen wie der Syntax richtig lautet?
Hallo, nicht das auch unbekannten Gründen der Compiler die Print Klasse falsch kompiliert. Deswegen habe ich diese im Original angehangen. Ich kann darin keinen Fehler erkennen.
Veit D. schrieb: > Ich verstehe es einfach nicht. Tut mir leid. Was > bedeutet "ICE" und was bedeutet "MCVE"? ICE: Internal Compiler Error MCVE: Minimal complete verifying example Veit D. schrieb: > Jetzt sieht es ja so aus als ob ein Fehler in der Print Klasse steckt > der nun ab gcc 12 ans Licht kommt. Nein! Wir jeden doch die ganze Zeit über einen ICE! Also, die Klasse Print ist syntaktisch und semantisch ok, jedoch triggert sie genau den ICE aus dem o.g. Bug des gcc. Was in der Klasse Print enthalten ist, ist eine ähnliche Funktion wie im Bug-Report. In diesem Fall ist es die Routine zur Abspaltung der Stellen eines Integers in einzelne Zeichen / Ziffern im Zehnersystem. Im PR war es die Aufsummierung der Stellen. Veit D. schrieb: > void setup (void) { > Serial.begin(9600); > Serial.println(F("\nuC Reset")); > Serial.println(enc.dir); > Serial.println(enc.rel); > } Wie auch im PR tritt der ICE nur dann auf, wenn ein 32-Bit Typ verwendet wird. Und das ist hier der Fall, weil das Datenelement rel den Typ uint32_t (unsingend long int) hat (s.a. Funktion printNumber(...)).
Hallo, Danke erstmal für die Begriffserklärungen. Das Problem ist glaube ich etwas verzwickter. Es kommt darauf an ob es signed oder unsigned ist. Erst dachte ich es liegt mit am struct, man kann es aber auch ohne struct testen. Generell scheint es mit 32Bit signed/unsigned kein Problem zu geben. Eine Ausgabe nur einer Variablen funktioniert, egal ob signed oder unsigned, egal wie breit. Es kommt auf die Konstellation der Datentypen an. Sind beide signed oder beide unsigned knallt es.
1 | int16_t dir; // oder beide unsigned |
2 | int16_t rel; // |
3 | |
4 | void setup (void) { |
5 | Serial.begin(9600); |
6 | Serial.println(F("\nuC Reset")); |
7 | Serial.println(dir); |
8 | Serial.println(rel); |
9 | }
|
10 | |
11 | void loop (void) |
12 | { } |
Ist eine von beiden signed und die andere unsigned funktioniert es.
1 | uint32_t dir; // oder signed / unsigned vertauscht |
2 | int32_t rel; // |
3 | |
4 | void setup (void) { |
5 | Serial.begin(9600); |
6 | Serial.println(F("\nuC Reset")); |
7 | Serial.println(dir); |
8 | Serial.println(rel); |
9 | }
|
10 | |
11 | void loop (void) |
12 | { } |
Das Spiel kann ich mit 8Bit und 16Bit Typen und gemischt wiederholen. Immer das gleiche Schema. Allein signed/unsigned ist entscheidend. signed mit unsigned gemischt ok, beide gleich nicht ok. Die Reihenfolge welche signed / unsigend ist spielt keine Rolle. Ist vielleicht eine wichtige Erkenntnis.
Hallo, es gibt noch ein Schema wo es immer funktioniert. Wenn beide unsigned sind und beide Datentypen in der Breite unterschiedlich funktioniert es. Beide unsigned und beide gleiche Breite funktioniert es nicht mehr. Zum anschauen, okay sind bspw.
1 | uint16_t dir; |
2 | uint32_t rel; |
3 | -----------------
|
4 | uint16_t dir; |
5 | uint8_t rel; |
6 | -----------------
|
7 | uint16_t dir; |
8 | uint32_t rel; |
Haben beide unsigned gleiche Datenbreite funktioniert es nicht mehr.
:
Bearbeitet durch User
Was versuchst du jetzt noch rauszuarbeiten? Ist doch klar dass PR105753 ein GCC-Bug ist, und ist auch klar wie man den mit 5 Zeilen C-Code triggern kann.
Hallo, weil das mir bis jetzt nicht deutlich klar war an was es nun wirklich liegt. Es wurde immer auf der Print Klasse rumgehackt, die nun nicht Schuld ist. Und es war nur von uint32_t die Rede. Vielleicht hilft das ja den Fehler zu finden, dachte ich mir. Ich möchte ja nichts weiter wie das der Fehler beseitigt wird und so viele Informationen, hoffentlich nützliche, beitragen das es die Compilerbauer so leicht wie möglich haben. Im Rahmen meiner Möglichkeiten. Ich Danke dir für deine Mühen und Geduld mit mir - Johann.
:
Bearbeitet durch User
Du kannst einfach den Patch aus dem PR nehmen und Dir damit einen avr-gcc selbst bauen. Dann bist Du das Problem los.
Veit D. schrieb: > Es wurde immer auf der Print Klasse rumgehackt Nirgendwo hat irgendjemand darauf rumgehackt. Es wurde nur festgestellt, dass augenscheinlich der Code in der Print.cpp einen bestimmten ICE triggert. Nachdem der ICE damit nachvollzogen wurde, wissen wir nun, dass es wirklich Code aus diesem Modul ist, dass den ICE triggern kann (abhängig von Compilerversion und Optionen). Insbesondere wurde auch festgestellt, dass sich der GCC Bug ohne LTO nachvollziehen lässt (was i.d.R bedeutet, dass man zu einfacher nachzuvollziehenden (Minimal)beispielen gelangen kann. Ich seh da jetzt nix, wo irdenjemand auf Print.cpp rumhackt oder Hasspostings schreibt. Vielleicht mal den Empörungsradar neu einnorden. > Vielleicht hilft das ja den Fehler zu finden Der Fehler bzw. mögliche Fix ist ja gefunden: https://gcc.gnu.org/bugzilla/attachment.cgi?id=54899&action=diff
Hallo, eine generelle Frage zum Verständnis. Wie können sich solche Bugs einschleichen? Ändert jemand an funktionierendem Code rum oder woran liegt es das etwas nicht mehr funktioniert was bis dahin funktioniert hat? Um irgendeinen Patch einbauen zu können müßte ich erstmal erkennen was der Patch in dem BugZilla Thread #105753 ist und wissen was ich dann machen müßte. Gibt es dafür eine Anleitung?
Veit D. schrieb: > eine generelle Frage zum Verständnis. Wie können sich solche Bugs > einschleichen? Ändert jemand an funktionierendem Code rum oder woran > liegt es das etwas nicht mehr funktioniert was bis dahin funktioniert > hat? Ja. Da hat wohl jemand was verschlimmbessert. gcc Quellen Downloaden, Patch downloaden (aus comment 17), patchen, gcc bauen, fertig. Oliver
Veit D. schrieb: > Wie können sich solche Bugs einschleichen? hast du schon mal nen Bug in deine Software gehabt, nachdem mal alles funktioniert (hatte)? Ist bei GCC auch so. Jedes Jahr im Frühjahr gibt's eine Major Release, also eine Release, die auch neue Features hat. Dazu gehören neue Sprachen wie Rust oder Modula-2, neue Backkends wie Risc-V, neue Optimierungen, bessere Diagnostics, Vectorizing, Supportlibs zum Bugfinden wie die ganzen Sanitizer, etc. Dabei wird seit v5 die Version jedes Jahr um 1 hochgezählt. Dieses Jahr war die v13 dran, nächstes Jahr wird's die v14 werden usw. Hinter dem ersten . wird der Patch-Level hochgezählt. Das sind Minor Releases wie v5.4, die lediglich Bugs beheben. Dazu gehören das Generieren von falschem Code, Abstürze wie eben Internal Compiler Errors. > Ändert jemand an funktionierendem Code rum Ja klar, ohne Änderungen kann keine Software besser werden oder neue Features bekommen. > Um irgendeinen Patch einbauen zu können müßte ich erstmal erkennen was > der Patch in dem BugZilla Thread #105753 ist und wissen was ich dann > machen müßte. Gibt es dafür eine Anleitung? "man patch" oder https://linux.die.net/man/1/patch An PR105753 klebt ein einziges Patch als Attachment. Irgendwo speichern und dann
1 | $ patch -p NUM < pr105753.diff |
wobei NUM davon abhängt wo der aktuelle Pfad ist relativ zur Zieldatei avr.md.
:
Bearbeitet durch User
Veit D. schrieb: > Hallo, > > eine generelle Frage zum Verständnis. Wie können sich solche Bugs > einschleichen? Ändert jemand an funktionierendem Code rum oder woran > liegt es das etwas nicht mehr funktioniert was bis dahin funktioniert > hat? Tja, wie schleichen sich Bugs ein. Hast Du noch nie einen versteckten Fehler eingebaut, der erst später aufgedeckt wurde?
Hallo, naiv dachte ich es gibt im Unterbau Codeteile die einmal getestet nie wieder angefasst werden müssen. Wenn ich mir die avr.md anschaue sieht das nicht nach einer Programmiersprache aus. Da scheint es auch auf die Anzahl von Leerzeichen an bestimmten Stellen anzukommen. Der Patch ist eingebaut. Problem behoben. Vielen vielen Dank!
Ist ja nicht das einzige Problem. Gibt zum Beispiel auch falschen Code mit https://gcc.gnu.org/PR109650 Die v11 funcktioniert noch, die v12.2 nicht mehr.
Veit D. schrieb: > Hallo, > > naiv dachte ich es gibt im Unterbau Codeteile die einmal getestet nie > wieder angefasst werden müssen. Ja, das ist wirklich naiv. 100% test-coverage bzgl. der Anforderungen ist wünschenswert, aber in der Praxis nicht zu erreichen.
Ist ja nicht das einzige Problem. Gibt zum Beispiel auch falschen Code mit https://gcc.gnu.org/PR109650 Die v11 funktioniert noch, die v12.2 nicht mehr. Veit D. schrieb: > naiv dachte ich es gibt im Unterbau Codeteile die einmal getestet nie > wieder angefasst werden müssen. Manchmal muss auch das sein, siehe zum Beispiel https://gcc.gnu.org/PR92729 Das waren recht großflächige Änderunge. Zwar "machanische" Änderungen, aber danach trat dann PR105753 auf, obwohl das überflüssige PARALLEL bei [u]divmodsi4 schon seit über 20 Jahren in avr.md drinne war. > Da scheint es auch auf die Anzahl von Leerzeichen an bestimmten > Stellen anzukommen. Wenn man die Coding-Rules und Einrückungen beachtet, dann ja.
Johann L. schrieb: > Ist ja nicht das einzige Problem. Gibt zum Beispiel auch falschen Code > mit > > https://gcc.gnu.org/PR109650 > > Die v11 funcktioniert noch, die v12.2 nicht mehr. Das produziert aber keinen ICE sondern schlicht falschen Code. Das ist sehr tragisch. Daneben gibt es noch einige Verschlimmbesserungen bzgl. Optimierung, wie Du selbst am besten weißt. Und dann gibt es noch die ganzen unentdeckten Fehler...
Hallo, das klingt nicht gerade Vertrauens erweckend. Man könnte denke man dürfte den gcc ab 11 nicht mehr verwenden.
Veit D. schrieb: > Man könnte denke man dürfte den gcc ab 11 nicht mehr verwenden. Um alle v9+ würde ich nen Bogen machen, jedenfalls für Target AVR. Warum brauchst du denn unbedingt v12?
Hallo, selbst den gcc 9 würdest du nicht empfehlen? gcc 8 wäre schon arg veraltet. Würde ja praktisch bedeuten das die Entwicklung trotz aller Bemühungen ums neue Backend tot ist, wenn man beim gcc 8 stehen bleibt. Weil es gab nun schon nach gcc 8 vier neue Generationen, da kommt doch nicht wirklich mehr jemand mit patchen hinterher. Da müßte es ja gefühlt eine Feature Freeze geben und 2 Jahre lange nur gepatcht werden. Habe schon mitbekommen das AVR nur stiefmütterlich behandelt wird. Finde ich traurig, weil die AVR Controller leicht zu überblicken sind und für alles ausreichend sind was man so macht. Warum ich mir neue Versionen baue? Gute Frage. Eher Spieltrieb wegen neuen Features wie constinit, consteval und ich wollte mich mit template Metaprogrammierung näher befassen. Benötigt aber alles viel Zeit. Ich könnte mich eigentlich auch mit C++17 zufrieden geben. Für C++17 ist doch eigentlich gcc 9 perfekt?
Veit D. schrieb: > selbst den gcc 9 würdest du nicht empfehlen? https://gcc.gnu.org/PR90706 betrifft v9 bis einschließlich v12.2, behoben wurde er ab 12.3. Ist zwar "nur" Code-Bloat von u.U. +10% oder mehr, will man aber trotzdem nicht. > gcc 8 wäre schon arg veraltet. Heißt? Neue Devices gehen ja eh per Device-Pack. Ok, für 64-Bit (long) double brauchst v10+. Oder brauchst du bleeding edge C++23? > Weil es gab nun schon nach gcc 8 vier neue Generationen, Dadurch gibt es aber nicht automatisch mehr Leute, die bereit sind, zu avr-gcc beizutragen. > Da müßte es ja gefühlt eine Feature Freeze geben und 2 Jahre > lange nur gepatcht werden. Wird ja auch so gemacht. Die v12.2 enthält im Vergleich zur v12.1 nur Bugfixes, dito wird auch zutreffen für v12.3 bezüglich v12.2. Hängt auch davon ab, wie weit ein Patch zurückportiert wird. Das ist ja auch Arbeit die einem keiner bezahlt. PR90706 zum Beispiel wurde in v13 gefixt und dann auf v12 zurückportiert, so das er in v12.3+ behoben ist. Aber auch nur weil ich lieb nachgefragt hab. Und dieser PR wurde überhaupt nur gefixt, weil ich den entsprechenden Maintainer angetriggert hab, was eigentlich ein NoGo ist. > Habe schon mitbekommen das AVR nur stiefmütterlich behandelt wird. Wie gesagt: Wer solls denn machen? Hast du schon mal nen Patch reviewen lassen, mit allem was dazugehört? Ich meine jetzt ohne den Patch selber erstellen zu müssen. Gibt ja PR's wo vorgeschlagene Patches drankleben. Zwei Voraussetzung erfüllst du ja schon mal: Du bist dran interessiert und weisst, wie man nen avr-gcc generiert. > Finde ich traurig, weil die AVR Controller leicht zu überblicken > sind und für alles ausreichend sind was man so macht. Und wie genau soll das zu mehr Kontributoren führen?
:
Bearbeitet durch User
Hallo Johann, wie gesagt, ich brauche rein praktisch weder C++20 noch C++23. Spielerei eben. Eigentlich möchte ich an meiner Modelleisenbahn bauen und programmieren. :-) Und im Arduino Forum helfen. :-) :-) Wegen patchen und Feature Freeze. Ich meinte eher es müssen doch immer mehrere gcc Generationen "parallel" gepflegt werden. Wenn man dann noch spät entdeckte Fehler für ältere gcc's portiert ist das ein großer Aufwand. Und wenn das nur noch klappt wenn man direkten Kontakt zu bestimmten Leuten hat, weil ansonsten nichts passiert, was soll ich dazu weiter sagen ... Ich würde generell anders rangehen. Bevor ich alte gcc Versionen nachträglich patche, würde es doch mehr Sinn machen den aktuellen mit allen Patches zu versorgen die es gibt. Da sind die älteren Version eben veraltet, wie es mit jeder alten Software ist und die aktuelle Version bekommt alle erdenklichen bekannten Updates. Damit werden doch auch Ressourcen - Manpower - frei. Eine Ausnahme würde ich zulassen. Die letzte gcc Version vorm neuen Backend würde ich so lange pflegen bis das neue Backend soweit stabil ist. Die Arbeit dahinter kann ich nur erahnen. Deswegen sollten das nur Vollzeit Beschäftigte machen. In der Freizeit schafft das doch keiner mehr alle Patches abzuarbeiten. Wenn das so einfach wäre könnte das Wilhelm nebenbei machen. Er hat wenigstens dein Level. Johann, vielen Dank für deine Freizeit. Kann man gar nicht hoch genug bewerten. Das man sowas nicht dauerhaft durchhält ist verständlich. Und nein, ich habe noch keinen gcc Patch reviewen lassen. Wie auch. Bin froh wenn ich die Toolchain bauen und einen Einzigen Patch reinbekomme. Du willst gar nicht wissen wie ich den gepatcht habe. Mit der Pfad Angabe vom 'patch' Kommando komme ich nicht zu recht. Also habe ich den Patch ins gleiche Verzeichnis kopiert wo die Datei avr.md liegt und dann 'patch' ausgeführt. Ich wollte nicht schon wieder fragen. Umständlich aber ich kam vorwärts. Die Methode klappt aber mit den anderen beiden Patches nicht. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 (gcc/avr/mmcu/lower-subreg.cc) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532 (gcc/config/avr/avr.cc) Vermutlich weil die noch andere Dateien in anderen Verzeichnisse verändern. Der entpackte gcc liegt in
1 | /home/ubuntixer/toolchain/downloads/gcc |
hier drin liegen dann die Ordner und Dateien vom gcc. Also Ordner config, contrib, c++tools, ..., gcc, gmp usw. Und die Patches hatte ich eigentlich hier abgelegt.
1 | /home/ubuntixer/toolchain/Patches |
Wenn ich mich auf der Kommandozeile in /Patches befinde und eingebe
1 | > patch -p3 < pr105753.diff |
Dann geht er laut Beschreibung 3 von links auf /toolchain zurück. Wie soll dann der Pfad zu
1 | /home/ubuntixer/toolchain/downloads/gcc/gcc/config/avr |
gefunden werden? Ich verstehe es nicht. Du meinst, wenn ich Toolchains bauen kann und irgendwann Patches vernünftig darin einpflegen kann, dann könnte ich Patches testen?
Veit D. schrieb: > Ich meinte eher es müssen doch immer mehrere gcc Generationen > "parallel" gepflegt werden. Wird ja auch, siehe "Supported Releases" in https://gcc.gnu.org Es werden also noch Änderungen an 5 Versionen gemacht: v14 wird aktuell entwichelt, und v13, v12, v11 und v10 werden noch supported. Wobei wie gesagt nur kritische Patches rückportiert werden, und die v10 Serie wohl demnächst mit v10.5 dichtgemacht wird. > Wenn man dann noch spät entdeckte Fehler für ältere gcc's portiert > ist das ein großer Aufwand. Ja, ist halt GCC. Aber die meisten Patches passen, und man weiß ja, wo das Problem war und wie es zu beheben ist. Aufwand ist dann halt Testing, aber das kann ja im Hintergrund laufen. > Und wenn das nur noch klappt wenn man direkten Kontakt zu > bestimmten Leuten hat, weil ansonsten nichts passiert, > was soll ich dazu weiter sagen Hab ich bislang auch nur ein einziges Mal gemacht. "Problem" des AVR Backends ist, dass es was Prio angeht drittklassig (ternary) ist. Grund ist, dass aufgrund des chronischen Entwicklermangels für AVR nicht sichergestellt ist, dass kritische Probleme auch zeitnah gelöst werden. Die Qualität ist also kein Kritierium für GCC Releases, und Bugs für ternäre Targets haben definitionsgemäß Prio P4 oder P5, wobei P5 die geringste ist. Außerdem gibt es zwei Hemmschuhe warum AVR nicht secondary ist: 1) double ist nicht standardkonform. Erst mit v10 gibt es 64-Bit double, wobei das noch nichtmal der Default ist um mit älteren Versionen kompatibel zu sein (man braucht -mdouble=64). 2) libsup++ wird incht unterstützt. Das wäre das Minimum an C++ Support. Da geht es zum Beispiel um File Handling. Embecosm hat sich wohl mal dran versucht, aber es blieb eben bei einem Versuch. Zu Urzeiten um die Jahrtausenwende gab es sogar GCC Maintainer, die befürworteten, dass AVR primäres Target wird weil es sich so stark von allen anderen Targets unterscheidet. Aber wie gesagt: 1) und 2) und mangelnder Support haben da einen Strich durch die Rechnung gemacht. Wie es dann weiterging wissen wir ja. > Mit der Pfad Angabe vom 'patch' Kommando komme ich nicht zu recht. > Also habe ich den Patch ins gleiche Verzeichnis kopiert wo die Datei > avr.md liegt und dann 'patch' ausgeführt. Ich wollte nicht schon > wieder fragen. Umständlich aber ich kam vorwärts. Die Methode klappt > aber mit den anderen beiden Patches nicht. Vermutlich weil da mehrere Dateien gepatcht werden. Ist bei "richtigen" Patches die Regel, weil ja auch Testfälle dazugehören. Im Patch steht ja drin , welche Datei gepatcht wird. Bei git diff sieht da zum Beispiel so aus
1 | diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md
|
2 | index 43b75046384..610fedcf59c 100644
|
3 | --- a/gcc/config/avr/avr.md
|
4 | +++ b/gcc/config/avr/avr.md
|
5 | ... |
Man stellt sich also ins GCC Quellverzeichnis und dann
1 | $ patch -p1 < /path/patch.diff |
-p1 weil das "a/" bzw. "b/" im Patch zu viel ist und man es entfernen muss um korrekte Pfade zu erhalten.
Veit D. schrieb: > Du meinst, wenn ich Toolchains bauen kann und irgendwann Patches > vernünftig darin einpflegen kann, dann könnte ich Patches testen? Na, auf jeden Fall. Hast Du doch jetzt schon bewiesen ;-) Veit D. schrieb: > wie gesagt, ich brauche rein praktisch weder C++20 noch C++23. Spielerei > eben. Na ja, C++20 hat schon ein paar Goodies an Board, C++23 wirst Du auf dem AVR nicht so vermissen, da es außer den DRs meisten Library-Features enthält. Bei C++26 sieht das ggf. wieder anders aus. In C++20 habe ich auf meiner Hit-Liste: - designated initializers - Concepts - SpaceShip - init-statements / range-based loop - is_constant_evaluated - consteval, constinit - explicit template parameters in generic lambda - char8_t - UDT in NTTP - modules (außerhalb µC) Für das AVR-Backend stellt ich in letzter Zeit eine klein wenig gesteigerte Aktivität fest. Und leider kommt das clang AVR-Backend nicht so recht voran (Konkurrenz würde vielleicht das Thema beleben?).
Hallo, ich habe das mit patch command und den Pfadangaben heute nochmal probiert. pr105753 funktioniert. Alles mit gcc 12.2.0
1 | > patch -p1 < ../../Patches/pr105753.diff |
1 | ubuntixer@ubuntixer:~/toolchain/downloads/gcc$ patch -p1 < /home/ubuntixer/toolchain/Patches/pr105753.diff |
2 | patching file gcc/config/avr/avr.md |
3 | Hunk #1 succeeded at 3755 (offset 1 line). |
4 | Hunk #2 succeeded at 4091 (offset 1 line). |
5 | Hunk #3 succeeded at 4140 (offset 1 line). |
6 | Hunk #4 succeeded at 4191 (offset 1 line). |
7 | Hunk #5 succeeded at 4238 (offset 1 line). |
Aber pr105532 und pr109476 funktioniert nicht.
1 | ubuntixer@ubuntixer:~/toolchain/downloads/gcc$ patch -p1 < /home/ubuntixer/toolchain/Patches/pr109476.diff |
2 | patching file gcc/lower-subreg.cc |
3 | Hunk #3 succeeded at 1380 with fuzz 1. |
4 | Hunk #4 FAILED at 1687. |
5 | 1 out of 4 hunks FAILED -- saving rejects to file gcc/lower-subreg.cc.rej |
1 | ubuntixer@ubuntixer:~/toolchain/downloads/gcc$ patch -p1 < /home/ubuntixer/toolchain/Patches/pr105532.diff |
2 | (Stripping trailing CRs from patch; use --binary to disable.) |
3 | patching file gcc/config/avr/avr.cc |
4 | (Stripping trailing CRs from patch; use --binary to disable.) |
5 | patching file gcc/testsuite/gcc.target/avr/torture/pr105523.c |
6 | patch unexpectedly ends in middle of line |
7 | patch: **** malformed patch at line 43: |
Sind meine Patchfiles fehlerhaft?
Veit D. schrieb: > 6patch unexpectedly ends in middle of line > 7patch: **** malformed patch at line 43: > > Sind meine Patchfiles fehlerhaft? Ja. Der Fehler ist üblicherweise in Zeile 42 ;) Schau halt in die Datei, was da in Zeile 43 steht. Oliver
Hallo, in der pr105532.diff steht
1 | 41 +void func (void) |
2 | 42 +{
|
3 | 43 + SFR = 1; |
4 | 44 +} |
in der zu patchenden avr.cc steht
1 | 41 #include "emit-rtl.h" |
2 | 42 #include "recog.h" |
3 | 43 #include "conditions.h" |
4 | 44 #include "insn-attr.h" |
Nützt mir absolut nichts. Die diff soll ja die .cc patchen, müssen ja unterschiedlich sein. Meine Frage war ob meine .diff okay ist oder nicht.
Veit D. schrieb: > Meine Frage war ob meine .diff okay ist oder > nicht. Die Fehlermeldung von patch ist da doch sehr eindeutig und dazu präzise. Was also tun? Man wirft die Fehlermeldung goggle vor, denn in den allermeisten Fällen hat den Fehler schonmal jemand vor dir gehabt. Dann findet sich z.B. das hier: https://unix.stackexchange.com/questions/1395/what-does-patch-unexpectedly-ends-in-middle-of-line-mean Vermutlich fehlt da einfach ein CR/LF am Ende der Datei, oder sowas in der Art. Oliver
Hallo, wegen dem CR/LF Problem zwischen Windows und Linux beim speichern hatte ich schon im Vorfeld gelesen und alles nochmal extra unter Ubuntu "runtergeladen" und gespeichert. Mal sehen woran es noch liegen könnte ...
Hallo, Zwischeninfo. Nach Behandlung mit dos2unix hat es mit pr105532 funktioniert.
1 | patching file gcc/config/avr/avr.cc |
2 | patching file gcc/testsuite/gcc.target/avr/torture/pr105523.c |
Nur pr109476 sträubt sich noch ... mal schauen ...
Hallo,
bei pr109476 darf man nur dos2unix anwenden. Warum auch immer.
Vorher mit
> echo -e "\n" >> Datei
funktionierte nicht.
Neu gespeichert, nur mit dos2unix behandelt, alles okay.
Danke.
(Warum ist das nur immer so unterschiedlich so umständlich ...)
Hallo, gibt es noch einen wichtigen Patch für gcc 12.2.0?
Beitrag #7403973 wurde vom Autor gelöscht.
Hallo, hatte Probleme beim kompilieren, habe nochmal von vorn angefangen und jeden einzeln reingepatched und jeweils kompilieren lassen. Mit dem letzten PR109476 gibt es ein Problem beim kompilieren.
1 | make[4]: Verzeichnis „/home/ubuntixer/toolchain/buildLinux/avr-libc/avr/devices/atmega256rfr2“ wird verlassen |
2 | make[3]: Verzeichnis „/home/ubuntixer/toolchain/buildLinux/avr-libc/avr/devices/atmega256rfr2“ wird verlassen |
3 | Making install in atxmega8e5 |
4 | make[3]: Verzeichnis „/home/ubuntixer/toolchain/buildLinux/avr-libc/avr/devices/atxmega8e5“ wird betreten |
5 | avr-gcc -DHAVE_CONFIG_H -I. -I../../../../../downloads/avr-libc/avr/devices/atxmega8e5 -I../../.. -I../../../../../downloads/avr-libc/common -I../../../../../downloads/avr-libc/include -I../../../include -Wall -W -Wstrict-prototypes -mmcu=atxmega8e5 -mcall-prologues -Os -MT eewr_block_xmega.o -MD -MP -MF .deps/eewr_block_xmega.Tpo -c -o eewr_block_xmega.o ../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c |
6 | ../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c: In function 'eeprom_write_block': |
7 | ../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c:124:1: error: unrecognizable insn: |
8 | 124 | } |
9 | | ^ |
10 | (insn 89 88 58 12 (set (concatn:HI [ |
11 | (reg:QI 93) |
12 | (reg:QI 94 [+1 ]) |
13 | ]) |
14 | (reg:HI 96)) "../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c":92:36 -1 |
15 | (nil)) |
16 | during RTL pass: subreg1 |
17 | ../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c:124:1: internal compiler error: in extract_insn, at recog.cc:2791 |
18 | 0x7f0367029d8f __libc_start_call_main |
19 | ../sysdeps/nptl/libc_start_call_main.h:58 |
20 | 0x7f0367029e3f __libc_start_main_impl |
21 | ../csu/libc-start.c:392 |
Ich kann in der eewr_block_xmega.c keinen Klammerfehler erkennen. Zeile 124 enthält die letzte Klammer der letzten Funktion. Vorm Letzten #endif.
1 | ATTRIBUTE_CLIB_SECTION
|
2 | void eeprom_write_block (const void *sram, void *eeprom_addr, size_t length) |
3 | {
|
4 | #if defined (NVM_EEMAPEN_bm)
|
5 | /* enable memory map. */
|
6 | NVM_CTRLB = NVM_CTRLB | NVM_EEMAPEN_bm; |
7 | #endif
|
8 | |
9 | while (length) |
10 | {
|
11 | uint8_t byte_position = ((uint16_t)eeprom_addr & (E2PAGESIZE-1)); |
12 | uint8_t nbytes = E2PAGESIZE - byte_position; |
13 | nbytes = nbytes > length ? length : nbytes; |
14 | eeprom_write_page ((uint8_t*)sram, (uint16_t)eeprom_addr, nbytes); |
15 | sram = (uint8_t*)sram + nbytes; |
16 | eeprom_addr = (uint8_t*)eeprom_addr + nbytes; |
17 | length -= nbytes; |
18 | }
|
19 | |
20 | #if defined (NVM_EEMAPEN_bm)
|
21 | /* disable memory map. */
|
22 | NVM_CTRLB = NVM_CTRLB & ~NVM_EEMAPEN_bm; |
23 | #endif
|
24 | }
|
25 | |
26 | #endif /* E2END && __AVR_XMEGA__ && E2PAGESIZE */ |
27 | #endif /* !__DOXYGEN__ */ |
:
Bearbeitet durch User
Veit D. schrieb: > Ich kann in der eewr_block_xmega.c keinen Klammerfehler erkennen. > Zeile 124 enthält die letzte Klammer der letzten Funktion. Vorm Letzten > #endif. Die Fehlermeldung sagt auch nichts vom einem Syntaxerror, sondern von einem ICE. Oliver
:
Bearbeitet durch User
Hallo, ja schon, wollte trotzdem der ersten Warnung/Error nachgehen so wie man das beim Programmieren macht. Jetzt triggert eine Datei der avr-libc einen Error, ähnlich der Print.cpp. Beim Wilhelm aber scheinbar nicht. Er hat ja den Patch bei sich schon lange eingebaut.
Veit D. schrieb: > Mit dem > letzten PR109476 gibt es ein Problem beim kompilieren. Hast Du origin/master, also 14.0.0 benutzt? Dort ist der Patch schon enthalten in einer verbesserten Version. Welchen Patch genau hast Du verwendet?
Veit D. schrieb: > eine generelle Frage zum Verständnis. Wie können sich solche Bugs > einschleichen? gute Frage, nächste Frage, erinnert mich an ein Prüfprogramm von mir was schon gut funktionierte und eine kleine Änderung und nichts lief mehr ein WE vor der Vorstellung sprich Typmusterprüfung. Also am WE am Werktor gerüttelt und gerufen lasst mich rein! Bedenke ein Programm was zu 90% fertig ist bleibt meisst bei 90% oder es funktioniert hinterher nicht 🤣
Wilhelm M. schrieb: > Veit D. schrieb: >> Mit dem >> letzten PR109476 gibt es ein Problem beim kompilieren. > > Hast Du origin/master, also 14.0.0 benutzt? > Dort ist der Patch schon enthalten in einer verbesserten Version. > Welchen Patch genau hast Du verwendet? Hallo, Ich habe gcc 12.2.0 mit dem Angehängten gepatcht.
Veit D. schrieb: > Ich habe gcc 12.2.0 mit dem Angehängten gepatcht. Ah ok. Die erste Version von Roger hatte tatsächlich noch Probleme. Die hatte ich auch gefunden bei meinen Tests zusammen mit ihm. Nimm git master, da ist die verbesserte Version drin (oder hol die aus dem angegebenen commit das diff als patch und wende es auf 12.2. an. DAs sollte funktionieren, da an dem betroffenen File wohl seit dre Zeit wenig bis nichts geändert wurde. Ist aber nur jetzt eine Vermutung). Es spricht aber kaum etwas dagegen, git master zu nehmen. Und wenn Du bugs findest, und ein MCVE erzeugst, dann freuen sich auch andere.
Hallo, ich blick da echt nicht durch. Ich bin in diesem Forumsbeitrag. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 Gehe nach ganz unten https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476#c18 Die ersten beiden Links führen zum gleichen Ziel. Das diff hatte ich verwendet. Also praktisch das diff von lower-subreg.cc. Ich weiß nicht was git master sein soll. Steht ja nirgends. Jetzt sehe ich am Ende der Seite https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=650c36ec461a722d9c65e82512b4c3aeec2ffee1;hp=fde00589911b5ff75ca167a45128d1d13fa76e57 noch einen Kleineren diff Eintrag. Sind das 2 getrennte Patches oder 2 in Einem? Edit: Das blob von gcc.target/avr/mmcu/pr109476.c kann ja kein Patch sein. Die Datei pr109476.c existiert ja gar nicht in der Toolchain. Ich blick echt nicht mehr durch. Würdest du mir bitte einen direkten Link zum korrekten Patch geben?
:
Bearbeitet durch User
Veit D. schrieb: > noch einen Kleineren diff Eintrag. > Sind das 2 getrennte Patches oder 2 in Einem? Ein Patch, der sich auf mehr als eine Datei auswirkt. Nichts besonderes. > Edit: > Das blob von gcc.target/avr/mmcu/pr109476.c kann ja kein Patch sein. Die > Datei pr109476.c existiert ja gar nicht in der Toolchain. Durch den Patch wird eine Datei erzeugt. In diesem Fall ein Testcase. > Ich blick echt nicht mehr durch. Würdest du mir bitte einen direkten > Link zum korrekten Patch geben? Den hast Du schon. Nur kann man den ggf. nicht auf die alten Sourcen vom 12.2. anwenden. Das diff was Du Dir aus dem Commit ziehst, ist eben für den master, und nicht für 12.2. Vielleicht solltest Du Dich mal grob mit dem Konzept der Versionsverwaltung beschäftigen. Ruhig gleich mit GIT statt mit subversion oder CVS. Da gibt es auch gute Dokus für die Basics. GIT ist schon sehr cool gemacht, jedenfalls im Vergleich zu Dinos wie SVN... Wie gesagt. mach ein clone vom git repo und compiliere das. Dann hast Du immer einen aktuellen gcc/avr-gcc. Und dann einfach zwischen durch mal ein git pull --recurse-submodules Und dann wieder compilieren. Ggf. vorher spezielle Patches anwenden (aber nur wenn Du sie tatsächlich brauchst). Wenn eine lokal gepatchte Datei dann durch git pull aktualisiert werden soll, merkst Du das und Du kannst ggf. etwaige Konflikte auflösen.
Veit D. schrieb: > Neu gespeichert, nur mit dos2unix behandelt, alles okay. > Danke. > (Warum ist das nur immer so unterschiedlich so umständlich ...) Wirf das Windows weg. Mit Windows kann man keine SW-Entwicklung betreiben.
Hallo, letzteres hat nichts mit Windows zu tun. Selbst mittels Standardtexteditor unter Ubuntu gespeichert muss ich die Dateien nachbehandeln. Ich wollte jetzt nicht den nagelneuen gcc 13 oder noch Gamma 14 nehmen. Ich möchte einfach den gcc 12.2.0 verwenden. Mal sehen was ich noch probieren kann. Danke erstmal. Edit: Womit programmierst du? Ich dachte mit Microchip Studio unter Windows?
:
Bearbeitet durch User
Hallo, ohne nachzuschauen, "git master" müßte doch gcc 13.1.0 sein. Ist ja der aktuelle gcc. Damit bricht übrigens mein Toolchainbau auch ab. Gleiche Fehlermeldung. Wenn PR109476 für gcc 12.3 und 13.2 passen soll stimmt doch irgendwas nicht.
Veit D. schrieb: > Hallo, > > letzteres hat nichts mit Windows zu tun. Selbst mittels > Standardtexteditor unter Ubuntu gespeichert muss ich die Dateien > nachbehandeln. Dann machst Du irgendetwas fundamentales falsch. > Edit: > Womit programmierst du? Ich dachte mit Microchip Studio unter Windows? Wahlweise QtCreator oder Code als IDE, alles seit (fast) immer unter Linux, davor SunOS bzw. Solaris, FreeBSD, ... Aber Windoofs, nein danke. Ist mir alles viel zu umständlich.
Veit D. schrieb: > Hallo, > > ohne nachzuschauen, "git master" müßte doch gcc 13.1.0 sein. Nein, seit ein paar Tagen: 14.0.0 > Ist ja der > aktuelle gcc. Damit bricht übrigens mein Toolchainbau auch ab. Gleiche > Fehlermeldung. Wenn PR109476 für gcc 12.3 und 13.2 passen soll stimmt > doch irgendwas nicht. git master compiliert bei mir wunderbar und wie gesagt ist dort PR109476 schon gemerged.
Veit D. schrieb: > Das blob von gcc.target/avr/mmcu/pr109476.c kann ja kein Patch sein. > Die Datei pr109476.c existiert ja gar nicht in der Toolchain. Ein Patch kann Dateien entfernen und hinzufügen. Wär auch ziemlich blöde, wenn das nicht so wäre. > Würdest du mir bitte einen direkten Link zum korrekten Patch geben? Laut ChangeLogs gibt es für PR109476 nur ein einzigen Commit. Veit D. schrieb: > Hallo, > > hatte Probleme beim kompilieren, habe nochmal von vorn angefangen und > jeden einzeln reingepatched und jeweils kompilieren lassen. Mit dem > letzten PR109476 gibt es ein Problem beim kompilieren. > >
1 | > avr-gcc -DHAVE_CONFIG_H -I.../avr-libc/avr/devices/atxmega8e5 |
2 | > -I.../avr-libc/common -I.../avr-libc/include -I../../../include -Wall |
3 | > -W -Wstrict-prototypes -mmcu=atxmega8e5 -mcall-prologues -Os -MT |
4 | > eewr_block_xmega.o -MD -MP -MF .deps/eewr_block_xmega.Tpo -c -o |
5 | > eewr_block_xmega.o |
6 | > .../avr-libc/libc/misc/eewr_block_xmega.c |
7 | > .../avr-libc/libc/misc/eewr_block_xmega.c: In |
8 | > function 'eeprom_write_block': |
9 | > .../avr-libc/libc/misc/eewr_block_xmega.c:124:1: |
10 | > error: unrecognizable insn: |
11 | > 124 | } |
12 | > | ^ |
13 | > (insn 89 88 58 12 (set (concatn:HI [ |
14 | > (reg:QI 93) |
15 | > (reg:QI 94 [+1 ]) |
16 | > ]) |
17 | > (reg:HI 96)) |
18 | > ".../avr-libc/libc/misc/eewr_block_xmega.c":92:36 |
19 | > -1 |
20 | > (nil)) |
21 | > during RTL pass: subreg1 |
22 | > .../avr-libc/libc/misc/eewr_block_xmega.c:124:1: |
23 | > internal compiler error: in extract_insn, at recog.cc:2791 |
24 | > |
> > Ich kann in der eewr_block_xmega.c keinen Klammerfehler erkennen. Ist auch keiner. Es handelt sich um einen Internal Compiler Error (ICE), also einen Bug in GCC selbst. Sieht ähnlich aus wie der ICE, den Wilhelm nach dem Patch für PR109476 beobachtet hat: Verweist auf RTL Pass "subreg1", zu welchem lower-subreg.cc gehört, und ist was mit "(concatn:HI [(reg:QI *) (reg:QI *)])". Diagnostics werden normalerweise während der syntaktischen Analyse des Quellcodes getriggert. Diese ist aber lange abgeschlossen, und der Lacation-Poninter zeigt auf das Ende der Funktion, in welcher der ICE auftrat.
Veit D. schrieb: > Wenn PR109476 für gcc 12.3 und 13.2 passen soll stimmt > doch irgendwas nicht. PR109476 war ein recht unbedeutender Codezuwachs verglichen mit älteren GCC. Soweit ich sehe, wurde der Patch nicht rückportiert auf v13 oder v12, und bei dem "Ausmaß" des PR ist das auch nicht zu erwarten. PR109476 weist nur einen einzigen Commit auf für master (future v14). Ich weiß auch nicht, wie der getestet wurde. Veit D. schrieb: > Du meinst, wenn ich Toolchains bauen kann und irgendwann Patches > vernünftig darin einpflegen kann, dann könnte ich Patches testen? Ja. Man testet den Compiler einmal ohne das Patch und einmal damit und vergleicht, was sich an FAILs ändert: Idealerweise nix. An Software brauchst du DejaGNU, Expect und Tcl. Dafür gibt es Packages. Für Laufzeittests braucht's noch nen Simulator: avrtest. https://sourceforge.net/p/winavr/code/HEAD/tree/trunk/avrtest/ Im README gibt's nen Abschnitt > "Running avr-gcc testsuite using avrtest simulator" der genau beschreibt, die man die Testsuite mit avrtest laufen lässt. avrtest bringt "Board"-Beschreibungen für mehrer wesentlich unterschiedliche AVR Devices mit: ATmega103, ATmega128, ATmega2560, ATmega8, ATtiny40, ATmega64, ATtiny3216 und ATxmega128A3. Normal reicht es, die Testsuite für ein Device laufen zu lassen wie ATmega128.
:
Bearbeitet durch User
Hallo, Danke Johann für die näheren Infos, auch wenn ich nur einen Teil verstehe hilft das für mein Verständnis. Den avrtest schaue ich mir an, aber nicht gleich morgen. ;-)
Ich hab mir den PR109650 der falschen Code generiert mal genauer angeschaut. Es ist ein Problem des AVR-Backend, das seit der Umstellung des ConditionCodes besteht, also für v12+. Einziger momentaner Workaround ist, den entsprechenden avr Pass per -fdisable-rtl-mach zu deaktivieren.
Beitrag #7408020 wurde von einem Moderator gelöscht.
Beitrag #7408041 wurde von einem Moderator gelöscht.
Beitrag #7408119 wurde von einem Moderator gelöscht.
Beitrag #7408212 wurde von einem Moderator gelöscht.
Beitrag #7408421 wurde von einem Moderator gelöscht.
Beitrag #7408606 wurde von einem Moderator gelöscht.
Beitrag #7409265 wurde von einem Moderator gelöscht.
Beitrag #7409376 wurde von einem Moderator gelöscht.
Beitrag #7409433 wurde von einem Moderator gelöscht.
Beitrag #7409570 wurde von einem Moderator gelöscht.
Beitrag #7409929 wurde von einem Moderator gelöscht.
Inzwischen gibt's Release v12.3.
Beitrag #7410196 wurde von einem Moderator gelöscht.
Beitrag #7410198 wurde von einem Moderator gelöscht.
Beitrag #7410348 wurde von einem Moderator gelöscht.
Hallo, ich sehe beim 12.3. keine Änderungen für AVR. Bedeutet das er ist zum 12.2. unverändert? Abgesehen von den reinen Sprach Features bzw. dessen Bugfixes. Dann würde ich die gleichen 2 Patches einbauen und mal testen ... Eine generelle Frage zum Patchstand. Wie kann ich einsehen welche gcc Version welchen Patch enthalten hat? Oder muss man alle Changelogs für jede Version raussuchen und durchsuchen? Die Bugliste je gcc Version ist nicht das was ich meine. Ich suche sowas wie eine Tabelle wo man nach Target (AVR) und gcc Version filtern kann. Wo dann nur die eingebauten Bugfixes / PRs zu sehen sind. Irgendwann verliert man ja den Überblick welcher Patch ab welcher Version geplant ist und falls sich das verschiebt dann nicht mehr stimmt wenn man in den PRs mitliest.
Beitrag #7410583 wurde von einem Moderator gelöscht.
Beitrag #7410632 wurde von einem Moderator gelöscht.
Hallo, hab den avr-gcc 12.3.0 inkl. Patches bauen lassen, funktioniert erstmal so weit. avrtest mach ich noch ... ;-)
Beitrag #7410903 wurde von einem Moderator gelöscht.
Beitrag #7412402 wurde von einem Moderator gelöscht.
Beitrag #7413087 wurde von einem Moderator gelöscht.
Beitrag #7413188 wurde von einem Moderator gelöscht.
Beitrag #7414681 wurde von einem Moderator gelöscht.
Beitrag #7414869 wurde von einem Moderator gelöscht.
Beitrag #7414939 wurde von einem Moderator gelöscht.
Hallo, DejaGNU, Expect und Tcl sind installiert. Scheinbar verstehe mal wieder die Beschreibung nicht. Verzeichnisbaum: /home/ubuntixer/Dokumente/
1 | ├── avr-gcc-linux |
2 | ├── avr-gcc-win |
3 | └── avrtest |
relevanter Inhalt von .dejagnurc
1 | set avrtest_dir "/home/ubuntixer/Dokumente/avrtest" |
2 | set avrlibc_include_dir "/home/ubuntixer/Dokumente/avr-gcc-linux/avr/include" |
3 | set boards_dir {}
|
4 | lappend boards_dir "${avrtest_dir}/dejagnuboards"
|
Ich befinde mich in: /home/ubuntixer/Dokumente/avrtest
1 | ubuntixer@ubuntixer:~/Dokumente/avrtest$ make |
2 | avr-gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp |
3 | make: avr-gcc: Datei oder Verzeichnis nicht gefunden |
4 | make: *** [Makefile:169: exit-atmega8.o] Fehler 127 |
oder
1 | ubuntixer@ubuntixer:~/Dokumente/avrtest$ make clean-exit all CC_FOR_AVR=../avr-gcc-linux/ |
2 | rm -f |
3 | ../avr-gcc-linux/ -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp |
4 | make: ../avr-gcc-linux/: Keine Berechtigung |
5 | make: *** [Makefile:169: exit-atmega8.o] Fehler 127 |
Was mach ich jetzt wieder falsch? Irgendwie raff ich das nicht. An den Zugriffsrechten der Ordner kann es nicht liegen. Die sind mit chmod extra nochmal auf 777 geändert wurden. Hilft aber auch nicht.
Veit D. schrieb:1 | > ubuntixer@ubuntixer:~/Dokumente/avrtest$ make |
2 | > avr-gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o |
3 | > -save-temps=obj -dp |
4 | > make: avr-gcc: Datei oder Verzeichnis nicht gefunden |
5 | > make: *** [Makefile:169: exit-atmega8.o] Fehler 127 |
Es muss ein avr-gcc im Pfad sein, d.h. wenn du avr-gcc in dem Verzeichnis ausführst, dann sollte kommen:
1 | $ avr-gcc |
2 | avr-gcc: fatal error: no input files |
3 | compilation terminated. |
> Verzeichnisbaum: /home/ubuntixer/Dokumente/1 | > ├── avr-gcc-linux |
2 | > ├── avr-gcc-win |
3 | > └── avrtest |
Im weiteren kommt es dann darauf, an, ob das Build- oder
Install-Verzeichnisse sind; ich gehe mal von ersterem aus.
> relevanter Inhalt von .dejagnurc1 | > set avrtest_dir "/home/ubuntixer/Dokumente/avrtest" |
2 | > set avrlibc_include_dir |
3 | > "/home/ubuntixer/Dokumente/avr-gcc-linux/avr/include" |
4 | > set boards_dir {}
|
5 | > lappend boards_dir "${avrtest_dir}/dejagnuboards"
|
Ok, also ist /home/ubuntixer/Dokumente/avr-gcc-linux ein
Install-Verzeichnis?
> Ich befinde mich in: /home/ubuntixer/Dokumente/avrtest1 | > ubuntixer@ubuntixer:~/Dokumente/avrtest$ make clean-exit all |
2 | > CC_FOR_AVR=../avr-gcc-linux/ |
Ein Compiler ist kein Verzeichnis. Also etwa CC_FOR_AVR=avr-gcc-5.4.0 wenn es einen solchen gibt. Falls es noch kein installierten avr-gcc im System gibt, aber einen in einem Build-Verzeichnis namens "$build", dann geht
1 | CC_FOR_AVR="$build/gcc/xgcc -B $build/gcc" |
Was natürlich auch geht, ist einen Pfad zu einem irgendwo installierten avr-gcc anzugeben, dann brauch's keine Option -B.
:
Bearbeitet durch User
Beitrag #7415741 wurde vom Autor gelöscht.
Hallo,
1 | ubuntixer@ubuntixer:~/Dokumente/avr-gcc-linux$ avr-gcc |
2 | Der Befehl 'avr-gcc' wurde nicht gefunden, kann aber installiert werden mit: |
3 | sudo apt install gcc-avr |
In avr-gcc-linux und avr-gcc-win liegen meine selbstgebauten avr-gcc Toolchains. Habe die Namen gekürzt wegen Tipparbeit. Sorry. Nur warum soll ich einen installierten avr-gcc testen? Ich dachte ich soll meine Eigenen gebauten testen? Installiert ist noch keiner. Teste ich mit deiner erwähnten Option passiert erstmal nichts, wiederholt passiert was aber am Ende wieder Zugriffsfehler.
1 | ubuntixer@ubuntixer:~/Dokumente/avrtest$ make clean-exit all CC_FOR_AVR=../avr-gcc-linux/lib/gcc -B ../avr-gcc-linux/lib/gcc" |
2 | > make clean-exit all CC_FOR_AVR=../avr-gcc-linux/lib/gcc -B ../avr-gcc-linux/lib/gcc" |
3 | rm -f |
4 | gcc -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic -S avrtest.c -o avrtest.s |
5 | gcc -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic -c options.c -o options.o |
6 | ... |
7 | ... |
8 | gcc -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic -S avrtest.c -o avrtest-tiny.s -DISA_TINY |
9 | gcc avrtest-tiny.s -o avrtest-tiny options.o load-flash.o flag-tables.o host.o -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic |
10 | gcc -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic -S avrtest.c -o avrtest-tiny_log.s -DAVRTEST_LOG -DISA_TINY |
11 | gcc avrtest-tiny_log.s -o avrtest-tiny_log options.o load-flash.o flag-tables.o host.o logging.o graph.o perf.o -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic -lm |
12 | ../avr-gcc-linux/lib/gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp |
13 | make: ../avr-gcc-linux/lib/gcc: Keine Berechtigung |
14 | make: *** [Makefile:169: exit-atmega8.o] Fehler 127 |
Alles nochmal auf Anfang, avr-gcc installieren und nochmal frisch testen?
Beitrag #7415803 wurde von einem Moderator gelöscht.
Veit D. schrieb: > In avr-gcc-linux und avr-gcc-win liegen meine selbstgebauten avr-gcc > Toolchains. Habe die Namen gekürzt wegen Tipparbeit. Sorry. > Nur warum soll ich einen installierten avr-gcc testen? Du bekamst den Fehler beim make von avrtest, und der braucht eben einen avr-gcc, um Module wie exit-atmega128.o zu generieren. Dabei geht es (noch) nicht darum, den Compiler selbst zu testen, sondern um avrtest zu generieren. Die Module werden später in Lauftests gelinkt, damit sich exit() und abort() so verhalten, wie avrtest es erwartet. > Ich dachte ich soll meine Eigenen gebauten testen? Ja aber zum avrtest generieren brauchst du einen avr-gcc. Wenn noch kein avr-gcc installiert ist, dann nimm den aus dem Build-Verzeichnis für einen native-cross avr-gcc (also kein canadian cross, weil ein avr-gcc.exe auf linux nicht läuft). Wenn dein Build-Verzeichnis z.B. $build heißt, dann kannst du den da generierten und noch nicht installierten avr-gcc verwenden per
1 | make CC_FOR_AVR="$build/gcc/xgcc -B $build/gcc" |
> Teste ich mit deiner erwähnten Option passiert erstmal nichts, > wiederholt passiert was aber am Ende wieder Zugriffsfehler. Dazu muss $build natürlich den richtigen Wert haben. Du kannst auch einen pfad direkt verwenden, ist dann aber mehr Tipparbeit. Getestet wird da noch nichts, es geht darum, avrtest zu generieren.
1 | > CC_FOR_AVR=../avr-gcc-linux/lib/gcc -B ../avr-gcc-linux/lib/gcc" |
Du hast das falsch abgeschrieben und das xgcc vergessen. Richtig:
1 | CC_FOR_AVR="../avr-gcc-linux/lib/gcc/xgcc -B ../avr-gcc-linux/lib/gcc" |
Wobei es etwas seltsam ist, ein Build-Verzeichnis auf /lib enden zu lassen. Aber ok, ist Geschmackssache.
...und wenn avr-gcc-linux eine Install-Verzeichnis ist, in welches bereits erfolgreich installiert wurde, dann geht auch:
1 | CC_FOR_AVR=".../avr-gcc-linux/bin/avr-gcc" |
Hallo, Danke. Das hat sich jetzt zeitlich überschnitten. Ich hatte vorhin das alte Ding von gcc-avr für Ubuntu installiert. Auch damit kam ein Fehler. Habs wieder deinstalliert. Dann weiter schlau gemacht die PATH Variable auf meine gebaute Toolchain gesetzt.
1 | ubuntixer@ubuntixer:~/Dokumente/avrtest$ export PATH="/home/ubuntixer/Dokumente/avr-gcc-linux/bin:$PATH" |
2 | ubuntixer@ubuntixer:~/Dokumente/avrtest$ which avr-gcc |
3 | /home/ubuntixer/Dokumente/avr-gcc-linux/bin/avr-gcc |
danach für avrtest 'make' ausgeführt und
1 | ubuntixer@ubuntixer:~/Dokumente/avrtest$ make |
2 | avr-gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp |
3 | avr-gcc -Os -mmcu=atmega168 -I. dejagnuboards/exit.c -c -o exit-atmega168.o -save-temps=obj -dp |
4 | ... |
5 | ... |
6 | avr-gcc -Os -mmcu=attiny3216 -I. dejagnuboards/exit.c -c -o exit-attiny3216.o -save-temps=obj -dp |
7 | avr-gcc: error: device-specs/specs-attiny3216: No such file or directory |
8 | make: *** [Makefile:169: exit-attiny3216.o] Fehler 1 |
Damit kann ich umgehen. Muss noch die Device Specs usw. hinzufügen. Das machte ich bisher immer nur meine Windows Toolchains. Das hätte jetzt mit der installierten von Ubuntu auch nicht funktioniert. Ich mach morgen weiter und lese mir nochmal alles von dir durch. Ich denke das wird schon ... :-)
Hallo, mein gebauter avr-gcc 7.5.0 ist wohl doch zu alt dafür. Da fehlt die gesamte avrxmega3 Architektur. Habe kurzerhand meinen avr-gcc 8.5.0 genommmen. Damit läuft make für avrtest schon einmal fehlerfrei durch. Erstmal Luft holen und durchatmen. Ist es später wichtig mit welcher avr-gcc Version avrtest gebaut wurde?
Beitrag #7415957 wurde von einem Moderator gelöscht.
Beitrag #7415979 wurde von einem Moderator gelöscht.
Veit D. schrieb:1 | > avr-gcc -Os -mmcu=attiny3216 -I. dejagnuboards/exit.c -c -o |
2 | > exit-attiny3216.o -save-temps=obj -dp |
3 | > avr-gcc: error: device-specs/specs-attiny3216: No such file or directory |
4 | > make: *** [Makefile:169: exit-attiny3216.o] Fehler 1 |
5 | > |
Den Fehler kannst du ignorieren, es sei denn du willst die Tests für ATtiny3216 ausführen. Oder im Makefile das Device entfernen. Veit D. schrieb: > mein gebauter avr-gcc 7.5.0 ist wohl doch zu alt dafür. Da fehlt die > gesamte avrxmega3 Architektur. Dann kannst du dafür eben nicht testen. Normal testet man avr-gcc gegen ATmega128. Es sei denn man hat architekturspezifische Erweiterungen am Compiler gemacht; dann würde man z.B. gegen Classic, Xmega, reduced Tiny etc. testen. > Ist es später wichtig mit welcher avr-gcc Version avrtest gebaut wurde? avrtest selbst wird ja mit gcc gebaut. avr-gcc brauch man nur für's exit Modul. Also nein, die Version spielt keine Rolle. exit.c ist nicht wirklich kompliziert. Es implementiert ein paar Streams so dass printf-Ausgaben per Syscall auf dem Host landen. Du kannst also printf ("Hallo Welt!\n"); machen und die Ausgabe erscheint aufm Host.
Beitrag #7416080 wurde von einem Moderator gelöscht.
Beitrag #7416128 wurde von einem Moderator gelöscht.
Hallo Johann, Danke zwischendurch mal wieder. :-) "Hello World" und "inout" funktioniert schon einmal mit atmega128. Jetzt muss ich mir erstmal ordentliche Notizen machen nach dem Motto "Was bisher geschah ... " :-) :-)
:
Bearbeitet durch User
Beitrag #7416184 wurde von einem Moderator gelöscht.
Beitrag #7416185 wurde von einem Moderator gelöscht.
Hallo, mittlerweile habe ich mir eine Batch zusammengebaut. Problem ist das Hello World funktioniert nicht mit dem ATmega2560. Das müßte aber doch mit allen enthaltenen MCUs in avrtest funktionieren. Oder nicht? atmega8 und atmega168 funktionieren.
1 | #!/bin/bash
|
2 | |
3 | PREFIX=$HOME/avrTestSuite/ |
4 | |
5 | # export PREFIX
|
6 | PATH=$PATH:$PREFIX/avrtest/ |
7 | PATH=$PATH:$PREFIX/avr-gcc-linux |
8 | PATH=$PATH:$PREFIX/avr-gcc-linux/bin |
9 | # export PATH
|
10 | |
11 | cd $PREFIX |
12 | |
13 | NAME_MCU="atmega2560" |
14 | echo "$NAME_MCU" |
15 | avr-gcc hello.c -O -mmcu=$NAME_MCU -o hello.elf avrtest/exit-$NAME_MCU.o |
16 | avrtest hello.elf |
17 | |
18 | NAME_MCU="atmega128" |
19 | echo "$NAME_MCU" |
20 | avr-gcc hello.c -O -mmcu=$NAME_MCU -o hello.elf avrtest/exit-$NAME_MCU.o |
21 | avrtest hello.elf |
Ausgabe
1 | atmega2560 |
2 | |
3 | exit status: ABORTED |
4 | reason: opcode 0x9419 illegal on avr51 |
5 | program: hello.elf |
6 | exit address: 0001ae |
7 | total cycles: 365 |
8 | total instr.: 221 |
9 | |
10 | atmega128 |
11 | Hallo World! |
12 | |
13 | exit status: EXIT |
14 | reason: exit 0 function called |
15 | program: hello.elf |
16 | exit address: 0001a8 |
17 | total cycles: 831 |
18 | total instr.: 494 |
Veit D. schrieb: > atmega2560 > > exit status: ABORTED > reason: opcode 0x9419 illegal on avr51 ATmega2560 ist avr6 und hat einen anderen Befehlssatz als ATmega128, also:
1 | avrtest -mmcu=avr6 hello.elf |
0x9419 codiert für EIJMP, das kennt ATmega128 nicht. Siehe zum Beispiel README oder avrtest --help. Die Granularität von -mmcu= ist nicht die gleiche wie bei avr-gcc, und für bestimmte Familien wie XMEGA braucht's avrtest-xmega. Siehe abermals README. Der Unterschied ist i.w. 2-Byte PC für avr51 vs. 3-Byte PC für avr6. Das muss man zum Beispiel bei Simulation von Funktionsaufrufen und RET beachten; daher können ATmega128 und ATmega2560 nicht im gleichen Set sein. ATmega8 funktioniert, weil der Compiler nur eine Teilmenge von avr51 generiert. Beim Ausführen der Testsuite braucht man sich darum nicht zu kümmern, das erledigt alles die Board-Beschreibung. Für ATmega2560 ist das dejagnuboards/atmega2560-sim.exp:
1 | set mmcu "atmega2560" |
2 | set avrtest_mmcu "avr6" |
Überblick gibt dejagnuboards/gen-exp.sh Die Auswahl des richtigen Simulators erledigt dejagnuboards/avrtest.exp::sim_load().
:
Bearbeitet durch User
Hallo,
Danke. Darauf wäre ich nie gekommen. Weil wenn man explizit den mmcu Typ
angibt geht man davon aus das der Rest automatisch passt. Ansonsten
müßte man beim atmega128 auch mmcu=avr51 angeben statt atmega128. Ist
ehrlich gesagt nicht ganz logisch für mich. Naja gut was solls.
Was ich auch schon lange fragen wollte ist. Warum heißt das Teil
'winavr' wenn man es nur unter Linux testen kann? Ganz zu Beginn hatte
ich nämlich versucht das unter Windows ans Laufen zubekommen. Nur dafür
fehlten die zusätzlichen Tools. ;-)
Nachdem das jetzt bei mir soweit funktioniert. Wofür verwendest du das?
Was kann ich damit zukünftig besser testen? Weil bisher hatte ich
Stichprobenartig meine Toolchains mit AS7 bzw. Microchip Studio und
danach mit der Arduino IDE getestet. Einen Pin von Port B getoggelt der
bei allen zur Verfügung steht. Wenn das kompilieren fehlerfrei lief
wußte ich zumindestens das alle notwendigen Dateien vorhanden sind bzw.
die Toolchain pauschal gesehen okay ist.
Edit:
Für den ATtiny3216 funktioniert das wieder nicht.
Die mmcu Option avrxmega3 kennt avrtest nicht.
avrxmega3 steht jedoch in der .sh und in der echten Toolchain ist der
ATtiny3216 auch in avrxmega3 einsortiert.
Belasse ich alles auf Standard kommt kein Fehler aber auch kein Hello
World.
Übrigens funktioniert bei mir weder
> avrtest --help noch --h
Ich kann nur das Readme File oder online nachlesen.
:
Bearbeitet durch User
Veit D. schrieb: > Was ist denn mit dem avr-gcc 12.x passiert? Da geht ja fast nichts. Ich hab das jetzt wirklich nur kurz überflogen, aber wenn ich das richtig sehe, benutzen alle Compiler-Aufrufe "-f lto": Link Time Optimization. Am Ende der Fehlermeldungen steht allerdings immer was "lto-wrapper failed". Vielleicht den Parameter mal weglassen und dann nochmal versuchen? Nur so eine blöde Idee... und, wie gesagt: nicht wirklich geguckt.
Beitrag #7416522 wurde von einem Moderator gelöscht.
Beitrag #7416528 wurde von einem Moderator gelöscht.
Beitrag #7416651 wurde von einem Moderator gelöscht.
Beitrag #7416654 wurde von einem Moderator gelöscht.
Sheeva P. schrieb:
Vielleicht wäre es besser gewesen länger im Thread zu lesen. Bei langen
Threads wie diesen ist es nie eine gute Idee mittenrein zu platzen ohne
den Thread zu kennen.
Veit D. schrieb: > Hallo, > > Danke. Darauf wäre ich nie gekommen. Weil wenn man explizit den mmcu Typ > angibt geht man davon aus das der Rest automatisch passt. Ansonsten > müßte man beim atmega128 auch mmcu=avr51 angeben statt atmega128. Ist > ehrlich gesagt nicht ganz logisch für mich. Naja gut was solls. Du kannst natürlich auch "avrtest -mmcu=avr51 hello.elf" wenn das ELF für ATmega128 erstellt wurde; in dem Fall ist -mmcu=avr51 aber redundant. > Was ich auch schon lange fragen wollte ist. Warum heißt das Teil > 'winavr' wenn man es nur unter Linux testen kann? Das Repo ist das von WinAVR; die letzte Release war 2010. Irgendwie ist damals anfang der 2000'er avrtest im Repo von WinAVR gelandet. Mit der Geschichte davon kenn ich mich nicht aus, das müsste Jörg wissen. > Ganz zu Beginn hatte ich nämlich versucht das unter Windows ans > Laufen zubekommen. Nur dafür fehlten die zusätzlichen Tools. ;-) winavr sollte auch unter Windows laufen. Man braucht allerdings einen GCC zum Übersetzen (und einen avr-gcc für exit.c). > Nachdem das jetzt bei mir soweit funktioniert. Wofür verwendest du das? Zum Testen von avr-gcc, siehe README "Running avr-gcc testsuite using avrtest simulator" > Weil bisher hatte ich Stichprobenartig meine Toolchains mit AS7 bzw. > Microchip Studio und danach mit der Arduino IDE getestet. Du verwendest Microchip Studio und Arduino um die GCC Regression Test laufen zu lassen? > Für den ATtiny3216 funktioniert das wieder nicht. > Die mmcu Option avrxmega3 kennt avrtest nicht. Wie ich bereits schrieb (und im README erklärt ist): Für Xmega wird avrtest-xmega verwendet: avrtest-xmega --help: > ARCH is one of: avrxmega6 avrxmega3 avrxmega7 Die Auswahl übernimmt avrtest.exp. > Übrigens funktioniert bei mir weder >> avrtest --help noch --h Seltsam. Eigentlich sollte --help, -help, -h, -?, ? alle funktionieren (aber nicht --h). Was kommt denn für eine Ausgabe / Fehlermeldung?
Beitrag #7416768 wurde von einem Moderator gelöscht.
Beitrag #7416771 wurde von einem Moderator gelöscht.
Hallo, >> Weil bisher hatte ich Stichprobenartig meine Toolchains mit AS7 bzw. >> Microchip Studio und danach mit der Arduino IDE getestet. > Du verwendest Microchip Studio und Arduino um die GCC Regression Test > laufen zu lassen? Nein, hatte ich auch nicht behauptet. Wie gesagt ich teste damit nur meine Toolchains auf allgemeine Funktion. ATtiny3216 funktioniert nun mit folgendem Kommando.
1 | > avrtest-xmega -mmcu=avrxmega3 hello.elf |
Wegen Help Option, es funktioniert nichts.
1 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --help |
2 | Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
3 | Befehl 'avctest' aus dem deb avce00 (2.0.0-8) |
4 | Versuche: sudo apt install <deb name> |
5 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest -help |
6 | Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
7 | Befehl 'avctest' aus dem deb avce00 (2.0.0-8) |
8 | Versuche: sudo apt install <deb name> |
9 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest -h |
10 | Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
11 | Befehl 'avctest' aus dem deb avce00 (2.0.0-8) |
12 | Versuche: sudo apt install <deb name> |
13 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --h |
14 | Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
15 | Befehl 'avctest' aus dem deb avce00 (2.0.0-8) |
16 | Versuche: sudo apt install <deb name> |
17 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest -? |
18 | Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
19 | Befehl 'avctest' aus dem deb avce00 (2.0.0-8) |
20 | Versuche: sudo apt install <deb name> |
21 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest ? |
22 | Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
23 | Befehl 'avctest' aus dem deb avce00 (2.0.0-8) |
24 | Versuche: sudo apt install <deb name> |
25 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --? |
26 | Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
27 | Befehl 'avctest' aus dem deb avce00 (2.0.0-8) |
28 | Versuche: sudo apt install <deb name> |
Veit D. schrieb: > Der Befehl 'avrtest' wurde nicht gefunden Wenn das avrtest -Programm nicht gefunden wird, ist es völlig unerheblich was du für Argumente (-help, --help, -h ... ) übergibst, die gehen ins Nirvana.
Veit D. schrieb: > Wegen Help Option, es funktioniert nichts.
1 | > ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --help |
2 | > Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie: |
Vermutlich is ~/avrTestSuite/avrtest nicht in PATH. Aufruf ist dann:
1 | ./avrtest --help |
Veit D. schrieb: > ATtiny3216 funktioniert nun mit folgendem Kommando.> avrtest-xmega > -mmcu=avrxmega3 hello.elf > > Wegen Help Option, es funktioniert nichts. avrtest-xmega geht ohne absolute/relative Pfadangabe? Schau doch mal mit "find", wo avr-test sich befindet bzw. ob es überhaupt vorhanden ist. P.S.: Und Fehlermeldungen lesen ;-)
:
Bearbeitet durch User
Hallo, also Leute ich bin ja nicht ganz blöd. Ich befinde ich direkt im Verzeichnis von avrtest. Das muss demzufolge gefunden werden.
1 | ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ ls |
2 | AUTHORS exit-atmega8.o fileio-atxmega128a1.i |
3 | avr51-flash1.x exit-atmega8.s fileio-atxmega128a1.o |
4 | avr-opcode.def exit-attiny3216.i fileio-atxmega128a1.s |
5 | avrtest exit-attiny3216.o fileio-atxmega128a3.i |
6 | avrtest.c exit-attiny3216.s fileio-atxmega128a3.o |
7 | avrtest.h exit-attiny40.i fileio-atxmega128a3.s |
8 | avrtest_log exit-attiny40.o fileio.h |
9 | avrtest_log.s exit-attiny40.s flag-tables.c |
10 | avrtest.s exit-atxmega128a1.i flag-tables.h |
11 | avrtest-tiny exit-atxmega128a1.o flag-tables.o |
12 | avrtest-tiny_log exit-atxmega128a1.s gen-flag-tables.c |
13 | avrtest-tiny_log.s exit-atxmega128a3.i graph.c |
14 | avrtest-tiny.s exit-atxmega128a3.o graph.h |
15 | avrtest-xmega exit-atxmega128a3.s graph.o |
16 | avrtest-xmega_log fileio-atmega103.i host.c |
17 | avrtest-xmega_log.s fileio-atmega103.o host.h |
18 | avrtest-xmega.s fileio-atmega103.s host.o |
19 | avrtiny-rodata.x fileio-atmega128.i load-flash.c |
20 | BUGS fileio-atmega128.o load-flash.o |
21 | ChangeLog fileio-atmega128.s logging.c |
22 | COPYING fileio-atmega168.i logging.h |
23 | dejagnuboards fileio-atmega168.o logging.o |
24 | exit-atmega103.i fileio-atmega168.s Makefile |
25 | exit-atmega103.o fileio-atmega2560.i NEWS |
26 | exit-atmega103.s fileio-atmega2560.o options.c |
27 | exit-atmega128.i fileio-atmega2560.s options.def |
28 | exit-atmega128.o fileio-atmega8.i options.h |
29 | exit-atmega128.s fileio-atmega8.o options.o |
30 | exit-atmega168.i fileio-atmega8.s perf.c |
31 | exit-atmega168.o fileio-attiny3216.i perf.h |
32 | exit-atmega168.s fileio-attiny3216.o perf.o |
33 | exit-atmega2560.i fileio-attiny3216.s README |
34 | exit-atmega2560.o fileio-attiny40.i sreg.h |
35 | exit-atmega2560.s fileio-attiny40.o testavr.h |
36 | exit-atmega8.i fileio-attiny40.s |
Moin, Veit D. schrieb: > Das muss demzufolge gefunden werden. Dann solltest du
1 | ./avrtest |
schreiben, damit's "gefunden" wird. Gruss WK
Veit D. schrieb: > also Leute ich bin ja nicht ganz blöd. Ich befinde ich direkt im > Verzeichnis von avrtest. Naja... Dann musst du es auch mit "./avrtest" starten, nicht nur mit "avrtest". Ohne die Anführungsstriche.
Hallo,
warum muss man das ./ machen wenn man schon im richtigen Verzeichnis
ist?
> ./avrtest --help
Ist zwar nicht ganz logisch für mich aber funktioniert. Danke.
Veit D. schrieb: > warum muss man das ./ machen wenn man schon im richtigen Verzeichnis > ist? Das ist eine der Fragen, die sich seit jeher jeder Linux-Einsteiger stellt, der das erste Mal davor sitzt. Von der Sorte gibts noch jede Menge mehr. Nach ein paar Jahren hat sich das dann eingeprägt. Oliver
Veit D. schrieb: > warum muss man das ./ machen wenn man schon im richtigen > Verzeichnis ist? >> ./avrtest --help Siehe Beitrag "Re: Was ist mit dem avr-gcc 12.x passiert? Internal Compiler Errors" Das Verzeichnis ist offenbar nicht in PATH. Das hat auch nix mit avrtest zu tun, sondern trifft auf alle Programme zu.
Hallo, so richtig warm werde ich mit Linux vermutlich nie werden. ;-) Befindet man sich ein Verzeichnis davor reicht ohne ./, weil relativ.
1 | ubuntixer@ubuntixer:~/avrTestSuite$ avrtest/avrtest --help |
Johann L. schrieb: > Veit D. schrieb: >> warum muss man das ./ machen wenn man schon im richtigen >> Verzeichnis ist? >>> ./avrtest --help > > Siehe > Beitrag "Re: Was ist mit dem avr-gcc 12.x passiert? Internal Compiler Errors" > > Das Verzeichnis ist offenbar nicht in PATH. Das hat auch nix mit > avrtest zu tun, sondern trifft auf alle Programme zu. Das Detail hatte ich übersehen. Nur wird nicht zuerst dort gesucht wo man sich befindet und danach wird die PATH Variable durchgegangen? Es bleibt aufregend. :-) :-)
:
Bearbeitet durch User
Veit D. schrieb: > Nur wird nicht zuerst dort gesucht wo man sich befindet und danach wird > die PATH Variable durchgegangen? Nein, das ist in MS-DOS und Nachfolgern so. In Unixoiden wird nur in $PATH gesucht. Es steht dir natürlich frei, "." In PATH aufzunehmen. Um böse Überraschungen zu vermeiden, sollte es aber an letzter Stelle in PATH stehen.
:
Bearbeitet durch Moderator
Hallo, okay, dann macht das wieder Sinn das meine Batch mit PATH setzen funktioniert und ohne nicht. Muss ich mir merken das nur PATH gilt. Danke.
Beitrag #7419353 wurde von einem Moderator gelöscht.
Hallo, gibt es für den avr-gcc 8.5 noch wichtige Patches die man einbauen sollte?
Das eine mir bekannte Problem mit v8 ist PR101188, für welches es aber kein Patch gibt.
:
Wiederhergestellt durch Moderator
Hallo, wenn ich das so lese scheint das Problem auch nicht einfach zu lösen zu sein. Generell gefragt. Gibt es eine Übersicht welche Patches es für welche avr-gcc Version gibt? In der Versiondoku steht ja drin welcher Patch eingebaut bzw. übernommen wurde. Mich würde interessieren ob es eine Übersicht gibt über Patches die existieren aber nicht eingebaut wurden weil keine neue avr-gcc Version herauskam bzw. nie mehr rauskommen wird. Oder noch anders gefragt wie behälst du den Überblick welcher Patch wo drin ist, welcher aktuell wichtig wäre und wann dieser im nächsten avr-gcc drin ist?
Veit D. schrieb: > Gibt es eine Übersicht welche Patches es für welche avr-gcc > Version gibt? Nicht dass ich wüsste. Üblicherweise werden die Patches ja eingebaut. Und wenn das mal nicht der Fall ist wie zum Beispiel bei PR49857 oder PR92606, ich weiß nicht ob man da anfangen will, das selber zu maintainen. > Oder noch anders gefragt wie behälst du den Überblick welcher Patch > wo drin ist, welcher aktuell wichtig wäre und wann dieser im nächsten > avr-gcc drin ist? Bei einem PR schreib ich das dazu. Üblicherweise macht man Backports ja zeitnah, und wenn man das erledigt hat ist er PR fertig. Welche Versionen gerade aktuell sind sieht man an den GIT HEADs; für die gefixte Version zählt man dann einfach 1 drauf.
:
Wiederhergestellt durch Moderator
Hallo, ich frage nochmal anders. Wenn ich nicht hier zufällig über die Patches für 12.2, 12.3 und 13.1 gestolpert wäre hätte ich davon nie etwas mitbekommen das es sie gibt. Eingebaut werden sie erst in 14. Solange muss man sie in 12 und 13 einbauen. Nur wenn man davon nichts weiß kann man sie nicht einbauen. Das sind die Gedanken um die es bei mir im Moment dreht. Und es wird sicherlich noch für ältere avr-gcc Patches geben die nicht mehr zum Einbau kommen aber vorhanden sind aber selbst eingebaut werden können. Nehme ich einmal an.
Beitrag #7421782 wurde von einem Moderator gelöscht.
Beitrag #7421887 wurde von einem Moderator gelöscht.
Beitrag #7421896 wurde von einem Moderator gelöscht.
Beitrag #7421923 wurde von einem Moderator gelöscht.
Beitrag #7422058 wurde von einem Moderator gelöscht.
Beitrag #7422169 wurde von einem Moderator gelöscht.
Aus irgendeinem Grund werden meine Antworten von den Moderatoren gelöscht. Über eine Erklärung würde ich mich freuen.
Johann L. schrieb: > Aus irgendeinem Grund werden meine Antworten von den Moderatoren > gelöscht. Über eine Erklärung würde ich mich freuen. Vermutlich hast du auf ein Posting von Moby geantwortet. Das darfst du nicht tun. Selbst wenn dein Posting eine umfassende Theorie enthält, die Quantenmechanik und ART plausibel zusammenführt, ist das den Moderatoren dann scheißegal. Das Forum in jeglicher Hinsicht Moby-frei zu halten, hat für die weitaus mehr Gewicht. Allerdings: auch ich habe den Fehler mal gemacht. In der Löschnotifikation stand dann aber eindeutig der Grund drin. Sehr ungewöhnlich. Normalerweise wird ohne Angabe von Gründen gelöscht. Da kannst du mal sehen, welch hohe Priorität der Kampf gegen Moby bei den Moderatoren wohl haben muss.
Beitrag #7422280 wurde von einem Moderator gelöscht.
Beitrag #7422308 wurde von einem Moderator gelöscht.
Beitrag #7422337 wurde von einem Moderator gelöscht.
Beitrag #7422349 wurde von einem Moderator gelöscht.
Beitrag #7422367 wurde von einem Moderator gelöscht.
Beitrag #7422485 wurde von einem Moderator gelöscht.
Veit D. schrieb: > ich frage nochmal anders. Wenn ich nicht hier zufällig über die Patches > für 12.2, 12.3 und 13.1 gestolpert wäre hätte ich davon nie etwas > mitbekommen das es sie gibt. Eingebaut werden sie erst in 14. Solange > muss man sie in 12 und 13 einbauen. Nur wenn man davon nichts weiß kann > man sie nicht einbauen. Ja. Was ist jetzt deine Frage? Wenn du deine eigene Toolchain maintainen willst, dann ist das natürlich mit einem gewissen Aufwand verbunden. Du kannst dich bei GCC Bugzilla anmelden und für PRs, die dich interessieren ins CC setzen. Dann bekommst du Änderungen am und Kommentare zum Bug etc. mit. Du kannst dich bei der gcc-patches Mailing-List anmelden und schauen, ob es da interessante Sachen gibt. Einen magischen Weg, wie du mitbekommst, ob irgendwer in irgendeinem Forum einen Patch bespricht, kenne ich nicht. > Und es wird sicherlich noch für ältere avr-gcc Patches geben die > nicht mehr zum Einbau kommen aber vorhanden sind aber selbst > eingebaut werden können. Nehme ich einmal an. Zu WinAVR Zeiten wurden auch Patches dort maintained; was vergleichbares gibt's heute nicht. MicroChip fährt da ne ganz andere Policy. C-hater schrieb: > Vermutlich hast du auf ein Posting von Moby geantwortet. Nein. Es wurde aus Versehen gelöscht und ist sofort wieder hergestellt worden. Und ich bin auch nicht der richtige Ansprechpartner für jemanden, der professionelle Hilfe benötigt.
:
Bearbeitet durch User
Beitrag #7422584 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten