AVR removed in GCC 16 ?

[Thomas H. (thux)]

Hallo,

wenn ich das richtig verstehe wird der AVR Support in GCC 16 entfernt 
weil  das neue LRA nicht unterstützt wird?

>This is the last release supporting the old reload local register allocation 
code. It will be removed for GCC 16, causing targets that do not support the new 
LRA local register allocation code to be removed. See the list of supported 
targets for which ports are going to be affected (look for missing a, the ports 
that do not use LRA by default).

a       Port uses LRA (by default, i.e. unless overridden by a switch).

           |      Characteristics
Target     | HMSLQNFICBD lqrpbfmgiates
avr        |    L  FI    l  p   g

Verstehe ich das falsch oder muss jetzt etwas gemacht werden?

Grüße

https://gcc.gnu.org/gcc-15/changes.html
https://gcc.gnu.org/backends.html

[Johann L. (gjlayde)]

Thomas H. schrieb:
> wenn ich das richtig verstehe wird der AVR Support in GCC 16
> entfernt weil  das neue LRA nicht unterstützt wird?
> Verstehe ich das falsch oder muss jetzt etwas gemacht werden?

Immerhin wird -mlra unterstützt, ist aber nicht default weil es noch 
mindestens einen Fall gibt, wo LRA falschen Code erzeugt (mit -Os 
-mmcu=atmega8 -mlra):

__attribute__((noipa))
void func2 (long long a1, long long a2, long b)
{
  static unsigned char count = 0;
  if (b != count++)
    __builtin_abort ();
}

int main (void)
{
  for (long b = 0; b < 5; ++b)
    {
      __asm ("/* some reg pressure */" ::: "r5", "r9");
      func2 (0, 0, b);
    }

  return 0;
}

https://gcc.gnu.org/PR118591

[Thomas H. (thux)]

Ah danke, ich versuche am nächsten freien Tag mal etwas davon zu 
verstehen.

[Thomas H. (thux)]

Mein AVR ASM war etwas eingerostet, das habe ich nun aufgefrischt. Die 
Beispiele hab ich verstanden, auch den erzeugen ASM Code sowie den 
falsch erzeugten.
Mit -O1 wird denke ich kein falscher Code erzeugt und der 
vorgeschlagener Patch mit optimize_function_for_size_p() zielt auch auf 
eine Optimierung hin. Also werde ich mich mal weiter in die Richtung 
damit beschäftigen.

[Johann L. (gjlayde)]

Thomas H. schrieb:
> der vorgeschlagener Patch mit optimize_function_for_size_p()
> zielt auch auf eine Optimierung hin. Also werde ich mich mal weiter
> in die Richtung damit beschäftigen.

Das Patch wurde abgelehnt weil es nicht die Ursache behebt:

https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681859.html

[Johann L. (gjlayde)]

Thomas H. schrieb:

> avr        |    L  FI    l  p   g

> https://gcc.gnu.org/backends.html

avr hat jetzt ein a:

avr        |    L  FI    l  p   g a

[Thomas H. (thux)]

Da bin ich aber erleichtert. Vielen Dank für deine Mühen! (und auch die 
von vielen anderen).

Ich habe noch ein wenig im GCC Bugtracker mitgelesen. Das scheint ja 
doch etwas Architektur übergreifendes gewesen zu sein.

Was passiert mit den Architekturen die kein a haben? Das sind ja doch 
einige, auch wenn ich von vielen noch nie etwas gehört habe.

[Johann L. (gjlayde)]

Thomas H. schrieb:
> Was passiert mit den Architekturen die kein a haben?

Eine bessere Übersicht über Backends, die LRA nicht (per default) 
unterstützen), gibt der entsprechende PR: https://gcc.gnu.org/PR113932

Gibt mehrere Möglichkeiten:

* LRA wird optional unterstützt ist aber nicht Default (zB: sh, vax, 
pdp11):  Prinzipiell könnte man den LRA-Schalter umlegen und hätte ein 
"a" in backends.html.  Für vax gibt es aber Dinge, die nicht 
funktionieren.  Konkret genannt wird Exception Handler Unwinding (also 
C++ Exceptions).  Ganz übel sieht's für sh aus: 
https://gcc.gnu.org/PR55212 wo einem der Build mit aktiviertem LRA um 
die Ohren fliegt.

* backends.html ist nicht aktuell.  Diese Datei ist Teil der GCC 
Webseite und nicht Teil der GCC Quellen.  Ist also nicht ausgeschlossen, 
dass entsprechende Einträge nicht aktuell sind.  So wurden 
beispielsweise die tile* Backends aus GCC entfernt weil diese aus GlibC 
und Linux entfernt wurden (tile* unterstützte nur *-linux 
Konfigurationen), sind aber noch in backends gelistet.

Was schlussendlich passieren wird, etwa mit sh, vermag ich nicht zu 
sagen.  Da bleiben auch mir nur Kristallkugel und Popkorn.  Für eine 
informiertere Antwort kannst du in der gcc@ Mailing Liste fragen: 
https://gcc.gnu.org/mailman/listinfo/gcc