AVR-GCC 4.8.1: unrecognizable insn

[Walter T. (nicolas)]

Hallo zusammen,

nach einer Rechner-Neuinstallation hat mir Atmel-Studio den AVR-GCC 
4.8.1 untergeschoben, mit dem ein Altprojekt, das mit AVR-GCC 4.7.2 noch 
problemlos lief, mit dem Fehler "unrecognizable insn" den Build 
abbricht.

Zurückführen konnte ich alles auf die folgende Zeile (von deren Typ es 
mehrere gibt):

snprintf_P(glstr_Buf,N_TEXTBUF,menudata[item].menutext,\
          *menudata[item].puint8);

Nicht zum Fehler führt die folgende Abwandlung mit einem konstanten 
String im Flash:

snprintf_P(glstr_Buf,N_TEXTBUF,PSTR("u=%u"),\
        *menudata[item].puint8);

Das Struct "menudata" ist etwas komplizierter aufgebaut:

// Header
    #define constflash const __flash

  enum datatype_e {
        nothing,
    voidFcn,
    uint8,
    uint16,
    int8,
    int16
  };


__extension__ typedef struct {
      constflash char *menutext; 
      enum datatype_e datatype;   // Datentyp des Zeigers "pointer"
                           
        union {
            voidFcn_t pvoidFcn;     // Funktionszeiger
            uint8_t  *puint8;       // Zeiger auf Variablentypen
            uint16_t *puint16;
            int8_t   *pint8;
            int16_t  *pint16;
            void     *pvoid;
        };
      const int16_t varMin;       // Untere Grenze numerische Variable
      const int16_t varMax;       // Oberere Grenze numerische Variable
    } menudata_t;                   // Struct wird terminiert mit einer Zeile,
                                    // wo in .menutext ein Nulltext
                                    // ({'\0'}) steht.

// C-File
constflash char MT_SAVEANDRET[]    = "\033vspeichern\033f & \033vzurück\033f";
constflash char MT_Z_MAX_DEF[]     = "Z\033smax,norm    \033n : %3umm";
constflash char MT_VAR_LIFTTIM[]   = "t\033slift        \033n : %3us";
constflash char MT_VAR_LIFTHEI[]   = "Z\033slift        \033n : %3imm";




    

constflash menudata_t calibmenu[] = {
  {MT_SAVEANDRET   ,voidFcn,{.pvoid = NULL},0,0}, // Rueckgabewert interessant
  {MT_ABORT        ,voidFcn,{.pvoid = NULL},0,0}, // Rueckgabewert interessant
  {MT_Z_MAX_DEF    ,uint8  ,{.puint8=&gls_setting.z_max_default},Z_MAX_DEFAULT_MIN ,Z_MAX_DEFAULT_MAX },
  {MT_VAR_LIFTTIM  ,uint8  ,{.puint8=&gls_setting.lift_time}    ,LIFT_TIME_MIN     ,LIFT_TIME_MAX     },
  {MT_VAR_LIFTHEI  ,int8   ,{.pint8= &gls_setting.lift_height}  ,LIFT_HEIGHT_MIN   ,LIFT_HEIGHT_MAX   },
}

Ich bekomme es also bei einem Zeiger im Flash auf einen String im Flash 
mit einem internen Kompilerfehler zu tun.

Ich habe das Ganze noch nicht mit neueren AVR-GCC-Versionen ausprobiert, 
ob der Fehler schon gefixed ist.

Da die Version 4.8.1 mit dem Atmel Studio 6 SP2 ausgeliefert wird, 
dürfte sie weit verbreitet sein. Deswegen suche ich erst einmal einen 
Workaround für diese Compilerversion.


Viele Grüße
W.T.

[Walter T. (nicolas)]

OK, ich habe meinen Workaround gefunden. strncpy_P scheint von diesem 
Compilerfehler nicht betroffen zu sein und mit dem Zwischenschritt, die 
Zeichenkette erst ins SRAM zu kopieren kann ich vorerst leben, da ich 
ohnehin einen Puffer für Zeichenketten vorhalten muß.

