[cfe-users] clang frontend command failed due to signal
Hello everyone: I'm building libcxx on amd64 ubuntu 14.04 for testing cloud9, but encountered the following fatal issue that clang caused. The program arguments are as follows: /home/bruce/Cloud9_Root/src/third_party/llvm-build/Release+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -disable-free -main-file-name condition_variable.cpp -pic-level 2 -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.24 -momit-leaf-frame-pointer -g -coverage-file out/Default/obj.target/libcxx/libcxx/src/condition_variable.o -nostdinc++ -resource-dir /home/bruce/Cloud9_Root/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.1 -dependency-file out/Default/.deps/out/Default/obj.target/libcxx/libcxx/src/condition_variable.o.d.raw -MT out/Default/obj.target/libcxx/libcxx/src/condition_variable.o -D _FILE_OFFSET_BITS=32 -I libcxx/include -fmodule-cache-path /var/tmp/clang-module-cache -c-isystem /usr/include/x86_64-linux-gnu/c++/4.8/ -c-isystem /home/bruce/Cloud9_Root/src/cloud9/include/ -cxx-isystem /usr/include/x86_64-linux-gnu/c++/4.8/ -cxx-isystem /home/bruce/Cloud9_Root/src/cloud9/include/ -internal-isystem /usr/local/include -internal-isystem /home/bruce/Cloud9_Root/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -Os -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded -Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4 -std=c++0x -fdeprecated-macro -fdebug-compilation-dir /home/bruce/Cloud9_Root/src/testing_targets -ferror-limit 19 -fmessage-length 143 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o out/Default/obj.target/libcxx/libcxx/src/condition_variable.o -x c++ libcxx/src/condition_variable.cpp But it failed with the following error, and I can not understand why. 1. libcxx/include/__config:1028:3: current parser token 'if' 2. libcxx/include/__config:448:1: parsing namespace 'std' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) I am a newbee on clang , and I have tried my best to google what I can do to solve it. But I failed. Does anyone encounter the same problem or know how to slove it. I can provide libcxx source code if someone responses to me. Thanks in advance. bruce___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang frontend command failed due to signal
Since clang segfaults, it could be a bug in clang. I am not a clang expert, but I'd suggest trying to remove some of the compiler flags and observe if the output changes. Or you could try to use a different version of clang/llvm. And then file a bug for clang if you can reproduce the crash. 01_Tyro_10 via cfe-users writes: > Hello everyone: > I'm building libcxx on amd64 ubuntu 14.04 for testing cloud9, but encountered > the following fatal issue that clang caused. > > > The program arguments are as follows: > /home/bruce/Cloud9_Root/src/third_party/llvm-build/Release+Asserts/bin/clang > -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -disable-free > -main-file-name condition_variable.cpp -pic-level 2 -masm-verbose > -mconstructor-aliases -munwind-tables -target-cpu x86-64 > -target-linker-version 2.24 -momit-leaf-frame-pointer -g -coverage-file > out/Default/obj.target/libcxx/libcxx/src/condition_variable.o -nostdinc++ > -resource-dir > /home/bruce/Cloud9_Root/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.1 > -dependency-file > out/Default/.deps/out/Default/obj.target/libcxx/libcxx/src/condition_variable.o.d.raw > -MT out/Default/obj.target/libcxx/libcxx/src/condition_variable.o -D > _FILE_OFFSET_BITS=32 -I libcxx/include -fmodule-cache-path > /var/tmp/clang-module-cache -c-isystem /usr/include/x86_64-linux-gnu/c++/4.8/ > -c-isystem /home/bruce/Cloud9_Root/src/cloud9/include/ -cxx-isystem > /usr/include/x86_64-linux-gnu/c++/4.8/ -cxx-isystem > /home/bruce/Cloud9_Root/src/cloud9/include/ -internal-isystem > /usr/local/include -internal-isystem > /home/bruce/Cloud9_Root/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.1/include > -internal-externc-isystem /usr/include/x86_64-linux-gnu > -internal-externc-isystem /include -internal-externc-isystem /usr/include -Os > -Wall -Wextra -Wshadow -Wconversion -Wnewline-eof -Wpadded > -Wmissing-prototypes -Wstrict-aliasing=2 -Wstrict-overflow=4 -std=c++0x > -fdeprecated-macro -fdebug-compilation-dir > /home/bruce/Cloud9_Root/src/testing_targets -ferror-limit 19 -fmessage-length > 143 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc > -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions > -fdiagnostics-show-option -fcolor-diagnostics -o > out/Default/obj.target/libcxx/libcxx/src/condition_variable.o -x c++ > libcxx/src/condition_variable.cpp > > > But it failed with the following error, and I can not understand why. > 1.libcxx/include/__config:1028:3: current parser token 'if' > 2.libcxx/include/__config:448:1: parsing namespace 'std' > clang: error: unable to execute command: Segmentation fault (core dumped) > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > > > > > > I am a newbee on clang , and I have tried my best to google what I can do to > solve it. But I failed. > > > Does anyone encounter the same problem or know how to slove it. I can provide > libcxx source code if someone responses to me. > > > Thanks in advance. > > > bruce > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang frontend command failed due to signal
Hi bruce, which version of clang are you actually using? Could you please paste output of clang -v here? Could you please also paste full output of clang (including reproducer files if any)? Thank you. Jan > On 8 Jan 2018, at 10:36, 01_Tyro_10 via cfe-users > wrote: > > bruce ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] eBPF: Odd optimization results with clang-5.0
Hi,
just tested the clang eBPF backend. Very cool thing :)
But I've noticed that the codegen creates really odd things which I
cannot explain from my understanding of the ISA. My test is attached
and was compiled via:
clang -O2 -target bpf -x c -c ebpf_opimizer_problems.o -o
ebpf_opimizer_problems.o
llvm-objdump -S ebpf_opimizer_problems.o
First thing is the odd way how 8 bit loads to an uint8_t are handled
(see bug1_sec):
0: bf 16 00 00 00 00 00 00 r6 = r1
1: 30 00 00 00 00 00 00 00 r0 = *(u8 *)skb[0]
2: 57 00 00 00 ff ff 00 00 r0 &= 65535
3: 95 00 00 00 00 00 00 00 exit
I have no idea why the second instruction (line "2:") would be
required when there was just a load of 8 bit to the 64 bit register.
This isn't generated when it is stored in an uint32_t or uint64_t
variable (but also when storing it in an uint16_t). This can be seen
in ok1_sec, ok1_too_a_sec and ok1_too_b_sec.
The other problem is the chaining of tests which results in an extra
store for the temporary output register (r7, see bug2_sec):
0: bf 16 00 00 00 00 00 00 r6 = r1
1: b7 07 00 00 00 00 00 00 r7 = 0
2: 30 00 00 00 00 00 00 00 r0 = *(u8 *)skb[0]
3: 55 00 04 00 01 00 00 00 if r0 != 1 goto 4
4: 30 00 00 00 01 00 00 00 r0 = *(u8 *)skb[1]
5: b7 07 00 00 15 00 00 00 r7 = 21
6: 15 00 01 00 01 00 00 00 if r0 == 1 goto 1
7: b7 07 00 00 00 00 00 00 r7 = 0
LBB4_3:
8: bf 70 00 00 00 00 00 00 r0 = r7
9: 95 00 00 00 00 00 00 00 exit
For unknown reasons, the line "6:" was changed from an JNE to an JEQ.
This makes it necessary to introduce link "5:" and line "7:". It would
have been better (in my eyes) to use keep it an JNE, move line "5:"
after the comparison and drop line "7:". This would look like this
(removed the bytecode to make it easier for me):
0: r6 = r1
1: r7 = 0
2: r0 = *(u8 *)skb[0]
3: if r0 != 1 goto 3
4: r0 = *(u8 *)skb[1]
5: if r0 != 1 goto 1
6: r7 = 21
LBB4_3:
7: r0 = r7
8: exit
Or a different version (not so easily readable because it is
asymmetric) would have been:
0: bf 16 00 00 00 00 00 00 r6 = r1
1: 30 00 00 00 00 00 00 00 r0 = *(u8 *)skb[0]
2: 55 00 03 00 01 00 00 00 if r0 != 1 goto 3
3: b7 07 00 00 15 00 00 00 r7 = 21
4: 30 00 00 00 01 00 00 00 r0 = *(u8 *)skb[1]
5: 15 00 01 00 01 00 00 00 if r0 == 1 goto 1
LBB4_2:
6: b7 07 00 00 00 00 00 00 r7 = 0
LBB4_3:
7: bf 70 00 00 00 00 00 00 r0 = r7
8: 95 00 00 00 00 00 00 00 exit
The used version (Debian buster amd64) is:
clang version 5.0.1-2 (tags/RELEASE_501/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
#include
#include
struct __sk_buff;
unsigned long long load_byte(void *skb, unsigned long long off) asm("llvm.bpf.load.byte");
/* FIRST eBPF optimizer "BUG" */
__attribute__((section("bug1_sec"), used))
int bug1(struct __sk_buff *skb)
{
uint8_t t = load_byte(skb, 0);
return t;
}
__attribute__((section("ok1_sec"), used))
int ok1(struct __sk_buff *skb)
{
return load_byte(skb, 0);
}
__attribute__((section("ok1_too_a_sec"), used))
int ok1_too_a(struct __sk_buff *skb)
{
uint32_t t = load_byte(skb, 0);
return t;
}
__attribute__((section("ok1_too_b_sec"), used))
int ok1_too_b(struct __sk_buff *skb)
{
uint64_t t = load_byte(skb, 0);
return t;
}
/* SECOND eBPF optimizer "BUG" */
__attribute__((section("bug2_sec"), used))
int bug2(struct __sk_buff *skb)
{
uint64_t t;
t = load_byte(skb, 0);
if (t != 1)
return 0;
t = load_byte(skb, 1);
if (t != 1)
return 0;
return 21;
}
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] eBPF: Odd optimization results with clang-5.0
On Fri, Jan 5, 2018 at 7:01 AM, Charlemagne Lasse wrote: > Hi, > > just tested the clang eBPF backend. Very cool thing :) > > But I've noticed that the codegen creates really odd things which I > cannot explain from my understanding of the ISA. My test is attached > and was compiled via: > > clang -O2 -target bpf -x c -c ebpf_opimizer_problems.o -o > ebpf_opimizer_problems.o > llvm-objdump -S ebpf_opimizer_problems.o > > First thing is the odd way how 8 bit loads to an uint8_t are handled > (see bug1_sec): > > 0: bf 16 00 00 00 00 00 00 r6 = r1 > 1: 30 00 00 00 00 00 00 00 r0 = *(u8 *)skb[0] > 2: 57 00 00 00 ff ff 00 00 r0 &= 65535 > 3: 95 00 00 00 00 00 00 00 exit > > I have no idea why the second instruction (line "2:") would be > required when there was just a load of 8 bit to the 64 bit register. > This isn't generated when it is stored in an uint32_t or uint64_t > variable (but also when storing it in an uint16_t). This can be seen > in ok1_sec, ok1_too_a_sec and ok1_too_b_sec. > > The other problem is the chaining of tests which results in an extra > store for the temporary output register (r7, see bug2_sec): > > 0: bf 16 00 00 00 00 00 00 r6 = r1 > 1: b7 07 00 00 00 00 00 00 r7 = 0 > 2: 30 00 00 00 00 00 00 00 r0 = *(u8 *)skb[0] > 3: 55 00 04 00 01 00 00 00 if r0 != 1 goto 4 > 4: 30 00 00 00 01 00 00 00 r0 = *(u8 *)skb[1] > 5: b7 07 00 00 15 00 00 00 r7 = 21 > 6: 15 00 01 00 01 00 00 00 if r0 == 1 goto 1 > 7: b7 07 00 00 00 00 00 00 r7 = 0 > > LBB4_3: > 8: bf 70 00 00 00 00 00 00 r0 = r7 > 9: 95 00 00 00 00 00 00 00 exit > > For unknown reasons, the line "6:" was changed from an JNE to an JEQ. > This makes it necessary to introduce link "5:" and line "7:". It would > have been better (in my eyes) to use keep it an JNE, move line "5:" > after the comparison and drop line "7:". This would look like this > (removed the bytecode to make it easier for me): > > 0: r6 = r1 > 1: r7 = 0 > 2: r0 = *(u8 *)skb[0] > 3: if r0 != 1 goto 3 > 4: r0 = *(u8 *)skb[1] > 5: if r0 != 1 goto 1 > 6: r7 = 21 > LBB4_3: > 7: r0 = r7 > 8: exit > > Or a different version (not so easily readable because it is > asymmetric) would have been: > >0: bf 16 00 00 00 00 00 00 r6 = r1 > 1: 30 00 00 00 00 00 00 00 r0 = *(u8 *)skb[0] > 2: 55 00 03 00 01 00 00 00 if r0 != 1 goto 3 > 3: b7 07 00 00 15 00 00 00 r7 = 21 > 4: 30 00 00 00 01 00 00 00 r0 = *(u8 *)skb[1] > 5: 15 00 01 00 01 00 00 00 if r0 == 1 goto 1 > > LBB4_2: > 6: b7 07 00 00 00 00 00 00 r7 = 0 > > LBB4_3: > 7: bf 70 00 00 00 00 00 00 r0 = r7 > 8: 95 00 00 00 00 00 00 00 exit > > > The used version (Debian buster amd64) is: > > clang version 5.0.1-2 (tags/RELEASE_501/final) > Target: x86_64-pc-linux-gnu > Thread model: posix > InstalledDir: /usr/bin thank you for reporting these issues. It does look odd. Not sure whether it's related to any recent changes. Needs more investigation. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] eBPF: Odd optimization results with clang-5.0
On 05/01/2018 20:05, Alexei Starovoitov wrote:
On Fri, Jan 5, 2018 at 7:01 AM, Charlemagne Lasse
wrote:
First thing is the odd way how 8 bit loads to an uint8_t are handled
(see bug1_sec):
I could reproduce both issues on other targets on latest LLVm trunk@321940,
for example AArch64 (need to remove asm("llvm.bpf.load.byte") from the
testcase.
For the first issue, it seems to be i8/i16 will be promoted to i32, so for
bug1_sec, the sequence is:
t6: i32 = truncate t5
t8: i32 = and t6, Constant:i32<255>
t9: i64 = any_extend t8
while for ok1, it is;
t6: i32 = truncate t5
t9: i64 = any_extend t6
For ok1 sequence, LLVM is doing (aext (trunx x)) -> x, while for bug1_sec
sequence, LLVM is not doing combination which is correct as it doesn't
understand the return value of llvm.bpf.load.byte is zero extended to i64
so combine the bug1_sec sequence will lost the effect of and instruction.
For unknown reasons, the line "6:" was changed from an JNE to an JEQ.
LLVM is doing geneirc canonicalizations inside
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:
// If the lhs block is the next block, invert the condition so that we can
// fall through to the lhs instead of the rhs block.
--
Regards,
Jiong
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Problem compiling simple main.c with llvm-5.0
On 28.12.2017 20:31, Don Hinton wrote: Looks like AVR is experimental, so you'll need to pass it via -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="AVR" As for the correct --target, you can take a look at the logic in llvm/cmake/config.guess to get an idea on how to construct one. hth... don Ok, thanks for your information. As it didn't appear to work, I just returned to GCC for now. Thanks for your help. On Wed, Dec 13, 2017 at 2:15 AM, via cfe-users wrote: Hi, I am new to llvm, so my first question is if this is the right mailing list to address respective problems using that software. I downloaded the llvm 5.0.0 binary bundle, and I can compile simple main.c for x64_64 host. However, when .../bin/clang main.c --target=avr error: unable to create target: 'No available targets are compatible with this triple.' 1 error generated. As --help is not much help, I tried guessing around using targets elf32-avr, avr-unknown-none, all giving the same, unspecific diagnostic (so much for "extremely useful error and warning messages"). https://clang.llvm.org/docs/CrossCompilation.html claims: On the other hand, Clang/LLVM is natively a cross-compiler, meaning that one set of programs can compile to all targets by setting the -target option. I checked the v5.0 sources, there are plenty of modules dealing with AVR, so that target should be supported. No? So I downloaded the llvm 5.0.0 source bundle and configured for AVR: $ cmake -G "Unix Makefiles" -DLLVM_TARGETS_TO_BUILD="AVR" ../../source/llvm-5.0.0.src/ But: -- Constructing LLVMBuild project information CMake Error at CMakeLists.txt:688 (message): The target `AVR' does not exist. It should be one of AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX; PowerPC;Sparc;SystemZ;X86;XCore -- Configuring incomplete, errors occurred! See also ".../build/llvm-5-avr/CMakeFiles/CMakeOutput.log". See also ".../build/llvm-5-avr/CMakeFiles/CMakeError.log". The 5.0.0 release notes have some mention of AVR http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html#change s-to-the-avr-target so I'd expect this target is supported? Thanks for any help. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang frontend command failed due to signal
On 8/01/2018 11:36 PM, 01_Tyro_10 via cfe-users wrote: But it failed with the following error, and I can not understand why. 1.libcxx/include/__config:1028:3: current parser token 'if' 2.libcxx/include/__config:448:1: parsing namespace 'std' clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) Make sure you're not running out of memory. Chris ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
