[m-users.] That parallel low-level C bug

[Zoltan Somogyi]

On Mon, 14 Sep 2026 14:36:53 +0200, Volker Wysk <post at volker-wysk.de> wrote:

> Am Montag, dem 14.09.2026 um 13:10 +0200 schrieb Zoltan Somogyi:
> > > Since no "asm_fast.par" grades are available, you need to compile in a
> > > high level C grade instead. But some programs need the tail recursion
> > > optimization, which isn't available there.
> > 
> > Yes, it is. For about a decade, tail recursion optimization has been
> > almost as good in high level C grades as in low level C grades.
> > For most purposes, though not all, they are just as good.
> 
> Somewhere I've got the notion that there's no TRO in high level C grades...

Twenty years ago, that would have been correct. Then, for several years,
we supported only self-tail-recursion in high level C grades. Since about
ten years ago, such grades support both self and mutual tail recursion.

> There indeed is something done after one call of master_loop_abort

Actually, there is probably not. The reason for the lack of tail recursion here
is much simpler. For low level C grades, tail recursive code is smaller
than the exact same code that is compiled without tail recursion optimization.
For high level C grades, the opposite is true. Therefore the code that
marks tail recursive calls simply SWITCHES OFF even TRYING to mark
recursive calls in predicates whose determinism is erroneous.
This is because such predicates abort the program, and whether they take
a microsecond less or more to do it does not matter, because conditions
that abort the program should be RARE, and deep recursion within such
predicates should be EVEN RARER. The compiler therefore prefers
the space saving from not doing tail recursion optimization to the
(presumably non-existent in this case) speedup from doing it.

Your example is the first time I have ever seen a recursive predicate
whose determinism is erroneous. What led you to this design?

> I mean the problem that the compiled program crashes or has weird errors in
> some Linux distributions, while it works in others. That is, when it is
> compiled in a parallel low-level C grade with an earlier version of the
> compiler, which doesn't abort with an error message.

The generation of an error message for the low-level-C with paralellism
combination is relatively recent, but the problems are old. I know of one
issue with the low-level-C code generator which has existed since about 2010
(which is NOT linux distro dependent), and the last time this incompatibility
was brought up, other people reported an issue which is, or at least
seems to be, distro-dependent. In absence of the required resources,
neither is being worked on.

Zoltan.