[M3devel] Assert problem

[Rodney M. Bates]

On 10/15/2017 05:28 PM, Peter McKinna wrote:
> Hi Rodney,
>
>   I'm getting an assert error in M3CG_LLVM.m3 line 2131 running test p004 (and a couple of others) Can you duplicate it? I'm using the latest I think.
>

Are you asking for debug info from the llvm backend?  This has assertion failures
that I have not tracked down. I disable llvm generation of debug info by commenting
out /usr/local/bin/config/Unix.common:144 'args += "-g'.

However, when I enable it, m3llvm runs to completion on p004, so I am not getting
the failure you are.  But later, in llc, I get a different, C++ assertion failure:

llc -disable-fp-elim -filetype=asm  -relocation-model=pic Main.mb -o Main_m.s
llc: /home/rodney/proj/llvm/llvm-3.6.1/llvm-3.6.1.src/include/llvm/CodeGen/MachineInstr.h:261: llvm::DIExpression llvm::MachineInstr::getDebugExpression() const: Assertion `Expr.Verify() && "not a DIExpression"' failed.

This seems to be some undocumented invariant that llvm has for its IR, but, unlike
many others, does not get checked by the llvm C++ IR-building code linked into m3llvm,
instead showing up only later in llc.  That makes it difficult even to find what
part of the compiled program has this problem.

This is on AMD64_LINUX, the only target I have done any testing on.

>  Also, how do you run the test suite using the llvm backend? I just put that define
> M3_BACKEND_MODE="StAloneLlvmAsm" in the top level m3makefile in m3tests/src and ran it. But I think the define does not make it into the local m3makefile in each test directory so it just runs the default gcc backend.
>

I have M3_BACKEND_MODE="StAloneLlvmAsm" in my /usr/local/cm3/bin/cm3.cfg, and it seems to
propagate to all the tests.  For a quick (but verbose) check, I invoke with 'cm3 -commands'
which will show the invocation of m3llvm, llc, etc.

The flow of information of these options is a huge maze, and I always dread trying to
trace it for some specific thing,  Info goes back and forth between quake and m3 code,
and there is no simple way to dig out the set and order of quake files being interpreted.

There should be a better way, that applies only to the tests, not everything you run cm3 on.
I have to remember to keep changing my cm3.cfg back and forth to recompile a new compiler,
using gcc backend, then run tests using the llvm backend.  (Fortunately, I have it
scripted.)  The llvm backend will produce a correctly built compiler, but only without any
significant debug info, making it hard to move to the next step.

> Regards Peter

-- 
Rodney Bates
rodney.m.bates at acm.org