[hp-freund (Gast)]

Vielleicht hilft auch ein:
-fno-optimize-sibling-calls

[Walter T. (nicolas)]

Hmmm.... ist eigentlich folgendes erlaubt:

// Header
#define N_BUF 100
char buffer[100];

// Funktion
strncpy(buffer,"u=%u",N_BUF);
snprintf(buffer,N_BUF,buffer,10U);

und wenn nein: Wo finde ich die Einschränkung?

Viele Grüße
W.T.

[Walter T. (nicolas)]

hp-freund schrieb:
> Vielleicht hilft auch ein:
> -fno-optimize-sibling-calls

Ich habe es gerade einmal ausprobiert: Das bewirkt keinen Unterschied in 
Bezug auf den Compilerfehler.

[Klaus W. (mfgkw)]

Walter T. schrieb:
> und wenn nein: Wo finde ich die Einschränkung?

In deinem Oberstübchen.

snprintf() wird den Formatstring lesen (bis zu einer abschließenden 0) 
und den Zielpuffer dabei überschreiben.
Daß snprintf() dazu einen temporären Zwischenspeicher nimmt, kann man 
nicht erwarten, weil ja im Voraus nicht klar ist, wie groß der sein 
müsste.

Davon auszugehen, daß das funktioniert, ist etwas gleichbedeutend mit 
"ja, ich will bis zum Ende meines Lebens der hier anwesenden..."

[Walter T. (nicolas)]

@Mod: Danke für's verschieben, hatte beim Erstellen vergessen, das 
richtig zu setzen.


Klaus W. schrieb:
> In deinem Oberstübchen.
>
> snprintf() wird den Formatstring lesen (bis zu einer abschließenden 0)
> und den Zielpuffer dabei überschreiben.

Von der gleichen Funktionsweise gehe ich auch aus. Aber:

1. mein Oberstübchen sagt mir, daß Einschränkungen einer Funktion der 
Standard-Library irgendwo explizit niedergeschrieben sein sollten 
anstelle daß sich der Nutzer Gedanken über die interne Funktionsweise 
machen sollte,

2. manche Implementierungen der vsprintf benötigen explizit malloc und

3. ich habe es gerade ausprobiert und es funktioniert (zumindest 
oberflächlich)

Vielleicht ist für die Diskussion über sprintf ein eigener Thread 
sinnvoll.

Falls der oben beschriebene AVR-GCC-Bug als bekannt anzunehmen ist, ist 
das Threadthema, für mich allerdings erst einmal erledigt - ansonsten 
würde ich mich noch hinsetzen für ein Minimalbeispiel.

[tictactoe (Gast)]

Walter T. schrieb:
> 1. mein Oberstübchen sagt mir, daß Einschränkungen einer Funktion der
> Standard-Library irgendwo explizit niedergeschrieben sein sollten
> anstelle daß sich der Nutzer Gedanken über die interne Funktionsweise
> machen sollte,

Im Papier N1539 (einem Draft von C11) steht:

7.21.6.5 The snprintf function
Synopsis
#include <stdio.h>
int snprintf(char * restrict s, size_t n,
   const char * restrict format, ...);

Beachte das 'restrict': es bedeutet, dass die Funktion davon ausgehen 
kann, dass alle so in der Parameterliste gekennzeichneten Pointer auf 
nicht-überlappende Speicher zeigen.

> 3. ich habe es gerade ausprobiert und es funktioniert (zumindest
> oberflächlich)

Wenn du hinter dem %u noch was anderes dranhängst, würde ich einen Crash 
erwarten.

[Klaus W. (mfgkw)]

Walter T. schrieb:
> 3. ich habe es gerade ausprobiert und es funktioniert (zumindest
> oberflächlich)

bei mir klappt es schon mal nicht (wenn ich anschließend den den Puffer 
ausgeben, kommt nichts).
Wesentlich wahrscheinlicher geht es auch bei dir schief, wenn du nicht 
%u gnädigerweise mit nur 2 Zeichen aus der 10 überschreibst, sondern mit 
einer Zahl, die mehr Stellen braucht.

