[llvm-bugs] [Bug 36104] New: LoopUnrollPass is not updating parameters of DbgValueInst correctly

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36104

Bug ID: 36104
   Summary: LoopUnrollPass is not updating parameters of
DbgValueInst correctly
   Product: libraries
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Loop Optimizer
  Assignee: unassignedb...@nondot.org
  Reporter: agu...@tifr.res.in
CC: llvm-bugs@lists.llvm.org

Consider following input to LoopUnroll pass to be unrolled two times.

define i32 @main() #0 !dbg !7 {
  call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !11, metadata !12),
!dbg !13
  br label %1, !dbg !14

; :1:  ; preds = %1, %0
  %.0 = phi i32 [ 0, %0 ], [ %3, %1 ]
  call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
  %2 = icmp slt i32 %.0, 5, !dbg !15
  %3 = add nsw i32 %.0, 1, !dbg !18
  call void @llvm.dbg.value(metadata i32 %3, i64 0, metadata !11, metadata
!12), !dbg !13
  br i1 %2, label %1, label %4, !dbg !20, !llvm.loop !21

; :4:  ; preds = %1
  ret i32 0, !dbg !23
}


After rotating and unrolling (unrolling requires rotating), we obtain:

define i32 @main() #0 !dbg !7 {
  call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !11, metadata !12),
!dbg !13
  br label %1, !dbg !14

; :1:  ; preds = %6, %0
  %.0 = phi i32 [ 0, %0 ], [ %8, %6 ]
  call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
  %2 = add nuw nsw i32 %.0, 1, !dbg !15
  call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
  call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
  %3 = icmp ult i32 %2, 5, !dbg !19
  %4 = add nuw nsw i32 %2, 1, !dbg !15
  call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
  br i1 %3, label %6, label %5, !dbg !20, !llvm.loop !21

; :5:  ; preds = %1
  ret i32 0, !dbg !23

; :6:  ; preds = %1
  call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
  %7 = add nuw nsw i32 %4, 1, !dbg !15
  call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
  call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
  %8 = add nuw nsw i32 %7, 1, !dbg !15
  call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
  br label %1
}



Look at the the copied body in block 6. Note that the dbg.value after %7 is not
updated and still reflects %2. IMHO, it is wrong cloning of the block.


I think the problem lies in the following function of LoopUnroll.cpp:67

static inline void remapInstruction(Instruction *I,
ValueToValueMapTy ) {
  for (unsigned op = 0, E = I->getNumOperands(); op != E; ++op) {
Value *Op = I->getOperand(op); <<<
ValueToValueMapTy::iterator It = VMap.find(Op);
if (It != VMap.end())
  I->setOperand(op, It->second); <<<
  }

  if (PHINode *PN = dyn_cast(I)) {
for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) {
  ValueToValueMapTy::iterator It = VMap.find(PN->getIncomingBlock(i));
  if (It != VMap.end())
PN->setIncomingBlock(i, cast(It->second));
}
  }
}


This function fails to pick the the right argument of a DbgValueInst. 0th Op is
not a Value but a metadata that contains the value %2 and needs one more
redirection to update the reference to %2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36103] New: LLVM overwrites spilled xmm registers in crash handler

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36103

Bug ID: 36103
   Summary: LLVM overwrites spilled xmm registers in crash handler
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: smee...@fb.com
CC: compn...@compnerd.org, david.majne...@gmail.com,
llvm-bugs@lists.llvm.org, r...@google.com

Created attachment 19754
  --> https://bugs.llvm.org/attachment.cgi?id=19754=edit
Reduced test case

See dbl3.ll (in the attached zip). If I assemble this with

% opt -mem2reg -mtriple x86_64-windows-msvc -S -o - dbl3.ll | \
llc -filetype=asm -o - -

the function prologue has

"?z@@YANXZ":# @"\01?z@@YANXZ"
.Lfunc_begin0:
.seh_proc "?z@@YANXZ"
.seh_handler __CxxFrameHandler3, @unwind, @except
# %bb.0:# %entry
pushq   %rbp
.seh_pushreg 5
subq$64, %rsp
.seh_stackalloc 64
leaq64(%rsp), %rbp
.seh_setframe 5, 64
movaps  %xmm6, -16(%rbp)# 16-byte Spill
.seh_savexmm 6, 48
.seh_endprologue

and the catch handler prologue has

"?catch$4@?0??z@@YANXZ@4HA":
.seh_proc "?catch$4@?0??z@@YANXZ@4HA"
.seh_handler __CxxFrameHandler3, @unwind, @except
.LBB0_4:# %catch
movq%rdx, 16(%rsp)
pushq   %rbp
.seh_pushreg 5
subq$32, %rsp
.seh_stackalloc 32
leaq64(%rdx), %rbp
movapd  %xmm6, -16(%rbp)# 16-byte Spill
.seh_savexmm 6, 48
.seh_endprologue

Note that the catch handler saves xmm6 to the stack to the exact same slot the
function prologue saved it to. In other words, when the catch handler is
entered, the *current* value of xmm6, which has already been overwritten inside
the function, is saved to the stack, overwriting the original value that was
saved in the function prologue. The function epilogue will therefore restore an
incorrect value to xmm6.

dbl.cpp, dbl2.cpp, and dbl3.cpp in the attached zip represent a complete
example demonstrating the problem. If you run

% clang-cl /O1 /EHsc dbl.cpp dbl2.cpp dbl3.cpp

and then execute dbl.exe, the exit code should be 1 rather than 0, because of
xmm6 getting trashed. Compiling with cl and running the compiled program yields
an exit code of 0, as expected.

