Linux/ARM: Bus error with -O3 flag of clang/llvm-3.6 while running unit-test of .NET Core

Renato Golin via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 20 08:49:06 PDT 2016


On 20 June 2016 at 15:47, Geunsik Lim <leemgs at gmail.com> wrote:
> Actually, there are a lot of files from the DotNet Core run-time (e.g.
> CoreCLR).
> In this case, How do we reproduce related IRs with upstream 'llc' command?

It depends. If the IR your front-end generate strictly follows the
Language Reference [1], then it's very simple (see below). If not,
than it can be very hard and we may not be able to help you at all. :/

If it does...

1. Reduce the C# code to the smallest code that reproduces the error.

In C++, I normally generate a pre-processed file and use that to
reduce (since the reducer has access to the entirety of the source). I
assume there is something similar in C#

To reduce the size of the pre-processed file, I use creduce [2], but I
have no idea how to do it in C#. Before creduce I used to do that
manually, and I could clean up large amounts of useless stuff by
removing code and looking for "unused" warnings.


2. Generate IR

Once you have a small enough sample, make sure it reproduces the
original case. I'm also assuming your front-end can easily generate IR
that can be consumed by LLVM as if it was passed directly (ie. no
additional settings that influence code-gen other than what's in the
IR or can be set via llc). If the IR is still big, you may still try
to reduce it using bugpoint [3,4,5]. I'm not very familiar with it
(though I really should), but it's supposed to work similar to creduce
(among other things). Give it a shot.

Once you have the IR, make sure your version of llc (if you have one)
can still reproduce the problem and record the options you have used
(something similar to "-triple thumbv7a-linux-gnueabihf -mfpu=vfpv3").
Once you can reliably repeat the problem with your llc, try it with
upstream's llc (recent 3.9-trunk). Fiddle with the parameters if you
do pass them differently on your own toolchain, until you can
reproduce the bug with upstream llc.


3. Submit the bug [6]

Once you have a small IR that can reproduce the problem with upstream
llc, you can create a bug, attach the IR and provide the exact command
line for llc (or another tool) that reproduces your problem. I imagine
that, whatever the problem is, will be one of three things:

1. Your front-end is producing invalid IR
2. Your front-end is producing valid IR, but one not produced by
Clang, so not heavily tested
3. You just found a bug in LLVM

If we got 1 or 2, it's not something terribly wrong, or validate()
wouldn't pass, but different enough to cause failures. In those cases,
some middle-end optimisation is meddling it up and the back-end gets
confused, but not completely so. This is possible, but less probably
than number 3.

I bet it's 3, maybe 2, unlikely 1.

Let me know how it goes.

cheers,
--renato

[1] http://llvm.org/docs/LangRef.html
[2] https://embed.cs.utah.edu/creduce/
[3] http://llvm.org/docs/Bugpoint.html
[4] http://logan.tw/posts/2014/11/26/llvm-bugpoint/
[5] https://zneak.github.io/fcd/2016/03/16/bugpoint.html
[6] http://llvm.org/docs/HowToSubmitABug.html


More information about the llvm-commits mailing list