Handling goto to start of function

[l-kent]

The example in #316 has a failing assertion when put through BASIL:

[ERROR]   errorFn_1840 Entry block malformed, missing or has incoming jumps: Some(ListSet(GoTo(errorFn_entry))) [procedureDiamondForm@ProcedureDiamondForm.scala:16]
Exception in thread "main" java.lang.AssertionError
    at ir.transforms.ReplaceReturn$package$.establishProcedureDiamondForm(ReplaceReturn.scala:143) 

This is caused by the following function in the C source:

void errorFn() {
ERROR:
  goto ERROR;
}

This is compiled to a function where the first block contains a jump to itself, though any function that has a label for a manual goto at its start should produce a similar result and cause this same assertion failure.

How do we want to handle this niche case? Does it cause problems elsewhere if we allow the first block of a procedure to be a loop header? @agle

[agle]

Yeah in the past its caused non-termination problems in the past in DSA (but I think there was an underlying bug I fixed). I think it makes sense to require entry blocks not have predecessors so they trivially dominate every reachable block in the procedure, it's an annoying case to have to keep in mind for writing transforms. A transform in the ReplaceReturns batch should fix up this structure. (The replace returns pass currently also introduces this problem for tail calls, I should PR this commit to fix it a3ef17e.

[l-kent]

I don't think that commit would properly fix the problem for the tail calls, as it's creating a new block after the entry block, when the correct transformation should be to create a new empty block to be the entry, and have it goto the old entry block, with all other jumps to the old entry block remaining the same?

I agree that it would make sense to handle this with a transform in ReplaceReturns though.

[agle]

Yeah true its obviously not right unless the entry is empty