I've reproduced this with clang 5, clang 6, and trunk, so it seems like it goes
a long way back.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 5704 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,  
mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-01-26

Type: Bug

New issue 5704 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: N1.getValueType() ==  
N2.getValueType() && N1.getValueType() == VT && "Binary ope

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5704

Detailed report: https://oss-fuzz.com/testcase?key=6013747266060288

Project: llvm
Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-gisel
Fuzz target binary: llvm-isel-fuzzer--aarch64-gisel
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: ASSERT
Crash Address:
Crash State:
  N1.getValueType() == N2.getValueType() && N1.getValueType() == VT  
&& "Binary ope

  llvm::SelectionDAG::getNode
  llvm::SelectionDAGBuilder::visitBinary

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201801240651:201801250632


Reproducer Testcase:  
https://oss-fuzz.com/download?testcase_id=6013747266060288


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any  
stable releases.

  * add any other useful information.
This information can help downstream consumers.

If you have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36099] Input stream formatted input for `float` produces incorrect result for non-hexadecimal-prefixed input containing hexadecimal characters without an exponent

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36099

Marshall Clow (home)  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Marshall Clow (home)  ---


*** This bug has been marked as a duplicate of bug 17782 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36102] New: RewriteStatepointsForGC probably shouldn't turn musttail calls into statepoints

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36102

Bug ID: 36102
   Summary: RewriteStatepointsForGC probably shouldn't turn
musttail calls into statepoints
   Product: libraries
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: ben...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19753
  --> https://bugs.llvm.org/attachment.cgi?id=19753=edit
A minimal example of input that the pass mangles

Applying the RewriteStatepointsForGC pass to a function definition that
contains a `musttail` call turns that call into a statepoint, which produces a
malformed module (since the parameter counts mismatch). The attached file is a
valid module, but running `opt -rewrite-statepoints-for-gc -S
tail_statepoint.ll` produces the following error message:

cannot guarantee tail call due to mismatched parameter counts
  %statepoint_token = musttail call token (i64, i32, i32 (i32
addrspace(1)*)*, i32, i32, ...)
@llvm.experimental.gc.statepoint.p0f_i32p1i32f(i64 288240, i32 0, i32 (i32
addrspace(1)*)* @foo, i32 1, i32 0, i32 addrspace(1)* %x, i32 0, i32 0, i32
addrspace(1)* %x)
LLVM ERROR: Broken function found, compilation aborted!

As far as I can tell, the decision on whether to rewrite a given callsite is
made here:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp#L2522

It seems to me that just adding a clause to verify that the call is not
`musttail` would be an improvement, but I'm not at all familiar with what other
repercussions it could possibly have.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36101] New: LLD COFF produces bad diagnostics for undefined /include symbol

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36101

Bug ID: 36101
   Summary: LLD COFF produces bad diagnostics for undefined
/include symbol
   Product: lld
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: COFF
  Assignee: unassignedb...@nondot.org
  Reporter: smee...@fb.com
CC: compn...@compnerd.org, llvm-bugs@lists.llvm.org,
pe...@pcc.me.uk, r...@google.com, r...@google.com,
ztur...@google.com

% cat using.c
int main() { return 0; }
#pragma comment(linker, "/include:undefined")

% clang -target x86_64-windows-msvc -c using.c
$ lld-link -entry:main using.o
lld-link: error: : undefined symbol: undefined

Undefined symbols from /include directives in object files are reported as
originating from the GC root, which is confusing and makes the user have to
manually hunt for the errant object file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36100] New: Abort trap in 'PowerPC DAG->DAG Pattern Instruction Selection'

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36100

Bug ID: 36100
   Summary: Abort trap in 'PowerPC DAG->DAG Pattern Instruction
Selection'
   Product: clang
   Version: 5.0
  Hardware: Other
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: s...@sven-siemsen.de
CC: llvm-bugs@lists.llvm.org

Created attachment 19752
  --> https://bugs.llvm.org/attachment.cgi?id=19752=edit
Preprocessed source and associated run script

I am trying to build FreeBSD-11.1 on powerpc64 with clang-5.0.1 from ports.
When building openssh, clang crashes

--- progressmeter.o ---
clang-5.0: error: unable to execute command: Abort trap (core dumped)
clang-5.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 5.0.1 (tags/RELEASE_501/final)
Target: powerpc-portbld-freebsd11.1
Thread model: posix
InstalledDir: /usr/local/llvm50/bin
clang-5.0: 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-5.0: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-5.0: note: diagnostic msg: /tmp/progressmeter-2c5082.c
clang-5.0: note: diagnostic msg: /tmp/progressmeter-2c5082.sh


Output of progressmeter-2c5082.sh:

