[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag

Fri Jun 3 00:12:59 PDT 2016

To avoid this error, I have attached a patch. Could you review it?

On Fri, Jun 3, 2016 at 3:18 PM, Geunsik Lim <leemgs at gmail.com> wrote:

> It's strange. I have got the below build error messages when I tried to
> merge r268662 into Ubuntu 14.04 x64 (Trusty) distribution.
> It seems that this build error is generated by
> test/FileCheck/check-empty.txt.
> Did you have similar experience like me? Is this related to the version of
> the LLVM?
>
> >
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/Release/bin/llc:
>
> > /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/test/CodeGen/ARM/litpool-licm.ll:29:18:
> error: expected value token
> >   %val = load i32, i32* @var
> >                  ^
> > FileCheck error: '-' is empty.
>
>
>
> --------- Detail error messages
> ---------------------------------------------------------------------------------------------------
>             . . . . Omission . . . .
>
> make[1]: Entering directory
> `/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6'
> NJOBS="-j 8"
> LD_LIBRARY_PATH=/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/Release/lib/
> /usr/bin/make -C build-llvm check
> make[2]: Entering directory
> `/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm'
> llvm[2]: Running test suite
> make[3]: Entering directory
> `/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/test'
> Making LLVM 'lit.site.cfg' file...
> Making LLVM unittest 'lit.site.cfg' file...
> ( ulimit -t 600 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -s 8192 ; \
>  /usr/bin/python
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/utils/lit/lit.py
> -s -v -j 8 . )
> lit.py: lit.cfg:271: note: Did not find llvm-go in
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/Release/bin
> FAIL: LLVM :: CodeGen/ARM/litpool-licm.ll (1638 of 12267)
> ******************** TEST 'LLVM :: CodeGen/ARM/litpool-licm.ll' FAILED
> ********************
> Script:
> --
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/Release/bin/llc
> -mtriple=thumbv7-linux-gnueabihf -relocation-model=pic
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/test/CodeGen/ARM/litpool-licm.ll
> -o - |
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/Release/bin/FileCheck
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/test/CodeGen/ARM/litpool-licm.ll
> --
> Exit Code: 2
>
> Command Output (stderr):
> --
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/Release/bin/llc:
> /work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/test/CodeGen/ARM/litpool-licm.ll:29:18:
> error: expected value token
>   %val = load i32, i32* @var
>                  ^
> FileCheck error: '-' is empty.
>
> --
>
> ********************
> Testing Time: 39.24s
> ********************
> Unexpected Passing Tests (12):
>     LLVM :: BugPoint/crash-narrowfunctiontest.ll
>     LLVM :: BugPoint/metadata.ll
>     LLVM :: BugPoint/remove_arguments_test.ll
>     LLVM :: ExecutionEngine/MCJIT/cross-module-sm-pic-a.ll
>     LLVM :: ExecutionEngine/MCJIT/eh-lg-pic.ll
>     LLVM :: ExecutionEngine/MCJIT/eh-sm-pic.ll
>     LLVM :: ExecutionEngine/MCJIT/hello-sm-pic.ll
>     LLVM :: ExecutionEngine/MCJIT/multi-module-sm-pic-a.ll
>     LLVM :: ExecutionEngine/MCJIT/stubs-sm-pic.ll
>     LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-sm-pic.ll
>     LLVM :: ExecutionEngine/MCJIT/test-ptr-reloc-sm-pic.ll
>     LLVM :: Feature/load_module.ll
>
> ********************
> Failing Tests (1):
>     LLVM :: CodeGen/ARM/litpool-licm.ll
>
>   Expected Passes    : 11998
>   Expected Failures  : 75
>   Unsupported Tests  : 181
>   Unexpected Passes  : 12
>   Unexpected Failures: 1
> make[3]: *** [check-local] Error 1
> make[3]: Leaving directory
> `/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm/test'
> make[2]: *** [check] Error 2
> make[2]: Leaving directory
> `/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6/build-llvm'
> make[1]: *** [override_dh_auto_test] Error 2
> make[1]: Leaving directory
> `/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6'
> make: *** [binary] Error 2
> Command exited with non-zero status 2
> 100.38user 45.56system 0:40.75elapsed 358%CPU (0avgtext+0avgdata
> 538244maxresident)k
> 0inputs+180240outputs (6major+32138062minor)pagefaults 0swaps
> invain at db400
> :/work/dotnet/llvm-3.6.2.fixed.packaging/llvm-toolchain-3.6-3.6$
>
>
>
> ------------------------------------------------------------------------------------------------------------
>
> On Fri, May 20, 2016 at 11:58 PM, Geunsik Lim <leemgs at gmail.com> wrote:
>
>> > BTW, I am afraid that I can merge the patch to Ubuntu 14.04 and Ubuntu
>> 16.04  LTS repository to support
>> > the easy update (e.g. apt-get install llvm-3.6).
>>
>> I have posted this issue to Ubuntu's launchpad bug system
>> (e.g. llvm-defaults package) as following:
>> * https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1584089
>>
>>
>> On Fri, May 20, 2016 at 11:20 PM, Geunsik Lim <leemgs at gmail.com> wrote:
>>
>>> > I'd be happy to look at the various clsload.cpp.o files produced
>>> > (there is more than 1 and I can't actually remember which had the
>>> > problem I'm afraid) and tell you if the TLS accesses are sane.
>>>
>>> I have verified that r268662 can resolve the __thread variable issue
>>> that I reported to LLVM community.
>>> Thank you for your technical support to fix ARM code generation of LLVM
>>> back-end.
>>>
>>> BTW, I am afraid that I can merge the patch to Ubuntu 14.04 and Ubuntu
>>> 16.04  LTS repository to support
>>> the easy update (e.g. apt-get install llvm-3.6).
>>>
>>> On Fri, May 20, 2016 at 7:49 AM, Geunsik Lim <leemgs at gmail.com> wrote:
>>>
>>>> >So, I am analyzing the build process of CoreCLR  to know why we can
>>>> not see the 'std::cout' message while compiling
>>>>
>>>> I have verified that the modified ARMConstantPoolValue.cpp.o is related
>>>> to the below files form the our build system. As you can see,  there are
>>>> two libraries (e.g. and ) at the linking procedure;
>>>> libLLVMARMCodeGen.a(static library)  and libLTO.so (shared library).
>>>>
>>>> * LLVM-3.6 - Building to support Linux/ARM:
>>>> Building CXX object
>>>> lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/ARMConstantPoolValue.cpp.o
>>>>
>>>> * LLVM-3.6 - Linking files:
>>>>
>>>> Linking CXX static library ../../libLLVMARMCodeGen.a
>>>> Linking CXX executable ../../bin/llc
>>>> Linking CXX executable ../../bin/llvm-ar
>>>> Linking CXX executable ../../bin/llvm-nm
>>>> Linking CXX executable ../../bin/llvm-objdump
>>>> Linking CXX executable ../../bin/opt
>>>> Linking CXX executable ../../bin/llvm-mc
>>>> Linking CXX executable ../../bin/llvm-readobj
>>>> Linking CXX executable ../../bin/llvm-rtdyld
>>>> Linking CXX executable ../../bin/llvm-c-test
>>>> Linking CXX shared library ../../lib/libLTO.so
>>>> Linking CXX executable ../../bin/llvm-lto
>>>>
>>>> Actually, I have simply overwritten the all generated files into the
>>>> existing LLVM folder (.e.g. /usr/lib/llvm-3.6 and /usr/include/llvm-* ) in
>>>> the build system.  However, existing clang has been operating with single
>>>> shared library (LLVM_BUILD_LLVM_DYLIB:BOOL). It was why I could not see the
>>>> 'std::cout" message at build time of CoreCLR. So, I have tried to make
>>>> self-made clang/llvm in my home folder ($HOME/llvm-3.6/) after uninstalling
>>>> temporarily all clang/llvm packages that are installed in build system.
>>>> Then, I could see the stdout message normally. I expect that the doing not
>>>> merging multiple 'ldr' instructions will be executed  for using __thread
>>>> variable in Linux/ARM environment. I will shortly tell you the experimental
>>>> result of the additional comparisons such as 'Modifier' and
>>>> 'AddCurrentAddress'.
>>>>
>>>> -      ACPV->Modifier == Modifier) {
>>>> -    if (ACPV->LabelId == LabelId)
>>>> -      return true;
>>>> +      ACPV->Modifier == Modifier &&
>>>> +      ACPV->LabelId == LabelId &&
>>>> +      ACPV->AddCurrentAddress == AddCurrentAddress) {
>>>>
>>>>
>>>>
>>>> On the other hands, It seems that Android developers have tried to
>>>> append emulated-TLS instead of the direct TLS usage to avoid
>>>> architecture-dependent operation situation. In this case, is problem is
>>>> just speed?
>>>> * Clang/driver: emulated TLS mode - http://reviews.llvm.org/D10524
>>>>
>>>> BRs,
>>>> Geunsik Lim.
>>>> > Maybe the build system is suppressing stdout for some reason?
>>>> I think that the build system does not suppress stdout at build-time if
>>>> I append "verbose" option.
>>>> So, I am analyzing the build process of CoreCLR  to know why we can not
>>>> see the 'std::cout' message while compiling
>>>> CoreCLR with clang/llvm(including your patch)
>>>>
>>>>
>>>>
>>>> On Wed, May 18, 2016 at 12:09 PM, Tim Northover <
>>>> t.p.northover at gmail.com> wrote:
>>>>
>>>>> On 17 May 2016 at 19:22, Geunsik Lim <leemgs at gmail.com> wrote:
>>>>> > It's strange. I could not see the "[DEBUG] ****" message while
>>>>> compiling
>>>>> > CoreCLR  with Clang/LLVM for Linux/ARM. Is it right? Can you give me
>>>>> an
>>>>> > opinion?
>>>>>
>>>>> That strongly suggests something is wrong. That function ought to be
>>>>> called hundreds of times while building the source, regardless of the
>>>>> changed outcome after my patch. Maybe the build system is suppressing
>>>>> stdout for some reason?
>>>>>
>>>>> I'd be happy to look at the various clsload.cpp.o files produced
>>>>> (there is more than 1 and I can't actually remember which had the
>>>>> problem I'm afraid) and tell you if the TLS accesses are sane.
>>>>>
>>>>> Cheers.
>>>>>
>>>>> Tim.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://leemgs.fedorapeople.org
>>>> Don't try to avoid pain if you fail.
>>>> If you decided to face the challenges in life,
>>>> you can gain a lot by giving your best.
>>>> Cheolsang Jeong's Book & life
>>>> --
>>>>
>>>
>>>
>>>
>>> --
>>> http://leemgs.fedorapeople.org
>>> Don't try to avoid pain if you fail.
>>> If you decided to face the challenges in life,
>>> you can gain a lot by giving your best.
>>> Cheolsang Jeong's Book & life
>>> --
>>>
>>
>>
>>
>> --
>> http://leemgs.fedorapeople.org
>> Don't try to avoid pain if you fail.
>> If you decided to face the challenges in life,
>> you can gain a lot by giving your best.
>> Cheolsang Jeong's Book & life
>> --
>>
>
>
>
> --
> http://leemgs.fedorapeople.org
> Don't try to avoid pain if you fail.
> If you decided to face the challenges in life,
> you can gain a lot by giving your best.
> Cheolsang Jeong's Book & life
> --
>

-- 
http://leemgs.fedorapeople.org
Don't try to avoid pain if you fail.
If you decided to face the challenges in life,
you can gain a lot by giving your best.
Cheolsang Jeong's Book & life
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160603/e2c9bf62/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Linux-ARM-Fix-incorrect-load-statement.patch
Type: text/x-patch
Size: 778 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160603/e2c9bf62/attachment.bin>