void *f(char c, char d, char *p)
{
return p < &c ? &c != 0 ? &d : 0 : 0;
}
Compiling this with sdcc test.c -mstm8 results in this :
~~~
Backtrace:
sdcc[0x496177]
sdcc[0x6a294c]
sdcc[0x6a498a]
sdcc[0x6bb213]
sdcc[0x6c6102]
sdcc[0x67d5cf]
sdcc[0x42ff1e]
sdcc[0x447efc]
sdcc[0x40c13e]
sdcc[0x40837c]
/lib64/libc.so.6(__libc_start_main+0xf2)[0x7f893ef24042]
sdcc[0x409efe]
test.c:3: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '453' : code generator internal error
Contact Author with source code
op2 type: 8, offset 1, rIdx -1
Backtrace:
sdcc[0x496177]
sdcc[0x6a215d]
sdcc[0x6a494d]
sdcc[0x6bb213]
sdcc[0x6c6102]
sdcc[0x67d5cf]
sdcc[0x42ff1e]
sdcc[0x447efc]
sdcc[0x40c13e]
sdcc[0x40837c]
/lib64/libc.so.6(__libc_start_main+0xf2)[0x7f893ef24042]
sdcc[0x409efe]
Backtrace:
sdcc[0x496177]
sdcc[0x6a294c]
sdcc[0x6a498a]
sdcc[0x6bb213]
sdcc[0x6c6102]
sdcc[0x67d5cf]
sdcc[0x42ff1e]
sdcc[0x447efc]
sdcc[0x40c13e]
sdcc[0x40837c]
/lib64/libc.so.6(__libc_start_main+0xf2)[0x7f893ef24042]
sdcc[0x409efe]
test.c:3: error 9: FATAL Compiler Internal Error in file 'peep.c' line number '89' : readint() got non-integer argument:
Contact Author with source code
dummy
dummy
dummy
dummy
~~~ (This is only the final few lines, otherwise this bug report would be endless). Tested on commit 11672.
It looks like &c is assigned to an iTemp that is then marked as rematerializable but the code generator for the comparisons don't know how to handled a rematerializable stack address. It appears that there previously was code that verified that the uses of the rematerializable stack address were only pointer gets/sets, but that was removed in [r11438].
Works for me as of [r13827]. I suspect my recent fix for [bugs:#3503] also covers this issue.
Related
Bugs:
#3503Commit: [r13827]