backwards indirect goto does not compile

[jmr]

int f (void)
{
    static void *x[1];
    L: if (x[0] != 0) return 0;
    x[0] = &&L;
    goto *x[0];
}

Results in:

Unresolved external 'L0004' referenced in:
  bugXXXX-ind-goto-rev.s(61)
  bugXXXX-ind-goto-rev.s(62)

This works with gcc.

It looks like something is wrong with the way GotoStatement is trying to prevent labels from getting deleted.

I'll send a PR with a test case soon.

[mrdudz]

Now this is some crazyness. I'd file it under "barely legal" :=)

[acqn]

Is this the expected output (compiled with a #897 solution)?

; ---------------------------------------------------------------
; int __near__ f (void)
; ---------------------------------------------------------------

.segment	"CODE"

.proc	_f: near

.segment	"CODE"

;
; L: if (x[0] != 0) return 0;
;
L0002:	lda     M0001
	ldx     M0001+1
	cpx     #$00
	bne     L0006
	cmp     #$00
L0006:	jsr     boolne
	jeq     L0003
	ldx     #$00
	lda     #$00
	jmp     L0001
;
; x[0] = &&L;
;
L0003:	lda     #<(L0002)
	ldx     #>(L0002)
	sta     M0001
	stx     M0001+1
;
; goto *x[0];
;
	ldy     #$00
	lda     M0001,y
	ldx     M0001+1,y
	jmp     callax
;
; }
;
L0001:	rts

.segment	"BSS"

M0001:
	.res	2,$00

.endproc

[jmr]

Yes, that looks right.

[jmr]

@acqn If you have a fix for #897, it would be great to get that in. Maybe it could allow cleanup of the indirect goto handling code and the jump tables I'm working on for #1049.

[jmr]

@clbr it looks like you implemented computed gotos.

[clbr]

Dynamic computed gotos are not supported, so from that sense this is not a bug.

[jmr]

Based on the generated code, there's no reason it shouldn't work. It's just the code preventing the label deletion that doesn't work.

If the intent really were to not support this, there should be an error like "dynamic computed goto not supported", rather than an obscure linker error.

[jmr]

Here's version with the same failure and no dynamic computed goto.

static unsigned char y = 0;
int f(void) {
    L: if (y) return 0;
    {
        static const void *const x[1] = {&&L};
        y = 1;
        goto *x[0];
    }
}

% cl65 -t sim6502 /tmp/back.c
Unresolved external 'L0003' referenced in:
  /tmp/back.s(47)
Unresolved external '_main' referenced in:
  runtime/callmain.s(27)
ld65: Error: 2 unresolved external(s) found - cannot create output file

[oliverschmidt]

Now this is some crazyness. I'd file it under "barely legal" :=)

Dynamic computed gotos are not supported, so from that sense this is not a bug.

If the intent really were to not support this, there should be an error like "dynamic computed goto not supported", rather than an obscure linker error.

That's what made me classify this issue as bug.

[clbr]

There is no such error message because it didn't occur to me at the time someone would try something that crazy...

[clbr]

The new sample still confuses me on why you would do that in the first place, but ok, it's a valid bug.

[jmr]

I don't actually want to do any of the things in this bug, but there should be no reason not to allow them. I was trying to look at the computed goto label handling code to see how things should work because there are (unsurprisingly) similar issues for #1049 trying to use jump tables for switch. I looked at the code, said, "wait, how does this work?" and found that it doesn't. #1211 is equivalent to something that needs to be handled for #1049, so I'm more interested in a fix for that one.

[acqn]

My fix for this depends on something tha depends on something that depends on something that depends on something... that is seemingly irrelevent to this one.... The "gap" between the current HEAD of the master branch and the fix is 20 31 commits. I'll see if I can rebase it.

[oliverschmidt]

If you plan to close the gap in the foreseeable future, I personally don't see why you should invest into changing the order of your commits just because of the existence of this issue.

[acqn]

I've been closing the gap. There are still (3 + 1) + 21 = 25 commits to go before the fix branch could be merged and tested. That would be the 2 current PRs plus about 6 new ones.

[greg-king5]

I've been closing the gap. There are still (3 + 1) + 21 = 25 commits to go before the fix branch could be merged and tested. That would be the 2 current PRs plus about 6 new ones.

We "nosy bees" appreciate the progress report.

[oliverschmidt]

+1

[mrdudz]

yes! I am totally overwhelmed by how it is moving forward atm. Don't stop :)