[m-rev.] for post-commit review: fix mantis bug 361

[Julien Fischer]

On Thu, 18 Sep 2014, Paul Bone wrote:

> I like this and I think it's a step in the right direction.  However it's
> still a leaky abstraction, by an ideal goal I was thinking of a system with
> many fewer grades (normal, debugging, profiling) and definitly not multiple
> backends to the same target language.  I beleive this matches what users
> want without adding unnecesary complexity, however it's extreamly
> hypothetical and not something that realistically matches the Mercury
> project in it's current form or with it's design goals (eg: not paying for a
> feature like parallelism or trailing when your program doesn't use it).

You've moved on to a different problem there, reducing the number of
grades and that's a different discussion.

BTW, the two "C" backends do not target the same language: the
high-level backend targets standard C (or at least it's supposed to),
the low-level C backend targets GNU C (usually) + a bunch of inline
assembler.

Actually, I note that the compiler attempts to install the libraries in
14 different grades by default on OS X when using clang (i.e. when we
can't use the asm_fast grades), namely:

    csharp
    hlc.gc
    hlc.gc.memprof
    hlc.gc.prof
    hlc.gc.trseg
    hlc.par.gc
    java
    none.gc
    none.gc.debug.stseg
    none.gc.debug.trseg.stseg
    none.gc.decldebug.stseg
    none.gc.prof
    none.gc.profdeep
    none.par.gc.stseg

That may be getting a bit excessive ;-)

Cheers,
Julien.