[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
Geunsik Lim via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 2 23:18:54 PDT 2016
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
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160603/349f59c4/attachment.html>
More information about the llvm-commits
mailing list