Was ist mit dem avr-gcc 12.x passiert? Internal Compiler Errors

[Veit D. (devil-elec)]

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.

[Oliver S. (oliverso)]

Ist das einer von deinen selbstgebauten avr-gccs?

Oliver

[Veit D. (devil-elec)]

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.

[sketch (Gast)]

Du hast vermutlich versucht einen Sketch von Ilja Richter zu 
compilieren. Die sind unverdaulich.

[Rolf M. (rmagnus)]

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

[Veit D. (devil-elec)]

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?

[Kaj (Gast)]

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

[Veit D. (devil-elec)]

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?

[Rolf M. (rmagnus)]

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.

[Veit D. (devil-elec)]

Hallo,

Danke für die Auskunft.

[Veit D. (devil-elec)]

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?

[Johann L. (gjlayde)]

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.

[Motopick (motopick)]

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.

[Johann L. (gjlayde)]

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.

[Wilhelm M. (wimalopaan)]

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).

[Veit D. (devil-elec)]

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.

[Johann L. (gjlayde)]

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.

[Veit D. (devil-elec)]

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.

compiler.path=C:\avrToolchain\avr-gcc-12.2.0_mingw32_binutils2.40_avrLibc2.1GitHub/bin/
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
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.

struct Daten
{
  int8_t dir;
  int32_t rel;
};
Daten enc;

void setup (void)
{
  Serial.begin(9600);
  Serial.println(F("\nuC Reset"));
  Serial.println(enc.dir);
  Serial.println(enc.rel);
}

void loop (void)
{ }

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

during RTL pass: combine
C:\Arduino IDE Portable\Mega2560\arduino-1.8.19\portable\packages\arduino\hardware\avr\1.8.6\cores\arduino\main.cpp: In function 'main':
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
   51 | }
      | ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using -freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper.exe: fatal error: C:\avrToolchain\avr-gcc-12.2.0_mingw32_binutils2.40_avrLibc2.1GitHub/bin/avr-gcc returned 1 exit status
compilation terminated.
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
collect2.exe: error: ld returned 1 exit status
exit status 1
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.

[Jack V. (jackv)]

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.

[Markus W. (dl8mby)]

@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

[Veit D. (devil-elec)]

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.

[Markus W. (dl8mby)]

Bist Du aus dem u.g. Link

https://github.com/arduino/arduino-builder/issues/332

schlauer geworden?

Markus

[Johann L. (gjlayde)]

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.

[Wf88 (wf88)]

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.

[Wilhelm M. (wimalopaan)]

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

--param=min-pagesize=0

beheben kannst.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

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.

[Oliver S. (oliverso)]

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

[Wilhelm M. (wimalopaan)]

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.

[Veit D. (devil-elec)]

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.

[Oliver S. (oliverso)]

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

[Johann L. (gjlayde)]

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:

avr-g++ -mmcu=atmega328 -flto ... -fpreprocessed modul1.ii -o modul1.o
avr-g++ -mmcu=atmega328 -flto ... -fpreprocessed modul2.ii -o modul2.o
...
avr-g++ -mmcu=atmega328 -flto ... -fpreprocessed modulN.ii -o modulN.o
avr-g++ -mmcu=atmega328 -flto ... -o final.elf modul1.o modul2.o ...

Dürfte doch kein Hexenwerk sein?

[Veit D. (devil-elec)]

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.

[Wilhelm M. (wimalopaan)]

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 ;-)

[Johann L. (gjlayde)]

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

typedef __UINT8_TYPE__ uint8_t;

[Johann L. (gjlayde)]

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.

[Wilhelm M. (wimalopaan)]

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

[Johann L. (gjlayde)]

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.

[Veit D. (devil-elec)]

Hallo,

Danke Johann, ich denke damit lässt sich arbeiten.  :-)

[Veit D. (devil-elec)]

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?

[Wilhelm M. (wimalopaan)]

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?

[Veit D. (devil-elec)]

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.

[Wilhelm M. (wimalopaan)]

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?

[Veit D. (devil-elec)]

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

[Johann L. (gjlayde)]

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:

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

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.

[Veit D. (devil-elec)]

Hallo,

Danke für deine Zeit. Ich versuche es hinzubekommen.

[Veit D. (devil-elec)]

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.  :-)

[Johann L. (gjlayde)]