Assertion failed: (NewLHS.getValueType() == N->getValueType(0) && "Unexpected
setcc expansion!"), function ExpandIntOp_SETCC, file
/usr/ports/devel/llvm50/work/llvm-5.0.1.src/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp,
line 3117.
Stack dump:
0.  Program arguments: /usr/local/llvm50/bin/clang-5.0 -cc1 -triple
powerpc-portbld-freebsd11.1 -emit-obj -disable-free -main-file-name
progressmeter.c -mrelocation-model static -mthread-model posix
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu 970
-mfloat-abi hard -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file
/usr/obj/usr/src/world32/usr/src/secure/lib/libssh/progressmeter.gcno
-sys-header-deps -D COMPAT_32BIT -D HAVE_LDNS=1 -O2 -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Wno-parentheses -std=gnu99 -ferror-limit 19
-fmessage-length 0 -stack-protector 2 -fno-signed-char -fobjc-runtime=gnustep
-fdiagnostics-show-option -vectorize-loops -vectorize-slp -x c
progressmeter-2c5082.c
1.   parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module
'progressmeter-2c5082.c'.
4.  Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on
function '@Fssh_refresh_progress_meter'
Abort trap (core dumped)

I tried with clang 7.0.0 from devel/clang-devel, same result.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 5688 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: llvm::all_of(Mask, [&](int M) { return M < (NElts * 2) && M >= -1; }) && "Index

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,  
mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-01-25

Type: Bug

New issue 5688 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2:  
ASSERT: llvm::all_of(Mask, [&](int M) { return M < (NElts * 2) && M >= -1;  
}) && "Index

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5688

Detailed report: https://oss-fuzz.com/testcase?key=5066873944145920

Project: llvm
Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2
Fuzz target binary: llvm-isel-fuzzer--x86_64-O2
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: ASSERT
Crash Address:
Crash State:
  llvm::all_of(Mask, [&](int M) { return M < (NElts * 2) && M >= -1; })  
&& "Index

  llvm::SelectionDAG::getVectorShuffle
  DAGCombiner::visitBUILD_VECTOR

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201710190451:201710200650


Reproducer Testcase:  
https://oss-fuzz.com/download?testcase_id=5066873944145920


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any  
stable releases.

  * add any other useful information.
This information can help downstream consumers.

If you have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36099] New: Input stream formatted input for `float` produces incorrect result for non-hexadecimal-prefixed input containing hexadecimal characters without an exponent

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36099

Bug ID: 36099
   Summary: Input stream formatted input for `float` produces
incorrect result for non-hexadecimal-prefixed input
containing hexadecimal characters without an exponent
   Product: libc++
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: brycelelb...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com

=
Test Case
=

#include 
#include 

int main() {
std::istringstream s("1.000f32");

float f;
s >> f;

std::cout << f << std::endl;
}

==
Steps to Reproduce
==

https://wandbox.org/permlink/3d9Z9Fr6vqzcx29w

===
Observed Output
===

0

===
Expected Output
===

1

This appears to be a bug in libc++'s hexadecimal `float` formatted input.

libc++'s formatted stream input implementation for `float` calls `num_get`
(ISO/IEC 14882 [istream.formatted.arithmetic]).

In the case of `float`, `num_get` accumulates valid characters until it
encounters an invalid character (stage 1), and then does the equivalent of
calling the C library function `strtof` on the accumulated string (ISO/IEC
14882 [facet.num.get.virtuals] (3.3.3) "Stage 2"). My guess is that in this
case,
libc++ considers the characters `[a-z]` (hexadecimal digits) to be valid in
addition to `[0-9+-eE]` in stage 1, but in stage 2 (the equivalent-to-`strtof`
stage), the string "1.000f32" is rejected because it doesn't have the
hexadecimal prefix (e.g. it's not "0x1.000f32").

Feeding the entire string directly into `strtof` consumes "1.000" and returns
1:

https://wandbox.org/permlink/BRWaxfmoTNewQMTo

If you change the input string to contain a character that is not a hexadecimal
digit (e.g. "1.000g32"), libc++ returns 1:

https://wandbox.org/permlink/BRWaxfmoTNewQMTo

libc++ should only accept hexadecimal digits in floats when the hexadecimal
prefix is present. Otherwise, there are ambiguities. Consider "1.000e32" - is
it a hexadecimal `float`, or a `float` with an exponent.

libstdc++ and MSVC print 1 for the test case:

libstdc++: https://wandbox.org/permlink/4EF17CZxau2CrYTA
MSVC: http://rextester.com/STNGQX93481

===
Environment
===

Platform: Godbolt (Linux Docker)
Clang/LLVM Version: Top of trunk as of 01/25/2018

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36098] New: llvm-ar/lib checks incorrectly "lib" stem

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36098

Bug ID: 36098
   Summary: llvm-ar/lib checks incorrectly "lib" stem
   Product: tools
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: llvm-ar
  Assignee: unassignedb...@nondot.org
  Reporter: ignacio.slipk...@gmail.com
CC: llvm-bugs@lists.llvm.org

Visual Studio 2015 runs lib as "Lib" so the case-sensitive comparison fails.
Not sure if it affects everyone.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 27784] llc emits AT when using -O0 --x86-asm-syntax=intel

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=27784

Craig Topper  changed:

   What|Removed |Added

 CC||craig.top...@gmail.com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Craig Topper  ---
I believe this was fixed in r314140. We now print "movabs»·rdi, offset
.LLt_0004"  The 'offset' makes the GNU assembler happy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36097] New: Merge r323469 into 6.0: Teach Intel syntax InstPrinter to print lock prefixes that have been parsed from the asm parser.

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36097

Bug ID: 36097
   Summary: Merge r323469 into 6.0: Teach Intel syntax InstPrinter
to print lock prefixes that have been parsed from the
asm parser.
   Product: libraries
   Version: 6.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org

This is another issue introduced by https://reviews.llvm.org/rL315899

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36096] New: Regression: Invalid *.lib produced on MSVC upgrading from 4.0.1

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36096

Bug ID: 36096
   Summary: Regression: Invalid *.lib produced on MSVC upgrading
from 4.0.1
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Object
  Assignee: unassignedb...@nondot.org
  Reporter: a...@crichton.co
CC: llvm-bugs@lists.llvm.org, martellmal...@gmail.com,
r...@google.com

Created attachment 19750
  --> https://bugs.llvm.org/attachment.cgi?id=19750=edit
Object to insert in archive

