[m-rev.] for review 1/4: Disable GCC Labels on RISC-V

[Paul Bone]

On Fri, 17 Mar 2023, at 3:03 PM, Julien Fischer wrote:
> Hi Paul,
>
> On Fri, 17 Mar 2023, Paul Bone wrote:
>
>> The configure test runs an infinite loop on RISC-V, disable it.
>
> Aarch64 had the same issue, the solution there was to disable the GCC
> option -ftree-dominator-opts.

I saw that.  The code below that says that PIC is still a problem though.  I'm trying now with gcc 12 and -fno-tree-dominator-opts (I copied the code from the aarch64 section).  The configure script is happy but the runtime won't compile.  I'm hitting (unrelated?) GCC bugs, both GCC 12 and GCC 9:

$ ../scripts/mgnuc --grade asm_fast.gc    --c-debug --no-ansi   --      -c mercury_engine.c -o mercury_engine.o
mercury_engine.c: Assembler messages:
mercury_engine.c:476: Error: junk at end of line, first unrecognized character is `/'
mercury_engine.c:523: Error: junk at end of line, first unrecognized character is `/'

What's interesting here is if I do:

$ ../scripts/mgnuc --grade asm_fast.gc    --c-debug --no-ansi   --      -S mercury_engine.c -o mercury_engine.S
$ ../scripts/mgnuc --grade asm_fast.gc    --c-debug --no-ansi   --      -c mercury_engine.S -o mercury_engine.o

Then it works, well it builds the .o file but I don't know if it has valid code.

Since I'm using gcc 12 (I have convenient access to 9, 10, 11 and 12) I may have the same problem on RISC-V.  But without getting really in-depth I won't know if a problem I'm having is because of PIC or because of -ftree-dominator-opts.  

I don't want to spend more time chasing asm_fast right now.  So I'll update the comment and push the changes I made.

FWIW RISC-V is an interesting target for Mercury's low-level C grades because it has two link registers.  Well, any register can be a link register, there's nothing special about any particular registers but the calling convention uses x1 and the specification suggests to implementers that they optimise both x1 and x5.  I know Mercury doesn't use C calling conventions in low-level C grades, but *if* it did and *if* we mapped MR_succip to x1 and mapped the nondet failure link register to x5, and *if* a particular hardware design did optimise x5 it might be interesting.  Another application is the implementation of coroutines, using x1 to "return" and x5 to "yield".

Anyway, the patches make hlc.gc and reg.gc usable which is already more than I need.