Re: [cfe-users] HELP!The clang crashed and I don't know why

2018-01-15 Thread Jan Korous via cfe-users 
Hi.

Could you please look for the preprocessed source and associated run script? 

I am not sure about clang 3.7 but newer versions tell you where to look for 
these. E. g.:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-7.0: note: diagnostic msg: 
/var/folders/fn/mprhw6vn429333rw1h0flzx4gn/T/foo-83341e.cpp
clang-7.0: note: diagnostic msg: 
/var/folders/fn/mprhw6vn429333rw1h0flzx4gn/T/foo-83341e.sh

You might also try to check your working directory or the directory where the 
binary goes to.

Please create a bug report in Bugzilla and attach those files so someone can 
try to reproduce and fix the bug.
https://bugs.llvm.org/ 

Thank you.

Jan



> On 15 Jan 2018, at 07:24, 白い 騎士 via cfe-users  
> wrote:
> 
> 0x01CBA6DB (0x08F33708 0x08F1F4C4 0x08F33710 0x096FDB38)  
>   
> 0x01CBC8E2 (0x08F1F4C4 0x09A5A2C8 0x 0x08BA9EE0)  
>   
> 0x01C5DB42 (0x08BA9EE0 0x09A5A2C8 0x09A5A2C8 0x08F456E0)  
>   
> 0x01C61833 (0x19D790E8 0x0374E8AC 0x017DD30A 0x09D790E8)  
>   
> 0x013B5462 (0x09D790E8 0x 0x0374E900 0x01892F9D)  
>   
> 0x017DD30A (0x08BA9EE0 0x0001 0x01153008 0x08BA9EE0)  
>   
> 0x01892F9D (0x08BA9EE0 0x08F456D0 0x011530AC 0x)  
>   
> 0x0189306A (0x01153030 0x 0x011A23D0 0x0374EA01)  
>   
> 0x018931F1 (0x01153030 0x01153008 0x01153008 0x0374EA18)  
>   
> 0x01892C3D (0x01153030 0x01130B80 0x01147488 0x0114C288)  
>   
> 0x01D1C601 (0x0005 0x01147488 0x01130B80 0x02CE4B69)  
>   
> 0x01D1C6A3 (0x0114C288 0x01142DD0 0x01130B80 0x01131A10)  
>   
> 0x01D11C21 (0x01139330 0x0112B9F8 0x02D08AB8 0x01BC8FF3)  
>   
> 0x01BE38EF (0x01139330 0x01138648 0x0112B9F8 0x0112B9F8)  
>   
> 0x01C14B03 (0x0112B9F8 0x0374F860 0x0114C711 0x0374F7B4)  
>   
> 0x012E1B57 (0x0374F7BC 0x0029 0x0114C6D8 0x012DE690)  
>   
> 0x012DE44B (0x0374F7B4 0x002B 0x0114C710 0x)  
>   
> 0x012E09F0 (0x002B 0x011421F8 0x01137420 0xC45CA5CF)  
>   
> 0x02599B81 (0x00F15000 0x770162A0 0x6F295D38 0x0374FCF4)  
>   
> 0x770162C4 (0x00F15000 0x9E499336 0x 0x), 
> BaseThreadInitThunk() + 0x24 bytes(s) 
> 0x77ED0609 (0x 0x77EF2522 0x 0x), 
> RtlSubscribeWnfStateChangeNotification() + 0x439 bytes(s) 
> 0x77ED05D4 (0x02599BE9 0x00F15000 0x 0x), 
> RtlSubscribeWnfStateChangeNotification() + 0x404 bytes(s) clang++.exe: 
> error: clang frontend command failed due to signal (use -v to see invocation) 
>  
> clang version 3.7.0 (trunk)   
>   
> Target: i686-pc-windows-msvc  
>   
> Thread model: posix   
>   
> clang++.exe: note: diagnostic msg: PLEASE submit a bug report to 
> http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, 
> and associated run script.
>  
> clang++.exe: note: diagnostic msg: Error generating preprocessed source(s) - 
> no preprocessable inputs. 
> ___
> 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] eBPF: Odd optimization results with clang-5.0

2018-01-15 Thread Yonghong Song via cfe-users 



On 1/8/18 5:45 AM, Jiong Wang wrote:

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.


Thanks for investigation.

Looks like the IR before "and" operation is introduced, IR looks like
  %call = call i64 @llvm.bpf.load.byte(i8* %0, i64 0)
  %conv = trunc i64 %call to i8
  %conv1 = zext i8 %conv to i32
  ret i32 %conv1

and the "Combine redundant instructions" phase changes it to:
  %call = call i64 @llvm.bpf.load.byte(i8* %0, i64 0)
  %conv = trunc i64 %call to i32
  %conv1 = and i32 %conv, 255
  ret i32 %conv1

while for ok1, IR looks like:
  %call = call i64 @llvm.bpf.load.byte(i8* %0, i64 0)
  %conv = trunc i64 %call to i32
  ret i32 %conv

One thing we could do is to do this optimization at BPF backend during
DAG2DAG transformation, since it understands the llvm.bpf.load.byte
semantics.




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.


I disabled this optimization and original condition "==" is preserved,
we still have the inefficient code:
Disassembly of section bug2_sec:
bug2:
   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:   15 00 01 00 01 00 00 00 if r0 == 1 goto +1 
   4:   05 00 04 00 00 00 00 00 goto +4 

LBB4_1:
   5:   30 00 00 00 01 00 00 00 r0 = *(u8 *)skb[1]
   6:   b7 07 00 00 15 00 00 00 r7 = 21
   7:   15 00 01 00 01 00 00 00 if r0 == 1 goto +1 
   8:   b7 07 00 00 00 00 00 00 r7 = 0

LBB4_3:
   9:   bf 70 00 00 00 00 00 00 r0 = r7
  10:   95 00 00 00 00 00 00 00 exit

Right, the insn 7 and 8 can be removed. But since the "switch" to "cond"
transformation happens in insn selection, it may be too late for
the redundant condition elimination...
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

[cfe-users] clang-format: Custom Language

2018-01-15 Thread Charles Welton via cfe-users 
I have been using clang-format in a certain C++ project successfully and
everything is great... but we also need support for a custom scripting
language.

This scripting language is much like C++, and clang-format works fine for
the most part except for some specific constructs ("a ?? b" is an example
of such a construct).

How would we go along adding support for this specific language in
clang-format?
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users