Over at rust-lang/rust we've been a little slow to the uptick of landing LLVM
changes, but we're getting around now to upgrading from LLVM 4.0.1 to 6.0.0.
Unfortunately though we're seeing what I think is a regression in behavior of
the `llvm-ar.exe` tool on Windows MSVC.

I've run a bisection and it pointed at https://reviews.llvm.org/D29892 so I'm
cc'ing those there to hope that y'all can help out with this issue!
Unfortunately I don't have a small reproduction to gist here but I can
certainly work to make it smaller if need be!

The rust compiler isn't necessarily standard about how it uses LLVM, for
example we don't literally use `llvm-ar.exe` but rather call `writeArchive`
directly. I believe that the various invocations are the same, however, in
terms of reproduction at the command line. 

In any case, the bug that I'm seeing happens when we do something like:

* First we compile a C++ library to an archive using its own build system
(CMake). That project is https://github.com/WebAssembly/binaryen. 
* Next, the Rust compiler opens up this archive using the `Archive` class in
LLVM and iterates over it with `Archive::child_iterator`.
* We then create a new archive with `writeArchive` where some members are
freshly generated object files (aka the Rust code) and the remaining members
are those from the previous `Archive` opened earlier. We're using
`NewArchiveMember::getOldMember` to insert these preexisting members into the
new archive.
* Later this archive that was generated is then passed to `link.exe`, MSVC's
linker
* The bug happens here where MSVC's linker spits out a message "library is
corrupt" (with no other information).

Using LLVM 4.0.1 `link.exe` doesn't spit out this error message, but using LLVM
6.0.0 `link.exe` spits out the error message. 

While I haven't managed to create a tiny test case I have managed to reduce
this somewhat. Specifically I've been taking the object file attached to this
bug and executing:

llvm-ar.exe crus libfoo.a archive.obj

When the resulting archive is fed to `link.exe` on LLVM 4.0.1 then `link.exe`
spits out a ton of undefined symbol errors (as the archive is missing all the
other objects). On LLVM 6.0.0, however, `link.exe` simply spits out "library is
corrupt". Unfortunately a direct invocation of `link.exe` isn't working, I've
been using it with all the other libraries and files on the originally failing
`link.exe` command. I'm not too familiar with `link.exe`, though, so y'all may
know how to create a more directly failing test case!

Upon running a bisection it ended up pointing at
https://github.com/llvm-mirror/llvm/commit/5d7d0e869f7abea7d1022e4b65a75a97dc2e54a6.
This commit was reverted a few hours later but a slight tweak was relanded and
I believe it's stayed since. The "suspicious" line for archive writing was the
change to `ArchiveWriter.cpp` where `SF_Indirect` symbols were changed to be
included in the archive.

I've tested out LLVM 6.0.0 with just the change to `ArchiveWriter.cpp` reverted
from that patch (aka remove the branch that checks `SF_Indirect`). That seems
to at least restore the old behavior and produces a working archive which isn't
considered corrupt by `link.exe`.

Ok so that's all the information that I currently have at this time, but I
realize it's not a great amount of information as it can't be trivially
reproduced yet! I'm hoping though that y'all cc'd here can help me out and
either recognize what's going on here or suggest a way to help minimize.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 35963] [AMDGPU][MC] Incorrect parsing of image modifiers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35963

Dmitry  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #1 from Dmitry  ---
closed by commit 322942:

http://llvm.org/viewvc/llvm-project?rev=322942=rev

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 35962] [AMDGPU][MC] Incorrect encoding of VDATA for image atomics

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35962

Dmitry  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #1 from Dmitry  ---
closed by commit 322942:

http://llvm.org/viewvc/llvm-project?rev=322942=rev

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 33629] [mc][gfx9] Missing support for 16-bit renamed/legacy VALU opcodes

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33629

Dmitry  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Dmitry  ---
Resolved by commits 318955, 310497

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36095] New: [AMDGPU][MC][GFX8][GFX9] d16 modifier of image instructions should be enabled for GFX8/9 only

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36095

Bug ID: 36095
   Summary: [AMDGPU][MC][GFX8][GFX9] d16 modifier of image
instructions should be enabled for GFX8/9 only
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: AMDGPU
  Assignee: unassignedb...@nondot.org
  Reporter: dpreobrazhen...@luxoft.com
CC: llvm-bugs@lists.llvm.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36094] New: [AMDGPU][MC][GFX9] r128 modifier of image instructions should be disabled for GFX9

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36094

Bug ID: 36094
   Summary: [AMDGPU][MC][GFX9] r128 modifier of image instructions
should be disabled for GFX9
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: AMDGPU
  Assignee: unassignedb...@nondot.org
  Reporter: dpreobrazhen...@luxoft.com
CC: llvm-bugs@lists.llvm.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 14493] [Hexagon] Factor out common functionality from the predicate definitions in HexagonOperands.td

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=14493

Krzysztof Parzyszek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Krzysztof Parzyszek  ---
A lot of the .td definitions are now auto-generated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36093] New: [AMDGPU][MC][GFX7][GFX8] Image instructions failed to assemble with r128 modifier

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36093

Bug ID: 36093
   Summary: [AMDGPU][MC][GFX7][GFX8] Image instructions failed to
assemble with r128 modifier
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: AMDGPU
  Assignee: unassignedb...@nondot.org
  Reporter: dpreobrazhen...@luxoft.com
CC: llvm-bugs@lists.llvm.org

Examples of failed tests:

  image_load v5, v[1:4], s[8:15] r128

The test fails because r128 modifier is not recognized.