Daß etwas in einem Fall auf einem System funktioniert, ist kein starkes 
Argument :-)

[Klaus W. (mfgkw)]

Wobei das auch mal eine interessante Technik wäre: während eines 
sprintf() %-Direktiven auszugeben, die dann im weiteren Verlauf wieder 
interpretiert werden.
Damit kann man bestimmt schöne Sachen bauen (wenn auch nur bedingt 
portabel). Wenn auch eher als abschreckendes Beispiel...

[Karl H. (kbuchegg)]

Klaus W. schrieb:
> Wobei das auch mal eine interessante Technik wäre: während eines
> sprintf() %-Direktiven auszugeben, die dann im weiteren Verlauf wieder
> interpretiert werden.

Der OCCC wartet :-)

[Jörg W. (dl8dtl) (Moderator)]

tictactoe schrieb:
> Beachte das 'restrict': es bedeutet, dass die Funktion davon ausgehen
> kann, dass alle so in der Parameterliste gekennzeichneten Pointer auf
> nicht-überlappende Speicher zeigen.

Es steht auch noch explizit drin:

If copying takes place between objects
that overlap, the behavior is undefined.

[Walter T. (nicolas)]

tictactoe schrieb:
> Im Papier N1539 (einem Draft von C11) steht:

Jörg W. schrieb:
> Es steht auch noch explizit drin:
> If copying takes place between objects
> that overlap, the behavior is undefined.

OK, damit gehört der N1570 zukünftig zu meinen Standardquellen.

Danke!

[Johann L. (gjlayde)]

Walter T. schrieb:
> mit dem Fehler "unrecognizable insn"

Und wie lautet nun die Fehlermeldung?

[Johann L. (gjlayde)]

Walter T. schrieb:
> Falls der oben beschriebene AVR-GCC-Bug als bekannt anzunehmen ist,

Da sowohl Testfall als auch Optionen und Fehlermeldung geheim sind:

Vielleicht ja.  Vielleicht nein.

[Walter T. (nicolas)]

Johann L. schrieb:
> Da sowohl Testfall als auch Optionen und Fehlermeldung geheim sind

Weder der Testfall noch die Fehlermeldung sind geheim. Das Projekt ist 
lediglich mal wieder ein Weilchen liegengeblieben.

Im Wesentlichen sieht der Testfall so aus:

/* aus *.h-Datei: */
  enum datatype_e {
        nothing,
    voidFcn,
    uint8,
    uint16,
    int8,
    int16
  };


    __extension__ typedef struct {
      constflash char *menutext; // Menueeintrag/Funktionsname
      enum datatype_e datatype;   // Datentyp des Zeigers "pointer"
                                  // Bei function pointer wird die Funktion
                    // gestartet, bei Zeigern auf normale Daten
                    // der Datentyp im Menue bearbeitet.
        union {
            voidFcn_t pvoidFcn;     // Funktionszeiger
            uint8_t  *puint8;       // Zeiger auf Variablentypen
            uint16_t *puint16;
            int8_t   *pint8;
            int16_t  *pint16;
            void     *pvoid;
        };
      const int16_t varMin;       // Untere Grenze numerische Variable
      const int16_t varMax;       // Oberere Grenze numerische Variable
    } menudata_t;                   // Struct wird terminiert mit einer Zeile,
                                    // wo in .menutext ein Nulltext
                                    // ({'\0'}) steht.


/* aus *.c-Datei: */


/* Sichtbare Menuetexte darstellen (inkl. Hervorhebung des aktuellen Texts)   */
/*   firstItem: Anfang des darstellten Bereichs (Index)
 *   actItem:   Hervorgehobenes Element (Index)
 *   height:    Hoehe des Dargestellten Bereichs in Zeilen; von unterer 
 *              Displaykante
 */
#if (__GNUC__ == 4 && __GNUC_MINOR__ == 8 && __GNUC_PATCHLEVEL__ == 1)
  /* WORKAROUND:
     Unter AVR-GCC 4.8.1 sorgt die direkte Verwendung von
       "menudata[item].menutext" mit "snprintf_P" fuer einen Compilerfehler 
       ("unrecognizable insn"). Konkret lautete die Zeile:
  
       snprintf_P(glstr_Buf,N_TEXTBUF,menudata[item].menutext,*menudata[item].puint8);
   
       Als Workaraound wird der String zuerst ins SRAM kopiert und anschliessend 
       die snprintf-Funktion genutzt. */
     #warning "GCC 4.8.1 needs workaround for flash strings"
     //#define WORKAROUND_STRING
#endif


void 
draw_menutext(constflash menudata_t menudata[],\
    uint8_t firstItem,uint8_t selectedItem,uint8_t nItem, uint8_t nHeadline) 
{
    uint_fast8_t i, item;
  #ifdef WORKAROUND_STRING
    char tempstr[N_TEXTBUF];  
  #endif
  
    item = firstItem;
    for (i = 0; i<nItem ; i++) {
      uint16_t pos;

      pos = ( (uint16_t) i+nHeadline);
      pos *= LINEWIDTH;
      pos += 9U;

        glcd_setpos(pos);
    
      switch(menudata[item].datatype) {
      case nothing:
        // Falltrough

      case voidFcn:
        // Menutexte fuer Funktionen werden einfach dargestellt
        strncpy_P(glstr_Buf,menudata[item].menutext,N_TEXTBUF);
        glstr_Buf[N_TEXTBUF-1] = '\0';
        break;

      case uint8:
        // Texte fuer Einstellkonstanten werden mit printf
        // interpretiert
        #ifdef WORKAROUND_STRING
          strncpy_P(tempstr,menudata[item].menutext,N_TEXTBUF);
          tempstr[N_TEXTBUF-1] = '\0';
          snprintf(glstr_Buf,N_TEXTBUF,tempstr,*menudata[item].puint8);
        #else
          snprintf_P(glstr_Buf,N_TEXTBUF,menudata[item].menutext,\
          *menudata[item].puint8);
        #endif
        break;

      case uint16:
        // Texte fuer Einstellkonstanten werden mit printf
        // interpretiert      
        #ifdef WORKAROUND_STRING
          strncpy_P(tempstr,menudata[item].menutext,N_TEXTBUF);
          tempstr[N_TEXTBUF-1] = '\0';
          snprintf(glstr_Buf,N_TEXTBUF,tempstr,*menudata[item].puint16);
        #else
          snprintf_P(glstr_Buf,N_TEXTBUF,menudata[item].menutext,\
          *menudata[item].puint16);
        #endif      
        break;

      case int8:
        // Texte fuer Einstellkonstanten werden mit printf
        // interpretiert
        #ifdef WORKAROUND_STRING
          strncpy_P(tempstr,menudata[item].menutext,N_TEXTBUF);
          tempstr[N_TEXTBUF-1] = '\0';
          snprintf(glstr_Buf,N_TEXTBUF,tempstr,*menudata[item].pint8);
        #else              
          snprintf_P(glstr_Buf,N_TEXTBUF,menudata[item].menutext,\
            *menudata[item].pint8);
        #endif
        break;

      case int16:
        // Texte fuer Einstellkonstanten werden mit printf
        // interpretiert
        #ifdef WORKAROUND_STRING
          strncpy_P(tempstr,menudata[item].menutext,N_TEXTBUF);
          tempstr[N_TEXTBUF-1] = '\0';
          snprintf(glstr_Buf,N_TEXTBUF,tempstr,*menudata[item].puint16);
        #else      
          snprintf_P(glstr_Buf,N_TEXTBUF,menudata[item].menutext,\
            *menudata[item].pint16);
        #endif
        break;
    }

           
        // Normale und hervorgehobene Menuepunkte
        if (selectedItem == item) glcd_putstr_P(PSTR("\033i")); // Hervorgehoben
        glcd_putstr(glstr_Buf);
        if (selectedItem == item) glcd_putstr_P(PSTR("\033n")); // Hervorhebung
                                                          // zuende
    
        item++;
    }
}