Kannst du nicht von Kommanozeile aus so aufrufen?

avr-g++ [options] *.cpp -o result.elf

[Veit D. (devil-elec)]

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 ...

[Veit D. (devil-elec)]

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

gcc 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 . . .

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

[Oliver S. (oliverso)]

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

[Johann L. (gjlayde)]

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:

> jar xf arduino_build_962106.zip
> cd arduino_build_962106
> 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
during RTL pass: combine
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':
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
0x7fe390ff3d8f __libc_start_call_main
  ../sysdeps/nptl/libc_start_call_main.h:58
0x7fe390ff3e3f __libc_start_main_impl
  ../csu/libc-start.c:392
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: avr-gcc-14 returned 1 exit status
compilation terminated.
.../bin/../lib/gcc/avr/14.0.0/../../../../avr/bin/ld: error: lto-wrapper failed
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

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:

> 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.

[Johann L. (gjlayde)]

...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:

// -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.

Wer's nachvollziehen will, hier ist der verwendete "interestingness 
test" für C-Reduce:

#!/usr/bin/bash

avr-g++-14 Print-ii.cpp -mmcu=atmega328 -Os -fsyntax-only -Wall -Wextra -Werror >& say1.txt

if [ $? = 1 ]; then
    exit 1
fi

avr-g++-14 Print-ii.cpp -mmcu=atmega328 -O2 -c -Wall -Wextra >& say2.txt

if [ $? = 0 ]; then
    exit 1
fi

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.

[Wilhelm M. (wimalopaan)]

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.

[C-hater (c-hater)]

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...

[Johann L. (gjlayde)]

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.

[Veit D. (devil-elec)]

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

struct Daten {
  int8_t dir;
  int32_t rel;
};
Daten enc;

void setup (void) {
  Serial.begin(9600);
  Serial.println(F("\nuC Reset"));
  Serial.println(enc.dir);
  Serial.println(enc.rel);
}

void loop (void)
{ }

und das kompiliert ohne Abbruch.

struct Daten {
  int8_t dir;
  int32_t rel;
};
Daten enc;

void setup (void) {
  Serial.begin(9600);
  Serial.println(F("\nuC Reset"));
  Serial.println(enc.dir);
}

void loop (void)
{ }

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?

[Veit D. (devil-elec)]

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.

[Wilhelm M. (wimalopaan)]

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(...)).

[Veit D. (devil-elec)]

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.

int16_t dir;  // oder beide unsigned
int16_t rel;  // 

void setup (void) {
  Serial.begin(9600);
  Serial.println(F("\nuC Reset"));
  Serial.println(dir);
  Serial.println(rel);
}

void loop (void)
{ }

Ist eine von beiden signed und die andere unsigned funktioniert es.

uint32_t dir;  // oder signed / unsigned vertauscht
int32_t rel;   //

void setup (void) {
  Serial.begin(9600);
  Serial.println(F("\nuC Reset"));
  Serial.println(dir);
  Serial.println(rel);
}

void loop (void)
{ }

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.

[Veit D. (devil-elec)]

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.

uint16_t dir;
uint32_t rel;
-----------------
uint16_t dir;
uint8_t rel;
-----------------
uint16_t dir;
uint32_t rel;

Haben beide unsigned gleiche Datenbreite funktioniert es nicht mehr.

[Johann L. (gjlayde)]

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.

[Veit D. (devil-elec)]

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.

[Wilhelm M. (wimalopaan)]

Du kannst einfach den Patch aus dem PR nehmen und Dir damit einen 
avr-gcc selbst bauen. Dann bist Du das Problem los.

[Johann L. (gjlayde)]

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

[Veit D. (devil-elec)]

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?

[Oliver S. (oliverso)]

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

[Johann L. (gjlayde)]

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

$ patch -p NUM < pr105753.diff

wobei NUM davon abhängt wo der aktuelle Pfad ist relativ zur Zieldatei 
avr.md.

[Wilhelm M. (wimalopaan)]

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?

[Veit D. (devil-elec)]

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!

[Johann L. (gjlayde)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Johann L. (gjlayde)]

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.

[Wilhelm M. (wimalopaan)]

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...

[Veit D. (devil-elec)]

Hallo,

das klingt nicht gerade Vertrauens erweckend. Man könnte denke man 
dürfte den gcc ab 11 nicht mehr verwenden.