Also note that this modifier should affect SRSRC size, but assembler currently
does not support 128-bit SRSRC. When it will, the correct test would be:

  image_load v5, v[1:4], s[8:11] r128

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36092] New: [AMDGPU][MC][GFX8][GFX9] Image instructions failed to assemble with d16 modifier

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36092

Bug ID: 36092
   Summary: [AMDGPU][MC][GFX8][GFX9] Image instructions failed to
assemble with d16 modifier
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: AMDGPU
  Assignee: unassignedb...@nondot.org
  Reporter: dpreobrazhen...@luxoft.com
CC: llvm-bugs@lists.llvm.org

An example of a failed test:

  image_load v5, v[1:4], s[8:15] d16

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36083] Crash when multiple ATs map to the same AT>

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36083

Rafael Ávila de Espíndola  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Rafael Ávila de Espíndola  ---
r323449.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36091] New: [X86][SSE] Failure to vectorize load+extend v8i8 to v8i16

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36091

Bug ID: 36091
   Summary: [X86][SSE] Failure to vectorize load+extend v8i8 to
v8i16
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
nir...@google.com, spatel+l...@rotateright.com

#include 
#include 

__m128i loadext_i8(int8_t *data) {
return _mm_set_epi16(data[7], data[6], data[5], data[4], data[3], data[2],
data[1], data[0]);
}
__m128i loadext_u8(uint8_t *data) {
return _mm_set_epi16(data[7], data[6], data[5], data[4], data[3], data[2],
data[1], data[0]);
}

clang -O3 -march=btver2

define <2 x i64> @loadext_i8(i8* nocapture readonly) {
  %2 = getelementptr inbounds i8, i8* %0, i64 7
  %3 = load i8, i8* %2, align 1, !tbaa !2
  %4 = sext i8 %3 to i16
  %5 = getelementptr inbounds i8, i8* %0, i64 6
  %6 = load i8, i8* %5, align 1, !tbaa !2
  %7 = sext i8 %6 to i16
  %8 = getelementptr inbounds i8, i8* %0, i64 5
  %9 = load i8, i8* %8, align 1, !tbaa !2
  %10 = sext i8 %9 to i16
  %11 = getelementptr inbounds i8, i8* %0, i64 4
  %12 = load i8, i8* %11, align 1, !tbaa !2
  %13 = sext i8 %12 to i16
  %14 = getelementptr inbounds i8, i8* %0, i64 3
  %15 = load i8, i8* %14, align 1, !tbaa !2
  %16 = sext i8 %15 to i16
  %17 = getelementptr inbounds i8, i8* %0, i64 2
  %18 = load i8, i8* %17, align 1, !tbaa !2
  %19 = sext i8 %18 to i16
  %20 = getelementptr inbounds i8, i8* %0, i64 1
  %21 = load i8, i8* %20, align 1, !tbaa !2
  %22 = sext i8 %21 to i16
  %23 = load i8, i8* %0, align 1, !tbaa !2
  %24 = sext i8 %23 to i16
  %25 = insertelement <8 x i16> undef, i16 %24, i32 0
  %26 = insertelement <8 x i16> %25, i16 %22, i32 1
  %27 = insertelement <8 x i16> %26, i16 %19, i32 2
  %28 = insertelement <8 x i16> %27, i16 %16, i32 3
  %29 = insertelement <8 x i16> %28, i16 %13, i32 4
  %30 = insertelement <8 x i16> %29, i16 %10, i32 5
  %31 = insertelement <8 x i16> %30, i16 %7, i32 6
  %32 = insertelement <8 x i16> %31, i16 %4, i32 7
  %33 = bitcast <8 x i16> %32 to <2 x i64>
  ret <2 x i64> %33
}

define <2 x i64> @loadext_u8(i8* nocapture readonly) {
  %2 = getelementptr inbounds i8, i8* %0, i64 7
  %3 = load i8, i8* %2, align 1, !tbaa !2
  %4 = zext i8 %3 to i16
  %5 = getelementptr inbounds i8, i8* %0, i64 6
  %6 = load i8, i8* %5, align 1, !tbaa !2
  %7 = zext i8 %6 to i16
  %8 = getelementptr inbounds i8, i8* %0, i64 5
  %9 = load i8, i8* %8, align 1, !tbaa !2
  %10 = zext i8 %9 to i16
  %11 = getelementptr inbounds i8, i8* %0, i64 4
  %12 = load i8, i8* %11, align 1, !tbaa !2
  %13 = zext i8 %12 to i16
  %14 = getelementptr inbounds i8, i8* %0, i64 3
  %15 = load i8, i8* %14, align 1, !tbaa !2
  %16 = zext i8 %15 to i16
  %17 = getelementptr inbounds i8, i8* %0, i64 2
  %18 = load i8, i8* %17, align 1, !tbaa !2
  %19 = zext i8 %18 to i16
  %20 = getelementptr inbounds i8, i8* %0, i64 1
  %21 = load i8, i8* %20, align 1, !tbaa !2
  %22 = zext i8 %21 to i16
  %23 = load i8, i8* %0, align 1, !tbaa !2
  %24 = zext i8 %23 to i16
  %25 = insertelement <8 x i16> undef, i16 %24, i32 0
  %26 = insertelement <8 x i16> %25, i16 %22, i32 1
  %27 = insertelement <8 x i16> %26, i16 %19, i32 2
  %28 = insertelement <8 x i16> %27, i16 %16, i32 3
  %29 = insertelement <8 x i16> %28, i16 %13, i32 4
  %30 = insertelement <8 x i16> %29, i16 %10, i32 5
  %31 = insertelement <8 x i16> %30, i16 %7, i32 6
  %32 = insertelement <8 x i16> %31, i16 %4, i32 7
  %33 = bitcast <8 x i16> %32 to <2 x i64>
  ret <2 x i64> %33
}

