#3795 Assignment to global produces Internal Error in SDCCopt.c Line 312

[Phillip Stevens]

Tested with sdcc v4.4.0 release.
Unsure whether this has been resolved recently.

Initial error report here https://github.com/z88dk/z88dk/issues/2635

test_sproduces an error. test_d does not.

bug2635.c:32: error 9: FATAL Compiler Internal Error in file 'SDCCopt.c' line number '312' : 0 
Contact Author with source code

#include <stdint.h>

uint8_t IntNorms[2][4] =  { {0x1F, 0x00, 0x3E, 0x1F},
                            {0x9F, 0x12, 0x37, 0x10},  };
float normalsf[13][3];

float test_s;

void main(void)
{
    uint8_t i = 0;
    int16_t value16x;

    float test_d;

    while (i < 2)
    {
        value16x = (int16_t)IntNorms[i][0];
        test_s = (float)value16x;
//      test_d = (float)value16x;
        ++i;
    }
}

[Philipp Klaus Krause]

I haven't been able to reproduce the issue using current trunk so far. But I'll put a regression test into SDCC to see if any machine in the compile farm encounters an issue.

1) Which options were used to call SDCC triggering the bug with the above code?
2) Can you still trigger the bug when you remove normalsf?
3) Can you still trigger the bug when you remove test_d?

[Phillip Stevens]

Environment is with z88dk, and the sdcc version is v4.4.0, release r14648.

This issue may have been repaired since r14648, and if so we can close this and move on.

I have dug into it a bit deeper (returned from AFK), and found this seems to be easily reproducible across a variety of z80 family machine types and optimisation levels.

My only thought is that since we're using UCPP as a preprocessor something is going wrong at that point, before it gets to SDCC. I'll dig in there shortly.
EDIT the .i preprocessor output looks normal.

Default configuration passed to (z)sdcc by +zxn.
-mz80n -O2 -SO2 -iquote. -D__ZXNEXT -D__Z80 -D__Z80__ -D__Z80N -subtype=default -clib=sdcc_iy

The default is overridden by these sdcc calling options.
zcc +zxn -S -O0 -SO0 bug-2635.c

The optimisation levels play no role.
The machine can be z80n, z80, z180, it plays no role.

Removing normalsf does nothing.
Removing test_d does nothing.

// zcc +zxn -S -O0 -SO0  bug-2635.c
// zcc +zx -compiler=sdcc -S -O0 -SO0  bug-2635.c


#include <stdint.h>

uint8_t IntNorms[2][4] =  { {0x1F, 0x00, 0x3E, 0x1F},
                            {0x9F, 0x12, 0x37, 0x10},  };

float test_s;

void main(void)
{
    uint8_t i = 0;
    int16_t value16x;

//  float test_d;

    while (i < 2)
    {
        value16x = (int16_t)IntNorms[i][0];
        test_s = (float)value16x;
//      test_d = (float)value16x;
        ++i;
    }
}

[Phillip Stevens]

Simplifying and working on this a bit further, the issue seems to be related to the casting of uint8_t to int16_t and then to float.

bug-2635.c:29: error 9: FATAL Compiler Internal Error in file 'SDCCopt.c' line number '312' : 0 
Contact Author with source code

The error does not occur in test_b case where the cast to float is done directly.

// zcc +zxn -S -O0 -SO0  bug-2635.c
// zcc +zx -compiler=sdcc -S -O0 -SO0  bug-2635.c

#include <stdint.h>

uint8_t IntNorms[4] = {0x1F, 0x00, 0x3E, 0x1F};

float test_a;
float test_b;

void main(void)
{
    uint8_t i = 0;
    int16_t value16x;

    while (i < 2)
    {
        value16x = (int16_t)IntNorms[i];
        test_a = (float)value16x;
//      test_b = (float)IntNorms[i];
        ++i;
    }
}

EDIT if volatile is added to volatile int16_t value16x declaration, the error is avoided. Somewhere an optimiser is being tangled up by the double casting.

[Phillip Stevens]

Confirmed the bug is present with vanilla sdcc r14648.

$ sdcc -v
SDCC : z80/z180/r2ka/r3ka/sm83/ez80_z80/z80n/r800 TD- 4.4.0 #14620 (Linux)
published under GNU General Public License (GPL)

$ sdcc -S bug-2635.c
bug-2635.c:29: error 9: FATAL Compiler Internal Error in file 'SDCCopt.c' line number '312' : 0 

Found bug is gone with sdcc r15078

$ sdcc -v
SDCC : z80/z180/r2ka/r3ka/sm83/ez80_z80/z80n/r800/f8 TD- 4.4.4 #15078 (Linux)
published under GNU General Public License (GPL)

$ sdcc -S bug-2635.c

This issue can be closed.