[Johann L. (gjlayde)]

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?

[Veit D. (devil-elec)]

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?

[Johann L. (gjlayde)]

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?

[Veit D. (devil-elec)]

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

/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.

/home/ubuntixer/toolchain/Patches

Wenn ich mich auf der Kommandozeile in /Patches befinde und eingebe

> patch -p3 < pr105753.diff

Dann geht er laut Beschreibung 3 von links auf /toolchain zurück. Wie 
soll dann der Pfad zu

/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?

[Johann L. (gjlayde)]

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

diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md
index 43b75046384..610fedcf59c 100644
--- a/gcc/config/avr/avr.md
+++ b/gcc/config/avr/avr.md
...

Man stellt sich also ins GCC Quellverzeichnis und dann

$ 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.

[Oliver S. (oliverso)]

Johann L. schrieb:
> …

Du hast die Antwort auf die letzte Frage vergessen.

Oliver

[Wilhelm M. (wimalopaan)]

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?).

[Veit D. (devil-elec)]

Hallo,

ich habe das mit patch command und den Pfadangaben heute nochmal 
probiert. pr105753 funktioniert. Alles mit gcc 12.2.0

> patch -p1 < ../../Patches/pr105753.diff

ubuntixer@ubuntixer:~/toolchain/downloads/gcc$ patch -p1 < /home/ubuntixer/toolchain/Patches/pr105753.diff 
patching file gcc/config/avr/avr.md
Hunk #1 succeeded at 3755 (offset 1 line).
Hunk #2 succeeded at 4091 (offset 1 line).
Hunk #3 succeeded at 4140 (offset 1 line).
Hunk #4 succeeded at 4191 (offset 1 line).
Hunk #5 succeeded at 4238 (offset 1 line).

Aber pr105532 und pr109476 funktioniert nicht.

ubuntixer@ubuntixer:~/toolchain/downloads/gcc$ patch -p1 < /home/ubuntixer/toolchain/Patches/pr109476.diff
patching file gcc/lower-subreg.cc
Hunk #3 succeeded at 1380 with fuzz 1.
Hunk #4 FAILED at 1687.
1 out of 4 hunks FAILED -- saving rejects to file gcc/lower-subreg.cc.rej

ubuntixer@ubuntixer:~/toolchain/downloads/gcc$ patch -p1 < /home/ubuntixer/toolchain/Patches/pr105532.diff
(Stripping trailing CRs from patch; use --binary to disable.)
patching file gcc/config/avr/avr.cc
(Stripping trailing CRs from patch; use --binary to disable.)
patching file gcc/testsuite/gcc.target/avr/torture/pr105523.c
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 43:

Sind meine Patchfiles fehlerhaft?

[Oliver S. (oliverso)]

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

[Veit D. (devil-elec)]

Hallo,

in der pr105532.diff steht

41 +void func (void)
42 +{
43 +    SFR = 1;
44 +}

in der zu patchenden avr.cc steht

41 #include "emit-rtl.h"
42 #include "recog.h"
43 #include "conditions.h"
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.

[Oliver S. (oliverso)]

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

[Veit D. (devil-elec)]

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 
...

[Veit D. (devil-elec)]

Hallo,

Zwischeninfo. Nach Behandlung mit dos2unix hat es mit pr105532 
funktioniert.

patching file gcc/config/avr/avr.cc
patching file gcc/testsuite/gcc.target/avr/torture/pr105523.c

Nur pr109476 sträubt sich noch ... mal schauen ...

[Veit D. (devil-elec)]

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 ...)

[Veit D. (devil-elec)]

Hallo,

gibt es noch einen wichtigen Patch für gcc 12.2.0?

[Veit D. (devil-elec)]

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.

make[4]: Verzeichnis „/home/ubuntixer/toolchain/buildLinux/avr-libc/avr/devices/atmega256rfr2“ wird verlassen
make[3]: Verzeichnis „/home/ubuntixer/toolchain/buildLinux/avr-libc/avr/devices/atmega256rfr2“ wird verlassen
Making install in atxmega8e5
make[3]: Verzeichnis „/home/ubuntixer/toolchain/buildLinux/avr-libc/avr/devices/atxmega8e5“ wird betreten
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
../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c: In function 'eeprom_write_block':
../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c:124:1: error: unrecognizable insn:
  124 | }
      | ^
(insn 89 88 58 12 (set (concatn:HI [
                (reg:QI 93)
                (reg:QI 94 [+1 ])
            ])
        (reg:HI 96)) "../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c":92:36 -1
     (nil))
during RTL pass: subreg1
../../../../../downloads/avr-libc/libc/misc/eewr_block_xmega.c:124:1: internal compiler error: in extract_insn, at recog.cc:2791
0x7f0367029d8f __libc_start_call_main
  ../sysdeps/nptl/libc_start_call_main.h:58
0x7f0367029e3f __libc_start_main_impl
  ../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.

ATTRIBUTE_CLIB_SECTION
void eeprom_write_block (const void *sram, void *eeprom_addr, size_t length)
{
  #if defined (NVM_EEMAPEN_bm)
    /* enable memory map.  */
    NVM_CTRLB = NVM_CTRLB | NVM_EEMAPEN_bm;
  #endif

  while (length)
  {
    uint8_t byte_position = ((uint16_t)eeprom_addr & (E2PAGESIZE-1));
    uint8_t nbytes = E2PAGESIZE - byte_position;
    nbytes = nbytes > length ? length : nbytes;
    eeprom_write_page ((uint8_t*)sram, (uint16_t)eeprom_addr, nbytes);
    sram = (uint8_t*)sram + nbytes;
    eeprom_addr = (uint8_t*)eeprom_addr + nbytes;
    length -= nbytes;
  }

  #if defined (NVM_EEMAPEN_bm)
    /* disable memory map.  */
    NVM_CTRLB = NVM_CTRLB & ~NVM_EEMAPEN_bm;
  #endif
}

#endif  /* E2END && __AVR_XMEGA__ && E2PAGESIZE */
#endif  /* !__DOXYGEN__ */

[Oliver S. (oliverso)]

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

[Veit D. (devil-elec)]

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.

[Wilhelm M. (wimalopaan)]

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?

[Joachim B. (jar)]

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 🤣

[Veit D. (devil-elec)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Veit D. (devil-elec)]

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?

[Wilhelm M. (wimalopaan)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Veit D. (devil-elec)]

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?

[Veit D. (devil-elec)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Johann L. (gjlayde)]

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.
>
>

> avr-gcc -DHAVE_CONFIG_H -I.../avr-libc/avr/devices/atxmega8e5
> -I.../avr-libc/common -I.../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 
> .../avr-libc/libc/misc/eewr_block_xmega.c
> .../avr-libc/libc/misc/eewr_block_xmega.c: In 
> function 'eeprom_write_block':
> .../avr-libc/libc/misc/eewr_block_xmega.c:124:1: 
> error: unrecognizable insn:
>   124 | }
>       | ^
> (insn 89 88 58 12 (set (concatn:HI [
>                 (reg:QI 93)
>                 (reg:QI 94 [+1 ])
>             ])
>         (reg:HI 96)) 
> ".../avr-libc/libc/misc/eewr_block_xmega.c":92:36 
> -1
>      (nil))
> during RTL pass: subreg1
> .../avr-libc/libc/misc/eewr_block_xmega.c:124:1: 
> internal compiler error: in extract_insn, at recog.cc:2791
>

>
> 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.

[Johann L. (gjlayde)]

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.

[Veit D. (devil-elec)]

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.  ;-)

[Johann L. (gjlayde)]

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.

[Johann L. (gjlayde)]

Inzwischen gibt's Release v12.3.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

Hallo,

hab den avr-gcc 12.3.0 inkl. Patches bauen lassen, funktioniert erstmal 
so weit. avrtest mach ich noch ...  ;-)

[Veit D. (devil-elec)]

Hallo,

DejaGNU, Expect und Tcl sind installiert.
Scheinbar verstehe mal wieder die Beschreibung nicht.
Verzeichnisbaum: /home/ubuntixer/Dokumente/

├── avr-gcc-linux
├── avr-gcc-win
└── avrtest

relevanter Inhalt von .dejagnurc

set avrtest_dir "/home/ubuntixer/Dokumente/avrtest"
set avrlibc_include_dir "/home/ubuntixer/Dokumente/avr-gcc-linux/avr/include"
set boards_dir {}
lappend boards_dir "${avrtest_dir}/dejagnuboards"

Ich befinde mich in:  /home/ubuntixer/Dokumente/avrtest

ubuntixer@ubuntixer:~/Dokumente/avrtest$ make
avr-gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp
make: avr-gcc: Datei oder Verzeichnis nicht gefunden
make: *** [Makefile:169: exit-atmega8.o] Fehler 127

oder

ubuntixer@ubuntixer:~/Dokumente/avrtest$ make clean-exit all CC_FOR_AVR=../avr-gcc-linux/
rm -f 
../avr-gcc-linux/ -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp
make: ../avr-gcc-linux/: Keine Berechtigung
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.

[Johann L. (gjlayde)]

Veit D. schrieb:

> ubuntixer@ubuntixer:~/Dokumente/avrtest$ make
> avr-gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o 
> -save-temps=obj -dp
> make: avr-gcc: Datei oder Verzeichnis nicht gefunden
> 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:

$ avr-gcc
avr-gcc: fatal error: no input files
compilation terminated.

> Verzeichnisbaum: /home/ubuntixer/Dokumente/

> ├── avr-gcc-linux
> ├── avr-gcc-win
> └── avrtest

Im weiteren kommt es dann darauf, an, ob das Build- oder 
Install-Verzeichnisse sind; ich gehe mal von ersterem aus.

> relevanter Inhalt von .dejagnurc

> set avrtest_dir "/home/ubuntixer/Dokumente/avrtest"
> set avrlibc_include_dir 
> "/home/ubuntixer/Dokumente/avr-gcc-linux/avr/include"
> set boards_dir {}
> 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/avrtest

> ubuntixer@ubuntixer:~/Dokumente/avrtest$ make clean-exit all 
> 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

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.

[Veit D. (devil-elec)]

Hallo,

ubuntixer@ubuntixer:~/Dokumente/avr-gcc-linux$ avr-gcc
Der Befehl 'avr-gcc' wurde nicht gefunden, kann aber installiert werden mit:
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.

ubuntixer@ubuntixer:~/Dokumente/avrtest$ make clean-exit all CC_FOR_AVR=../avr-gcc-linux/lib/gcc -B ../avr-gcc-linux/lib/gcc"
> make clean-exit all CC_FOR_AVR=../avr-gcc-linux/lib/gcc -B ../avr-gcc-linux/lib/gcc"
rm -f 
gcc -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic   -S avrtest.c -o avrtest.s 
gcc -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic   -c options.c -o options.o
...
...
gcc -O3 -fomit-frame-pointer -std=c99 -dp -W -Wall -Wno-unused-parameter -pedantic   -S avrtest.c -o avrtest-tiny.s -DISA_TINY
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   
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
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
../avr-gcc-linux/lib/gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp
make: ../avr-gcc-linux/lib/gcc: Keine Berechtigung
make: *** [Makefile:169: exit-atmega8.o] Fehler 127

Alles nochmal auf Anfang, avr-gcc installieren und nochmal frisch
testen?

[Johann L. (gjlayde)]

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

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.

> CC_FOR_AVR=../avr-gcc-linux/lib/gcc -B ../avr-gcc-linux/lib/gcc"

Du hast das falsch abgeschrieben und das xgcc vergessen. Richtig:

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.

[Johann L. (gjlayde)]

...und wenn avr-gcc-linux eine Install-Verzeichnis ist, in welches 
bereits erfolgreich installiert wurde, dann geht auch:

CC_FOR_AVR=".../avr-gcc-linux/bin/avr-gcc"

[Veit D. (devil-elec)]

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.

ubuntixer@ubuntixer:~/Dokumente/avrtest$ export PATH="/home/ubuntixer/Dokumente/avr-gcc-linux/bin:$PATH"
ubuntixer@ubuntixer:~/Dokumente/avrtest$ which avr-gcc
/home/ubuntixer/Dokumente/avr-gcc-linux/bin/avr-gcc

danach für avrtest 'make' ausgeführt und

ubuntixer@ubuntixer:~/Dokumente/avrtest$ make
avr-gcc -Os -mmcu=atmega8 -I. dejagnuboards/exit.c -c -o exit-atmega8.o -save-temps=obj -dp
avr-gcc -Os -mmcu=atmega168 -I. dejagnuboards/exit.c -c -o exit-atmega168.o -save-temps=obj -dp
...
...
avr-gcc -Os -mmcu=attiny3216 -I. dejagnuboards/exit.c -c -o exit-attiny3216.o -save-temps=obj -dp
avr-gcc: error: device-specs/specs-attiny3216: No such file or directory
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 ...  :-)

[Veit D. (devil-elec)]

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?

[Johann L. (gjlayde)]

Veit D. schrieb:

> avr-gcc -Os -mmcu=attiny3216 -I. dejagnuboards/exit.c -c -o 
> exit-attiny3216.o -save-temps=obj -dp
> avr-gcc: error: device-specs/specs-attiny3216: No such file or directory
> make: *** [Makefile:169: exit-attiny3216.o] Fehler 1
>

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.

[Veit D. (devil-elec)]

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 ... "   :-)  :-)

[Veit D. (devil-elec)]

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.

#!/bin/bash

PREFIX=$HOME/avrTestSuite/

# export PREFIX
PATH=$PATH:$PREFIX/avrtest/
PATH=$PATH:$PREFIX/avr-gcc-linux
PATH=$PATH:$PREFIX/avr-gcc-linux/bin
# export PATH

cd $PREFIX

NAME_MCU="atmega2560" 
echo "$NAME_MCU"
avr-gcc hello.c -O -mmcu=$NAME_MCU -o hello.elf avrtest/exit-$NAME_MCU.o
avrtest hello.elf

NAME_MCU="atmega128" 
echo "$NAME_MCU"
avr-gcc hello.c -O -mmcu=$NAME_MCU -o hello.elf avrtest/exit-$NAME_MCU.o
avrtest hello.elf

Ausgabe

atmega2560

 exit status: ABORTED
      reason: opcode 0x9419 illegal on avr51
     program: hello.elf
exit address: 0001ae
total cycles: 365
total instr.: 221

atmega128
Hallo World!

 exit status: EXIT
      reason: exit 0 function called
     program: hello.elf
exit address: 0001a8
total cycles: 831
total instr.: 494

[Johann L. (gjlayde)]

Veit D. schrieb:
> atmega2560
>
>  exit status: ABORTED
>       reason: opcode 0x9419 illegal on avr51

ATmega2560 ist avr6 und hat einen anderen Befehlssatz als ATmega128, 
also:

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:

set mmcu "atmega2560"
set avrtest_mmcu "avr6"

Überblick gibt dejagnuboards/gen-exp.sh

Die Auswahl des richtigen Simulators erledigt 
dejagnuboards/avrtest.exp::sim_load().

[Veit D. (devil-elec)]

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.

[Sheeva P. (sheevaplug)]

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.

[Veit D. (devil-elec)]

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.

[Johann L. (gjlayde)]

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?

[Veit D. (devil-elec)]

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.

> avrtest-xmega -mmcu=avrxmega3 hello.elf

Wegen Help Option, es funktioniert nichts.

ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --help
Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:
  Befehl 'avctest' aus dem deb avce00 (2.0.0-8)
Versuche: sudo apt install <deb name>
ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest -help
Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:
  Befehl 'avctest' aus dem deb avce00 (2.0.0-8)
Versuche: sudo apt install <deb name>
ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest -h
Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:
  Befehl 'avctest' aus dem deb avce00 (2.0.0-8)
Versuche: sudo apt install <deb name>
ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --h
Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:
  Befehl 'avctest' aus dem deb avce00 (2.0.0-8)
Versuche: sudo apt install <deb name>
ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest -?
Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:
  Befehl 'avctest' aus dem deb avce00 (2.0.0-8)
Versuche: sudo apt install <deb name>
ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest ?
Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:
  Befehl 'avctest' aus dem deb avce00 (2.0.0-8)
Versuche: sudo apt install <deb name>
ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --?
Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:
  Befehl 'avctest' aus dem deb avce00 (2.0.0-8)
Versuche: sudo apt install <deb name>

[Niklas G. (erlkoenig)]

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.

[Johann L. (gjlayde)]

Veit D. schrieb:
> Wegen Help Option, es funktioniert nichts.

> ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ avrtest --help
> Der Befehl 'avrtest' wurde nicht gefunden, meinten Sie:

Vermutlich is ~/avrTestSuite/avrtest nicht in PATH.  Aufruf ist dann:

./avrtest --help

[Wilhelm M. (wimalopaan)]

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 ;-)

[Veit D. (devil-elec)]

Hallo,

also Leute ich bin ja nicht ganz blöd. Ich befinde ich direkt im 
Verzeichnis von avrtest. Das muss demzufolge gefunden werden.

ubuntixer@ubuntixer:~/avrTestSuite/avrtest$ ls
AUTHORS              exit-atmega8.o       fileio-atxmega128a1.i
avr51-flash1.x       exit-atmega8.s       fileio-atxmega128a1.o
avr-opcode.def       exit-attiny3216.i    fileio-atxmega128a1.s
avrtest              exit-attiny3216.o    fileio-atxmega128a3.i
avrtest.c            exit-attiny3216.s    fileio-atxmega128a3.o
avrtest.h            exit-attiny40.i      fileio-atxmega128a3.s
avrtest_log          exit-attiny40.o      fileio.h
avrtest_log.s        exit-attiny40.s      flag-tables.c
avrtest.s            exit-atxmega128a1.i  flag-tables.h
avrtest-tiny         exit-atxmega128a1.o  flag-tables.o
avrtest-tiny_log     exit-atxmega128a1.s  gen-flag-tables.c
avrtest-tiny_log.s   exit-atxmega128a3.i  graph.c
avrtest-tiny.s       exit-atxmega128a3.o  graph.h
avrtest-xmega        exit-atxmega128a3.s  graph.o
avrtest-xmega_log    fileio-atmega103.i   host.c
avrtest-xmega_log.s  fileio-atmega103.o   host.h
avrtest-xmega.s      fileio-atmega103.s   host.o
avrtiny-rodata.x     fileio-atmega128.i   load-flash.c
BUGS                 fileio-atmega128.o   load-flash.o
ChangeLog            fileio-atmega128.s   logging.c
COPYING              fileio-atmega168.i   logging.h
dejagnuboards        fileio-atmega168.o   logging.o
exit-atmega103.i     fileio-atmega168.s   Makefile
exit-atmega103.o     fileio-atmega2560.i  NEWS
exit-atmega103.s     fileio-atmega2560.o  options.c
exit-atmega128.i     fileio-atmega2560.s  options.def
exit-atmega128.o     fileio-atmega8.i     options.h
exit-atmega128.s     fileio-atmega8.o     options.o
exit-atmega168.i     fileio-atmega8.s     perf.c
exit-atmega168.o     fileio-attiny3216.i  perf.h
exit-atmega168.s     fileio-attiny3216.o  perf.o
exit-atmega2560.i    fileio-attiny3216.s  README
exit-atmega2560.o    fileio-attiny40.i    sreg.h
exit-atmega2560.s    fileio-attiny40.o    testavr.h
exit-atmega8.i       fileio-attiny40.s

[Dergute W. (derguteweka)]

Moin,

Veit D. schrieb:
> Das muss demzufolge gefunden werden.

Dann solltest du

./avrtest

 schreiben, damit's "gefunden" wird.

Gruss
WK

[Niklas G. (erlkoenig)]

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.

[Veit D. (devil-elec)]

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.

[Oliver S. (oliverso)]

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

[Johann L. (gjlayde)]

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.

[Veit D. (devil-elec)]

Hallo,

so richtig warm werde ich mit Linux vermutlich nie werden. ;-)
Befindet man sich ein Verzeichnis davor reicht ohne ./, weil relativ.

ubuntixer@ubuntixer:~/avrTestSuite$ avrtest/avrtest --help

[Veit D. (devil-elec)]

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.  :-)  :-)

[Yalu X. (yalu) (Moderator)]

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.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

Hallo,

gibt es für den avr-gcc 8.5 noch wichtige Patches die man einbauen 
sollte?

[Johann L. (gjlayde)]

Das eine mir bekannte Problem mit v8 ist PR101188, für welches es aber 
kein Patch gibt.

[Veit D. (devil-elec)]

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?

[Johann L. (gjlayde)]

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.

[Veit D. (devil-elec)]

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.

[Johann L. (gjlayde)]

Aus irgendeinem Grund werden meine Antworten von den Moderatoren 
gelöscht.  Über eine Erklärung würde ich mich freuen.

[C-hater (c-hater)]

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.

[Johann L. (gjlayde)]

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.