loadext_i8:
  movsbl (%rdi), %ecx
  movsbl 1(%rdi), %eax
  movsbl 2(%rdi), %edx
  vmovd %ecx, %xmm0
  movsbl 3(%rdi), %ecx
  vpinsrw $1, %eax, %xmm0, %xmm0
  vpinsrw $2, %edx, %xmm0, %xmm0
  movsbl 4(%rdi), %edx
  vpinsrw $3, %ecx, %xmm0, %xmm0
  movsbl 5(%rdi), %ecx
  vpinsrw $4, %edx, %xmm0, %xmm0
  movsbl 6(%rdi), %edx
  vpinsrw $5, %ecx, %xmm0, %xmm0
  movsbl 7(%rdi), %ecx
  vpinsrw $6, %edx, %xmm0, %xmm0
  vpinsrw $7, %ecx, %xmm0, %xmm0
  retq

loadext_u8:
  movzbl (%rdi), %ecx
  movzbl 1(%rdi), %eax
  movzbl 2(%rdi), %edx
  vmovd %ecx, %xmm0
  movzbl 3(%rdi), %ecx
  vpinsrw $1, %eax, %xmm0, %xmm0
  vpinsrw $2, %edx, %xmm0, %xmm0
  movzbl 4(%rdi), %edx
  vpinsrw $3, %ecx, %xmm0, %xmm0
  movzbl 5(%rdi), %ecx
  vpinsrw $4, %edx, %xmm0, %xmm0
  movzbl 6(%rdi), %edx
  vpinsrw $5, %ecx, %xmm0, %xmm0
  movzbl 7(%rdi), %ecx
  vpinsrw $6, %edx, %xmm0, %xmm0
  vpinsrw $7, %ecx, %xmm0, %xmm0
  retq

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36090] New: [X86

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36090

Bug ID: 36090
   Summary: [X86
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36089] New: [ThinLTO] asserts `!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"` failed

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36089

Bug ID: 36089
   Summary: [ThinLTO] asserts `!(Pair.first != Ty && Pair.second
== Ty) && "mapping to a source type"` failed
   Product: libraries
   Version: 6.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Linker
  Assignee: unassignedb...@nondot.org
  Reporter: russell_gal...@sn.scee.net
CC: llvm-bugs@lists.llvm.org

This seems related to PR37522 but wasn't fixed by r322103.

At r323433:
$ clang --version
clang version 7.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
...

$ cat a.cpp
void foo() {}
$ cat b.cpp
struct B;
struct C {
  C(B &);
};
struct A () {}
C::C(B &) {}
$ cat c.cpp
struct A ();
template  struct D {};
struct B {
  B(A &);
  D<> m_list;
};
struct C {
  C(B &);
};
void bar() {
  B b(foo());
  C c(b);
}
$ clang -c -O1 -g -flto=thin a.cpp
$ clang -c -O1 -g -flto=thin b.cpp
b.cpp:5:18: warning: control reaches end of non-void function [-Wreturn-type]
struct A () {}
 ^
1 warning generated.
$ clang -c -O1 -g -flto=thin c.cpp
$ llvm-lto -thinlto-action=run a.o b.o c.o
llvm-lto: /home/user/git/llvm/lib/Linker/IRMover.cpp:248: llvm::Type*
{anonymous}::TypeMapTy::get(llvm::Type*, llvm::SmallPtrSet&): Assertion
`!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"'
failed.
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36088] New: ExprWithCleanups not handled in emitOpenCLEnqueuedBlock

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36088

Bug ID: 36088
   Summary: ExprWithCleanups not handled in
emitOpenCLEnqueuedBlock
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: OpenCL
  Assignee: unassignedclangb...@nondot.org
  Reporter: l...@zaghen.it
CC: llvm-bugs@lists.llvm.org

Created attachment 19749
  --> https://bugs.llvm.org/attachment.cgi?id=19749=edit
The CL kernel

The attached source makes clang (6.0-rc1 and trunk) assert on
cast().
I tried ignoring the ExprWithCleanups:

   if (auto DR = dyn_cast(E)) {
 E = cast(DR->getDecl())->getInit();
   }
+  if (auto Cast = dyn_cast(E)) {
+E = Cast->getSubExpr();
+  }
   if (auto Cast = dyn_cast(E)) {
 E = Cast->getSubExpr();
   }
   auto *Block = cast(E);

but it seems like clang also tries to emit the same block expression twice (the
second time through the OCL enqueue specific codepath.)

Options I used for clang: "-x cl -cl-std=CL2.0 enqueue_block_kernel.cl"

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36018] [GlobalISel][AArch64] Two load instructions generated for single volatile load

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36018

Hans Wennborg  changed:

   What|Removed |Added

 CC||h...@chromium.org
 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #9 from Hans Wennborg  ---
(In reply to Eli Friedman from comment #8)
> Needs to be cherry-picked to 6.0.

Merged in r323434

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35804
Bug 35804 depends on bug 36018, which changed state.

Bug 36018 Summary: [GlobalISel][AArch64] Two load instructions generated for 
single volatile load
https://bugs.llvm.org/show_bug.cgi?id=36018

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36087] New: Unable to execute command: Segmentation fault

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36087

Bug ID: 36087
   Summary: Unable to execute command: Segmentation fault
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: wellingtonuem...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19748
  --> https://bugs.llvm.org/attachment.cgi?id=19748=edit
Clang diagnostic msg

clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 5.0.0-3 (tags/RELEASE_500/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: 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: note: diagnostic msg: 


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/wico-7049ee.cpp
clang: note: diagnostic msg: /tmp/wico-7049ee.sh
clang: note: diagnostic msg:

Compiling src/mame/drivers/next.cpp...
#0 0x7fac0a52adfa llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/llvm-5.0/bin/../lib/libLLVM-5.0.so.1+0x7aadfa)
#1 0x7fac0a529016 llvm::sys::RunSignalHandlers()
(/usr/lib/llvm-5.0/bin/../lib/libLLVM-5.0.so.1+0x7a9016)
#2 0x7fac0a52914b (/usr/lib/llvm-5.0/bin/../lib/libLLVM-5.0.so.1+0x7a914b)
#3 0x7fac0d39b150 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x13150)
#4 0x557f13af96de clang::ParmVarDecl::getDefaultArg()
(/usr/lib/llvm-5.0/bin/clang+0x17a16de)
#5 0x557f135a774b clang::Sema::SubstParmVarDecl(clang::ParmVarDecl*,
clang::MultiLevelTemplateArgumentList const&, int, llvm::Optional, bool) (/usr/lib/llvm-5.0/bin/clang+0x124f74b)
#6 0x557f135a8863 (/usr/lib/llvm-5.0/bin/clang+0x1250863)
#7 0x557f135a9e3a (/usr/lib/llvm-5.0/bin/clang+0x1251e3a)
#8 0x557f135aaeba (/usr/lib/llvm-5.0/bin/clang+0x1252eba)
#9 0x557f135ad85b (/usr/lib/llvm-5.0/bin/clang+0x125585b)
#10 0x557f135b1b1b (/usr/lib/llvm-5.0/bin/clang+0x1259b1b)
#11 0x557f135b5280 (/usr/lib/llvm-5.0/bin/clang+0x125d280)
#12 0x557f135b1004 (/usr/lib/llvm-5.0/bin/clang+0x1259004)
#13 0x557f135b176e (/usr/lib/llvm-5.0/bin/clang+0x125976e)
#14 0x557f135b5e4f (/usr/lib/llvm-5.0/bin/clang+0x125de4f)
#15 0x557f135aaa78 (/usr/lib/llvm-5.0/bin/clang+0x1252a78)
#16 0x557f135ad85b (/usr/lib/llvm-5.0/bin/clang+0x125585b)
#17 0x557f135b624f clang::Sema::SubstType(clang::TypeSourceInfo*,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName, bool) (/usr/lib/llvm-5.0/bin/clang+0x125e24f)
#18 0x557f1350b07f (/usr/lib/llvm-5.0/bin/clang+0x11b307f)
#19 0x557f1351f6d6
clang::Sema::CheckTemplateArgumentList(clang::TemplateDecl*,
clang::SourceLocation, clang::TemplateArgumentListInfo&, bool,
llvm::SmallVectorImpl&, bool)
(/usr/lib/llvm-5.0/bin/clang+0x11c76d6)
#20 0x557f1351fe8a clang::Sema::CheckTemplateIdType(clang::TemplateName,
clang::SourceLocation, clang::TemplateArgumentListInfo&)
(/usr/lib/llvm-5.0/bin/clang+0x11c7e8a)
#21 0x557f135b5776 (/usr/lib/llvm-5.0/bin/clang+0x125d776)
#22 0x557f135abbd4 (/usr/lib/llvm-5.0/bin/clang+0x1253bd4)
#23 0x557f135ad85b (/usr/lib/llvm-5.0/bin/clang+0x125585b)
#24 0x557f135b1b1b (/usr/lib/llvm-5.0/bin/clang+0x1259b1b)
#25 0x557f135b5280 (/usr/lib/llvm-5.0/bin/clang+0x125d280)
#26 0x557f135abbd4 (/usr/lib/llvm-5.0/bin/clang+0x1253bd4)
#27 0x557f135c1cf1
clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName, clang::CXXRecordDecl*, unsigned int)
(/usr/lib/llvm-5.0/bin/clang+0x1269cf1)
#28 0x557f135c4d22 clang::TemplateDeclInstantiator::VisitDecl(clang::Decl*)
(/usr/lib/llvm-5.0/bin/clang+0x126cd22)
#29 0x557f135d66d0
clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*,
clang::TemplateParameterList*, bool) (/usr/lib/llvm-5.0/bin/clang+0x127e6d0)
#30 0x557f135d3d2e clang::Sema::SubstDecl(clang::Decl*,
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&)
(/usr/lib/llvm-5.0/bin/clang+0x127bd2e)
#31 0x557f1358da3f
clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*,
llvm::SmallVectorImpl&, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&,
llvm::SmallVectorImpl const*, bool,
llvm::function_ref) (/usr/lib/llvm-5.0/bin/clang+0x1235a3f)
#32 0x557f135926be
clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*,
clang::TemplateArgumentListInfo*, llvm::ArrayRef,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, 

[llvm-bugs] [Bug 36086] New: llvm-cov: Uncovered region when evaluated at compile-time

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36086

Bug ID: 36086
   Summary: llvm-cov: Uncovered region when evaluated at
compile-time
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: dennis.fels...@sap.com
CC: llvm-bugs@lists.llvm.org

Code regions that can be evaluated at compile-time are shown as uncovered by
llvm-cov, for example:

if (true && true) { // second true is uncovered
  return 0;
}

if (argc > 1 && strcmp("&&", "&&) == 0) { // strcmp is uncovered
  return 0;
}

if (argc > 1 && (strcmp)("&&", "&&) == 0) { // strcmp is covered here because
it is done at runtime
  return 0;
}

if (argc > 1 && strcmp(argv[1], "&&) == 0) { // strcmp is covered here because
it is done at runtime
  return 0;
}

Instead I would expect all of the if line to be covered.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 36085] New: Debug fragment offsets are emitted in the wrong order for symbol locations

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36085

Bug ID: 36085
   Summary: Debug fragment offsets are emitted in the wrong order
for symbol locations
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: david.stenb...@ericsson.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19747
  --> https://bugs.llvm.org/attachment.cgi?id=19747=edit
llc input

LLVM commit used: r323411.

When compiling foo.c:

  struct {
long foo;
void *bar;
long baz;
void *qux;
  } static var = { .bar = (void *)0x1234, .qux = (void *)0x5678 };

  void *ptr;

  int main() {
if (var.foo == 0)
  var.bar = var.qux = ptr;
return 0;
  }

using:

  clang -march=x86-64 -O0 -g2 -S -emit-llvm foo.c -o foo.ll
  opt -S -globalopt foo.ll -o foo.opt.ll
  llc -O0 foo.opt.ll -filetype=obj -o foo.obj 

the following debug info is emitted for the SRA'd struct variable, in which
the first and third fields have been optimized out:

   <1><40>: Abbrev Number: 4 (DW_TAG_variable)
  <41>   DW_AT_name: (indirect string, offset: 0x10f): var
  <45>   DW_AT_type: <0x66>
  <49>   DW_AT_decl_file   : 1
  <4a>   DW_AT_decl_line   : 6
  <4b>   DW_AT_location: 26 byte block: 3 0 0 0 0 0 0 0 0 93 8 93 8 3 8
0 0 0 0 0 0 0 93 8 93 8   (DW_OP_addr: 0; DW_OP_piece: 8; DW_OP_piece: 8;
DW_OP_addr: 8; DW_OP_piece: 8; DW_OP_piece: 8)

As seen, the DW_OP_addr operations for the second and fourth field are emitted
before the pieces used as offsets for the optimized-out first and third
variable, leading the operations to be associated with wrong parts of the
variable.

This can be further seen by printing the variable in gdb:

echo "print /x var" | gdb a.out  | grep '\$1'  
(gdb) $1 = {foo = 0x1234, bar = , baz = 0x5678, qux = }

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 5683 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-earlycse: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-earlycse

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,  
mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm  
Reported-2018-01-25

Type: Bug

New issue 5683 by ClusterFuzz-External:  
llvm/llvm-opt-fuzzer--x86_64-earlycse: Out-of-memory in  
llvm_llvm-opt-fuzzer--x86_64-earlycse

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5683

Detailed report: https://oss-fuzz.com/testcase?key=5089029801377792

Project: llvm
Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-earlycse
Fuzz target binary: llvm-opt-fuzzer--x86_64-earlycse
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Out-of-memory (exceeds 2048 MB)
Crash Address:
Crash State:
  llvm_llvm-opt-fuzzer--x86_64-earlycse

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201801240651:201801250632


Reproducer Testcase:  
https://oss-fuzz.com/download?testcase_id=5089029801377792


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any  
stable releases.

  * add any other useful information.
This information can help downstream consumers.

If you have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 5265 in oss-fuzz: llvm/clang-proto-fuzzer: Stack-overflow in matchSelectPattern

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #4 on issue 5265 by ClusterFuzz-External: llvm/clang-proto-fuzzer:  
Stack-overflow in matchSelectPattern

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5265#c4

ClusterFuzz testcase 5259730642534400 is verified as fixed, so closing  
issue as verified.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 5265 in oss-fuzz: llvm/clang-proto-fuzzer: Stack-overflow in matchSelectPattern

[ClusterFuzz-External via monorail via llvm-bugs]

Comment #3 on issue 5265 by ClusterFuzz-External: llvm/clang-proto-fuzzer:  
Stack-overflow in matchSelectPattern

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5265#c3

ClusterFuzz has detected this issue as fixed in range  
201801240651:201801250632.


Detailed report: https://oss-fuzz.com/testcase?key=5259730642534400

Project: llvm
Fuzzer: libFuzzer_llvm_clang-proto-fuzzer
Fuzz target binary: clang-proto-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffc71245de0
Crash State:
  matchSelectPattern
  llvm::matchSelectPattern
  matchMinMaxOfMinMax

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201801020611:201801030610
Fixed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201801240651:201801250632


Reproducer Testcase:  
https://oss-fuzz.com/download?testcase_id=5259730642534400


See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


If you suspect that the result above is incorrect, try re-doing that job on  
the test case report page.


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 5647 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #3 on issue 5647 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT ==  
MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5647#c3

ClusterFuzz testcase 4634333408133120 is verified as fixed, so closing  
issue as verified.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] Issue 5647 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64

[ClusterFuzz-External via monorail via llvm-bugs]

Comment #2 on issue 5647 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT ==  
MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5647#c2

ClusterFuzz has detected this issue as fixed in range  
201801240651:201801250632.


Detailed report: https://oss-fuzz.com/testcase?key=4634333408133120

Project: llvm
Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-gisel
Fuzz target binary: llvm-isel-fuzzer--aarch64-gisel
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: ASSERT
Crash Address:
Crash State:
  (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT ==  
MVT::i64

  AArch64FastISel::emitLSL_ri
  AArch64FastISel::fastSelectInstruction

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201801020611:201801030610
Fixed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201801240651:201801250632


Reproducer Testcase:  
https://oss-fuzz.com/download?testcase_id=4634333408133120


See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


If you suspect that the result above is incorrect, try re-doing that job on  
the test case report page.


--
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs