Code bringt XC8 zum hängen

[Vierauge (Gast)]

Guten Abend,

folgender Code führt, sofern das Projekt für PIC18 erzeugt wird, zum 
aufhängen des ASPIC18.EXE (Teil des XC8) (Build dauert unendlich lange). 
Sobald der Prozessor auf PIC16 oder PIC12 geändert wird, funktioniert 
der Build-Prozeß.

#include <xc.h>

void main(void) 
{
    unsigned char a, b;
    
    for (a = 0; a <= 32; a++)
    {
        b++;
    }
    
    while(1);
    
    return;
}

Lasse ich die for-Schleife weg oder ersetze while(1); durch 
while(1){b=a;} läuft der Build durch.

Seltener Fehler im ASPIC18?

XC16 und XC32 haben kein Problem mit dem Code, nur XC8 in Verbindung mit 
PIC18

[Witkatz :. (wit)]

Hallo Vierauge,

auf microchip forum wurde das Problem auch gepostet, zur Info:
http://www.microchip.com/forums/m934265.

Streng genommen gehört das Thema in "Compiler & IDEs" rein

[Vierauge (Gast)]

Ja, ich habe es auch dort gepostet. Problem soll mit v1.38 behoben sein.

[Peter D. (peda)]

Unsinniger Code wird selten zum Compilertest genommen und kann daher gut 
den Compiler durcheinander bringen.

Man könnte sogar sagen, das ist ein Feature, d.h. der Compiler sagt Dir 
durch die Blume, Du hast Bockmist verzapft.

Sobald Du b initialisierst (lokale Variablen sind bei Eintritt 
unbestimmt), muß der Code aber durchlaufen.

[Vierauge (Gast)]

Dass der obige Code unsinnig ist weiß ich selber. Obiger Code ist ja nur 
die eigentliche Ursache, warum ein ursprünglich größerer, durchaus 
sinnvoller Code den Compiler zum hängen gebracht hat (Inititialisierung 
der Peripherie in main(), Code nur im Interrupt, daher leere 
while(1)-Schleife). Code wurde von nem PIC16 auf nen PIC18 migriert.

Falls es jemand interessiert: V1.35 hat kein Problem, V1.37 nur in den 
Optimierungsstufen Free und Standard, Pro läuft hingegen, wobei es in 
den Free & Standard-Stufen wohl in der standardmäßig aktivierten 
Assembleroptimierung liegt (+asm hängt, -asm läuft). In V1.38 wird der 
Bug behoben sein.

[Peter D. (peda)]

Vierauge schrieb:
> Obiger Code ist ja nur
> die eigentliche Ursache, warum ein ursprünglich größerer, durchaus
> sinnvoller Code den Compiler zum hängen gebracht hat

Dann zeig dochmal Code, der hängt obwohl er keine unbestimmten Ausdrücke 
enthält.
Der oben gezeigte Code ist deshalb unbestimmt, weil b bei der Verwendung 
(b++;) nicht initialisiert ist und sowas ist erstmal ein Fehler des 
Programmierers.
Nur globale Variablen werden per default mit 0 initialisiert.

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

Peter D. schrieb:
> Dann zeig dochmal Code, der hängt obwohl er keine unbestimmten Ausdrücke
> enthält.

Egal, wie unsinnig der Code ist, der Compiler hat sich davon nicht
aufzuhängen.  Die Überschrift ist ja etwas schlecht formuliert, es
geht ja wohl nicht darum, dass der Zielprozessor irgendwie Mist macht,
sondern der Compiler (steht im Eingangsposting dann jedenfalls so).

[Vierauge (Gast)]

Bei

#include <xc.h>

void main(void) 
{
    unsigned char a, b;

    b = 0;
    
    for (a = 0; a <= 32; a++)
    {
        b++;
    }
    
    while(1);
    
    return;
}

hängt der Compiler genauso wie bei

#include <xc.h>

void main(void) 
{
    unsigned char a, b;
    
    for (a = 0; a <= 32; a++)
    {
        b = a;
    }
    
    while(1);
    
    return;
}

wo hingegen

#include <xc.h>

void main(void) 
{
    unsigned char a, b;
    
    for (a = 0; a <= 32; a++)
    {
        b++;
    }
    
    while(1)
    {
        b++;
    }
    
    return;
}

anstandslos durch den Compiler läuft

Das Problem liegt aber wie bereits genannt in der Optimierungsfunktion 
des erzeugten Assemblercodes des XC8 und dort auch nur in bestimmten 
Konstellationen (V1.37, PIC18, Free o. Standard-Optimierung). Es ist 
also kein genereller Code um Compiler ins Schwitzen zu bringen.

Wurde von Microchip auch als Antwort auf mein Ticket bestätigt

[Vierauge (Gast)]

Dachte XC8 ist als Compiler bekannt :/