assertion bestreg fails sometimes for some targets when there are too many locals

[kulp]

Thank you for LCC -- it has been a pleasure and an educational experience to work with.

The following code fails an assertion when compiled (as r.c) with rcc -Wf-target=symbolic -target=sparc/sun -S r.c :

void fails(void)
{
    int a=0,b=0,c=0,d=0,e=0,f=0,g=0,h=0,i=0,j=0,
        k=0,l=0,m=0,n=0,o=0,p=0,q=0,r=0,s=0,t=0;

    a |= b|c|1|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t;
    a |= b|c  |d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t;
}

On my Macbook Pro :

$ cc --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
$ mkdir -p build && cd build && make -C .. BUILDDIR=$PWD HOSTFILE=etc/solaris.c all
# ... build succeeds ... (as long as I #undef memmove inside cpp/unix.c to prevent clashing with system memmove)
$ ./rcc -Wf-target=symbolic -target=sparc/sun -S r.c
.global _fails
.seg "text"
Assertion failed: (bestreg), function spillee, file src/gen.c, line 686.
Abort trap: 6

In a Debian GNU/Linux VM :

$ cc --version
cc (Debian 4.9.1-19) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ mkdir -p build && cd build && make -C .. BUILDDIR=$PWD HOSTFILE=etc/solaris.c all
# ... build succeeds ... (memmove issue does not occur)
$ ./rcc -Wf-target=symbolic -target=sparc/sun -S r.c
.global _fails
.seg "text"
rcc: src/gen.c:686: spillee: Assertion `bestreg' failed.
Aborted

I first noticed this on my own backend (lcc-tenyr) and then while trying to debug, found it does similarly on sparc. I am not gunning for sparc specifically to be mended, but I am wondering if there is a target-independent bug, given that this happens even with -Wf-target=symbolic. This bug does not occur for me with -target=mips/irix or -target=x86/linux.

The problem seems to be that ralloc runs out of viable registers to spill in spillee. For my own architecture, this happens quite soon because the lastuse pointer is never updated. I am wondering if lastuse is not updated in enough cases ?

[hhtat]

I'm working on a new backend and running into the same issue. @kulp - did you ever figure out the cause?

[kulp]

@hhtat, no, I stopped working on my port of lcc because of this issue, and I have no further information. I will be happy to know if you find anything out.