Das Ganze ist eher unübersichtlich und weit entfernt von einem 
Minimalbeispiel - falls das hilfreich ist, kann ich das aber noch 
nachliefern.

Mit den folgenden Build-Optionen:
 avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields 
-DF_CPU=7372800UL  -Os -ffunction-sections -fdata-sections -fpack-struct 
-fshort-enums -Wall -Wextra -Wundef -pedantic -mmcu=atmega32 -c 
-gdwarf-2 -std=gnu99 -fwrapv -H -Wsign-conversion -v -MD -MP -MF 
"common/src_menu/menu.d" -MT"common/src_menu/menu.d" 
-MT"common/src_menu/menu.o"   -o "common/src_menu/menu.o" 
"../common/src_menu/menu.c"
    Using built-in specs.

sieht die Konsolen-Ausgabe wie folgt aus:

C:\Users\Nicolas\Desktop\SVN\2015_Rotorsteuerung\Firmware_AVR\Pulsgenerator04\common\src_menu\menu.c(177,6): warning: #warning is a GCC extension [enabled by default]
         #warning "GCC 4.8.1 needs workaround for flash strings"
          ^
C:\Users\Nicolas\Desktop\SVN\2015_Rotorsteuerung\Firmware_AVR\Pulsgenerator04\common\src_menu\menu.c(177,6): warning: #warning "GCC 4.8.1 needs workaround for flash strings" [-Wcpp]
    ../common/src_menu/menu.c: In function 'draw_menutext':
C:\Users\Nicolas\Desktop\SVN\2015_Rotorsteuerung\Firmware_AVR\Pulsgenerator04\common\src_menu\menu.c(273,1): error: unrecognizable insn:
     }
     ^
    (insn 71 70 72 11 (set (reg:QI 99)
            (subreg:QI (mem/f:HI (reg/f:HI 47 [ D.2725 ]) [3 _20->menutext+0 S2 A8 AS1]) 1)) ../common/src_menu/menu.c:219 -1
         (nil))
C:\Users\Nicolas\Desktop\SVN\2015_Rotorsteuerung\Firmware_AVR\Pulsgenerator04\common\src_menu\menu.c(273,1): error: in extract_insn, at recog.c:2150
    Please submit a full bug report,
    with preprocessed source if appropriate.

Leider gibt es also keine wirklich sinnvolle genauere Fehlermeldung.

Viele Grüße
W.T.

[Johann L. (gjlayde)]

Vermutlich

https://gcc.gnu.org/PR61443

...aber nur geraten, weil das Beispiel sich nicht compilieren lässt.  Du 
hast wohl nie versucht, den angeblichen Testfall zu übersetzen :-/

[Karl H. (kbuchegg)]

Walter T. schrieb:

> Das Ganze ist eher unübersichtlich und weit entfernt von einem
> Minimalbeispiel - falls das hilfreich ist, kann ich das aber noch
> nachliefern.

Ein Minimalbeispiel ist immer hilfreich.
Die wenigsten Fehler sind so, dass man sie nur durch hinsehen sofort 
weiß, was Sache ist.

Dir ist schon aufgefallen, dass in der geposteten Funktion die 
Block-Klammerung nicht stimmt? Da ist eine } zu viel.

Ob das was damit zu tun hat?
Keine Ahnung. Vielleicht ist das ja auch nicht der komplette 
Original-Code.

[Walter T. (nicolas)]

Hallo zusammen,
ich habe mal ein "nicht-ganz-Minimalbeispiel" gemacht. In Atmel-Studio 
6.2 sollte es direkt build-bar sein und mit dem ein- und auskommentieren 
der Zeile 61 in main.c ist der Fehler erzeugbar.

Ich habe kein noch kleineres Minimalbeispiel erstellt, weil ich sonst 
befürchten muß, daß

a) ich aus dem ursprünglichen Fehler in einen ganz anderen laufe 
(Flüchtigkeitsfehler bei der Minimierung) und

b) ansonsten die unweigerliche Frage kommt (nicht unbedingt von 
bisherigen Thread-Teilnehmern), warum ich solche Konstruktionen mit 
struct arrays im Flash mit Zeigern auf char arrays im Flash überhaupt 
nutzen will

c) ich immer noch nicht 100% ausschließen kann, daß bei mir noch ein 
Programmierfehler liegt.

[Karl H. (kbuchegg)]

Walter T. schrieb:

> c) ich immer noch nicht 100% ausschließen kann, daß bei mir noch ein
> Programmierfehler liegt.

Da kann ich dich beruhigen.
Wenn der Compiler abkratzt, dann ist das ein Fehler im Compiler.

Egal was du schreibst, und sei es der größte Unsinn, der Compiler darf 
nicht abschmieren.

[Walter T. (nicolas)]

Hallo Karl-Heinz,
wenn wir ehrlich sind, kratzt der Compiler nicht ab, sondern stellt 
seine Tätigkeit mit einer mehr oder weniger definierten Fehlermeldung 
ein. Nicht auf optimale Weise, aber immerhin muß das Betriebssystem 
nicht hinterher die Scherben wegkehren.

Kann bitte einer der C-Experten prüfen, ob er das aufgrund eigentlich 
korrekten Codes macht (womit es ein echter Compilerfehler ist) oder nur 
die anderen Compilerversionen so großzügig sind, das erwartete Verhalten 
bei ungültigem Code zu liefern (womit es nur ein ungünstiges 
Compilerverhalten, aber kein Fehler ist).

Ich habe mir die Sachen jetzt leider schon so oft angesehen, daß ich 
einen Fehler noch nicht einmal mehr dann sehen würde, wenn er rot 
blinkte.

Viele Grüße
W.T.

[Jörg W. (dl8dtl) (Moderator)]

Eine unrecognizable INSN ist immer ein „echter Compilerfehler“.

Johann hatte ja weiter oben bereits eine Vermutung geäußert, um welchen
Bug es sich handelt.  Ich würde diese Vermutung bestätigen: wenn du in
der Funktion, bei der der Fehler auftritt, den Aufruf nach snprintf
auskommentierst, dann compiliert er durch.

[Walter T. (nicolas)]

Jörg W. schrieb:
> Johann hatte ja weiter oben bereits eine Vermutung geäußert, um welchen
> Bug es sich handelt.  Ich würde diese Vermutung bestätigen

OK, wenn ihr beiden sagt, daß es ein bekannter Bug ist, dann gehe ich 
mal davon aus, das das stimmt. Das spart mir auch den Gegentest mit dem 
AVR-GCC 4.9.1 oder 4.8.4, falls am Wochenende das Wetter schlecht genug 
ist.

Für mich ist die Sache damit erledigt  - es sei denn, einem geneigten 
Mitleser fällt noch ein besserer Workaround als das Kopieren des 
gesamten Strings ein.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> es sei denn, einem geneigten Mitleser fällt noch ein besserer Workaround
> als das Kopieren des gesamten Strings ein.

Benutzung von GCC 4.8.4 oder 4.9.1, für beide nennt der Bugreport die
Sache als erledigt.  Johann hat den Fix auf beide Branches zurück
portiert.

[Walter T. (nicolas)]

Jörg W. schrieb:
> Benutzung von GCC 4.8.4 oder 4.9.1

Du beschreibst hier eine sinnvolle Lösung, keinen Workaround :-)

Solange die Atmel-Toolchain noch auf den AVG-GCC 4.8.1 setzt, werde ich 
aber wohl oder übel noch diese Version unterstützen müssen.

Wobei der Grund dazu aber schon Off-Topic ist: Ich bin der Meinung, wenn 
ich meine Projekte (als abschreckendes Beispiel) Open Source mache, 
sollte ich nicht auf irgendwelche aufwendig installierbare 
Build-Umgebungen setzen. Und die Atmel-Toolchain ist noch auf AVR-GCC 
4.8.1, WinAVR auf 4.3.3.