[llvm-bugs] [Bug 30501] New: AVX512: LLVM generates invalid instructions on Xeon Phi (SIGILL: illegal instruction operand), crashes ensue
https://llvm.org/bugs/show_bug.cgi?id=30501
Bug ID: 30501
Summary: AVX512: LLVM generates invalid instructions on Xeon
Phi (SIGILL: illegal instruction operand), crashes
ensue
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: wenzel.ja...@epfl.ch
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Hi,
LLVM occasionally generates invalid instructions that crash my application
running on Xeon Phi (KNL).
I've been able to reduce one such crash to a minimal example compiled with the
following flags:
$ clang++ -march=knl -stdlib=libc++ -O0 -fno-rtti -fno-exceptions -o test
test.cpp
===
#include
#define ALWAYS_INLINE __attribute__ ((always_inline)) inline
struct KMask {
__mmask8 k;
ALWAYS_INLINE KMask(bool value) : k(__mmask8(value ? -1 : 0)) { }
};
int main(int /* argc */, char * /*argv */ []) {
KMask m(true);
return 0;
}
===
LLDB session illustrating the crash:
(lldb) target create "test"
Current executable set to 'test' (x86_64).
error: Unrecognized command 'rujn'.
(lldb) run
Process 83258 launched: '/home/wjakob/simdarray/test' (x86_64)
Process 83258 stopped
* thread #1: tid = 83258, 0x0040069d test`main + 45, name = 'test',
stop reason = signal SIGILL: illegal instruction operand
frame #0: 0x0040069d test`main + 45
(lldb) d
test`main:
0x400670 <+0>: push rbp
0x400671 <+1>: movrbp, rsp
0x400674 <+4>: xoreax, eax
0x400676 <+6>: movecx, 0x
0x40067b <+11>: leardx, [rbp - 0x28]
0x40067f <+15>: movdword ptr [rbp - 0x10], 0x0
0x400686 <+22>: movdword ptr [rbp - 0x14], edi
0x400689 <+25>: movqword ptr [rbp - 0x20], rsi
===
This is the assembly output I get when compiling with "-S":
.text
.file "test.cpp"
.globl main
.p2align4, 0x90
.type main,@function
main: # @main
.cfi_startproc
# BB#0:
pushq %rbp
.Ltmp0:
.cfi_def_cfa_offset 16
.Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
.Ltmp2:
.cfi_def_cfa_register %rbp
xorl%eax, %eax
movl$4294967295, %ecx # imm = 0x
leaq-40(%rbp), %rdx
movl$0, -16(%rbp)
movl%edi, -20(%rbp)
movq%rsi, -32(%rbp)
movq%rdx, -8(%rbp)
movb$1, -9(%rbp)
movq-8(%rbp), %rdx
movb-9(%rbp), %r8b
kortestw%r8b, %r8b
movl%eax, %edi
cmovnel %ecx, %edi
movb%dil, %r8b
movb%r8b, (%rdx)
popq%rbp
retq
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
.ident "clang version 4.0.0 (trunk 282142)"
.section".note.GNU-stack","",@progbits
===
This is the LLVM IR corresponding to the same code
; ModuleID = 'tests/testsuite.cpp'
source_filename = "tests/testsuite.cpp"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
%struct.KMask = type { i8 }
; Function Attrs: norecurse nounwind uwtable
define i32 @main(i32, i8**) #0 {
%3 = alloca %struct.KMask*, align 8
%4 = alloca i8, align 1
%5 = alloca i32, align 4
%6 = alloca i32, align 4
%7 = alloca i8**, align 8
%8 = alloca %struct.KMask, align 1
store i32 0, i32* %5, align 4
store i32 %0, i32* %6, align 4
store i8** %1, i8*** %7, align 8
store %struct.KMask* %8, %struct.KMask** %3, align 8
store i8 1, i8* %4, align 1
%9 = load %struct.KMask*, %struct.KMask** %3, align 8
%10 = getelementptr inbounds %struct.KMask, %struct.KMask* %9, i32 0, i32 0
%11 = load i8, i8* %4, align 1
%12 = trunc i8 %11 to i1
%13 = select i1 %12, i32 -1, i32 0
%14 = trunc i32 %13 to i8
store i8 %14, i8* %10, align 1
ret i32 0
}
attributes #0 = { norecurse nounwind uwtable
"correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false"
"less-precise-fpmad"="false" "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false"
"no-jump-tables"="false" "no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false" "no-trapping-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="knl"
"target-features"="+adx,+aes,+avx,+avx2,+avx512cd,+avx512er,+avx512f,+avx512pf,+bmi,+bmi2,+cx16,+f16c,+fma,+fsgsbase,+fxsr,+lzcnt,+mmx,+movbe,+pclmul,+popcnt,+prefetchwt1,+rdrnd,+rdseed,+rtm,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt"
"unsafe-fp-math"="false" "use-soft-float"="false" }
!llvm.ident = !{!0}
!0 = !{!"clang version 4.0.0 (trunk 2821
[llvm-bugs] [Bug 30502] New: AVX512: incorrect code generation for simple piece of code (KNL & CNL backends affected)
https://llvm.org/bugs/show_bug.cgi?id=30502
Bug ID: 30502
Summary: AVX512: incorrect code generation for simple piece of
code (KNL & CNL backends affected)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: wenzel.ja...@epfl.ch
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I've run into issues where the current (trunk) backend for Xeon Phi generates
incorrect code. As with similar issues before, it's got something to do with
LLVM's use of mask registers.
The snippet is given below (I tried to make it as small as possible). It makes
no use of AVX512 features whatsoever.
Try it as follows:
$ clang++ -march=nocona -std=c++11 -stdlib=libc++ -O0 -fno-rtti -fno-exceptions
-o test_works
$ ./test_works
(no crash)
$ clang++ -march=knl -std=c++11 -stdlib=libc++ -O0 -fno-rtti -fno-exceptions -o
test_broken
$ ./test_broken
[2] 91952 segmentation fault (core dumped) ./test_broken
Looking at the diff of the assembly files generated by the two different
backends, there is only one change which is not equivalent and thus introduces
the failure:
$ diff -u assembly-nocona.s assembly-knl.s [INS]
--- assembly-nocona.s2016-09-23 11:09:30.0 +0200
+++ assembly-knl.s2016-09-23 11:09:30.0 +0200
@@ -66,7 +66,8 @@
movq%rax, -24(%rbp) # 8-byte Spill
callq_ZN5ArrayC2Ev
movb$1, -1(%rbp)
-testb$1, -1(%rbp)
+movb-1(%rbp), %cl
+kortestw%cl, %cl
jne.LBB1_2
# BB#1:
movq-16(%rbp), %rdi # 8-byte Reload
=
#include
/* Some dummy data structure */
struct Data { float f; };
/* Stores a 'Data' instance via unique_ptr */
struct Array {
using Holder = std::unique_ptr;
Array() : data(new Data[1]) { }
Array(const Array &) : data(new Data[1]) { }
static Array Make() { Array result; return result; }
Array &operator=(Array &value) { data[0] = value.data[0]; return *this; }
Holder data;
};
int main(int /* argc */, char * /* argv */[]) {
Array a = Array::Make();
/* This next line causes a crash (nullptr dereference in __memcpy) */
Data result = a.data[0];
/* Quench unused variable warning */
(void) result;
return 0;
}
===
--
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 30503] New: SSE instructions are generated with SSE disabled
https://llvm.org/bugs/show_bug.cgi?id=30503
Bug ID: 30503
Summary: SSE instructions are generated with SSE disabled
Product: libraries
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: simonas+llvm@kazlauskas.me
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Compiling
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: uwtable
define internal i64 @banana() unnamed_addr #0 {
entry-block:
ret i64 0
}
; Function Attrs: nounwind uwtable
define x86_64_win64cc i64 @peach() unnamed_addr #1 {
entry-block:
%0 = call i64 @banana()
ret i64 %0
}
attributes #0 = { uwtable }
attributes #1 = { nounwind uwtable }
with `llc test.ll -mattr="-sse,-mmx,+soft_float" -filetype=asm -o -` produces
assembly which contains SSE (movaps) instructions, despite SSE being disabled:
peach: # @peach
.cfi_startproc
# BB#0: # %entry-block
pushq%rsi
.Ltmp0:
.cfi_def_cfa_offset 16
pushq%rdi
.Ltmp1:
.cfi_def_cfa_offset 24
subq$168, %rsp
movaps%xmm15, 144(%rsp) # 16-byte Spill
movaps%xmm14, 128(%rsp) # 16-byte Spill
movaps%xmm13, 112(%rsp) # 16-byte Spill
movaps%xmm12, 96(%rsp)# 16-byte Spill
# and so forth
Issue is present in 3.8 as well.
--
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 30500] ICE: when Clang build case with -std=c++14 occurred ICE, but pass -std=c++11 on PPC
https://llvm.org/bugs/show_bug.cgi?id=30500 Hal Finkel changed: What|Removed |Added Status|CLOSED |REOPENED CC||hfin...@anl.gov Resolution|INVALID |--- --- Comment #2 from Hal Finkel --- (In reply to comment #1) > Hi Wu, > > Could you please comment on why this was invalid? It looks like a valid ICE > to me? What is a valid ICE? The frontend should not crash, even on invalid inputs. -- 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 30504] New: crash on at -O1 and above in both 32-bit ad 64-bit modes on x86_64-linux-gnu (Segmentation fault, Early GVN Hoisting of Expressions)
https://llvm.org/bugs/show_bug.cgi?id=30504 Bug ID: 30504 Summary: crash on at -O1 and above in both 32-bit ad 64-bit modes on x86_64-linux-gnu (Segmentation fault, Early GVN Hoisting of Expressions) Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: chengnian...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ clang-trunk -v clang version 4.0.0 (trunk 282170) (llvm/trunk 282169) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -O3 small.c #0 0x01c9e585 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1c9e585) #1 0x01c9c52e llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1c9c52e) #2 0x01c9c692 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1c9c692) #3 0x7f1be8e61340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x01b41e41 (anonymous namespace)::GVNHoist::hasEHOrLoadsOnPath(llvm::Instruction const*, llvm::MemoryDef*, int&) (/usr/local/clang-trunk/bin/clang-4.0+0x1b41e41) #5 0x01b439fc (anonymous namespace)::GVNHoist::safeToHoistLdSt(llvm::Instruction const*, llvm::Instruction const*, llvm::MemoryUseOrDef*, (anonymous namespace)::GVNHoist::InsKind, int&) [clone .constprop.450] (/usr/local/clang-trunk/bin/clang-4.0+0x1b439fc) #6 0x01b43e8c (anonymous namespace)::GVNHoist::computeInsertionPoints(llvm::DenseMap, llvm::SmallVector, llvm::DenseMapInfo >, llvm::detail::DenseMapPair, llvm::SmallVector > > const&, llvm::SmallVector >, 4u>&, (anonymous namespace)::GVNHoist::InsKind) [clone .constprop.444] (/usr/local/clang-trunk/bin/clang-4.0+0x1b43e8c) #7 0x01b44ad7 (anonymous namespace)::GVNHoist::run(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x1b44ad7) #8 0x01b45dcb (anonymous namespace)::GVNHoistLegacyPass::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x1b45dcb) #9 0x0191ad13 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x191ad13) #10 0x0191ae77 llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x191ae77) #11 0x0191af44 llvm::legacy::FunctionPassManager::run(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x191af44) #12 0x01dfd7b2 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x1dfd7b2) #13 0x023fd6c8 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/clang-trunk/bin/clang-4.0+0x23fd6c8) #14 0x027d5462 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x27d5462) #15 0x023fdabe clang::CodeGenAction::ExecuteAction() (/usr/local/clang-trunk/bin/clang-4.0+0x23fdabe) #16 0x02110d46 clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang-4.0+0x2110d46) #17 0x020eb44e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang-4.0+0x20eb44e) #18 0x02198936 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/clang-trunk/bin/clang-4.0+0x2198936) #19 0x
[llvm-bugs] [Bug 30505] New: !range metadata pessimizes generated assembly
https://llvm.org/bugs/show_bug.cgi?id=30505 Bug ID: 30505 Summary: !range metadata pessimizes generated assembly Product: libraries Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: simonas+llvm@kazlauskas.me CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17340 --> https://llvm.org/bugs/attachment.cgi?id=17340&action=edit Case where pessimisation happens In the attached test case the instruction %1 = load i8, i8* %0, !range !1 has range metadata attached to it. In LLVM 3.9 Combine Redundant instructions pass replaces this load with %1 = load i8, i8* %0, align 1, !range !1 %trunc = trunc i8 %1 to i2 The truncation ends up never getting removed and results in extra and unnecessary `andb $3, %dil` instruction in the optimised assembly. This extra instruction is causing some noticeable overhead in a tight loop. --- LLVM 3.8 does not apply the transformation detailed above. Therefore it does not emit the superfluous `andb` instruction either. As far as fixes are concerned, perhaps it would make sense to only `trunc` to the bitwidths supported by the target machine? -- 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 30506] New: does not declare _tzcnt_u32
https://llvm.org/bugs/show_bug.cgi?id=30506 Bug ID: 30506 Summary: does not declare _tzcnt_u32 Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: froy...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Firefox's copy of FFmpeg includes on MSVC to get access to _tzcnt_u32: https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/libavutil/x86/intmath.h#26 This is the same as upstream: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/intmath.h#L26 Upstream FFmpeg used to include for the same purpose ( declares it in MSVC, which is included by MSVC's ), until that was discovered to not work on older MSVC installations: https://github.com/FFmpeg/FFmpeg/commit/f98417451291a3ff6719d739b5e904e0b7bf404b Unfortunately, clang-cl's doesn't declare _tzcnt_u32, which breaks compiling Firefox. -- 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 30484] [LibCallSimplifier] Both operands to a binary operator are not of the same type
https://llvm.org/bugs/show_bug.cgi?id=30484 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Sanjay Patel --- This should be fixed with: https://reviews.llvm.org/rL282278 -- 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 27440] Binary built with `-flto` errors on ARM
https://llvm.org/bugs/show_bug.cgi?id=27440 PeteVine changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from PeteVine --- Not sure if the cmake-based build system started sanitizing those flags or it's something else entirely but I believe I succeeded in doing an `-flto` build a while ago. -- 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 26882] `-force-target-max-vector-interleave=0` leads to segfault
https://llvm.org/bugs/show_bug.cgi?id=26882 PeteVine changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX -- 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 30507] New: Disassembly asserts for certain invalid PowerPC instructions
https://llvm.org/bugs/show_bug.cgi?id=30507 Bug ID: 30507 Summary: Disassembly asserts for certain invalid PowerPC instructions Product: libraries Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: njholc...@wi.rr.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Calls to LLVMDisasmInstruction() with certain invalid PPC instructions fails due to assertions instead of returning an error. Below are 4 asserts that were hit, including example input bytes: Input: fe 47 c0 0a llvm/lib/Target/PowerPC/InstPrinter/PPCInstPrinter.cpp:256: void llvm::PPCInstPrinter::printU1ImmOperand(const llvm::MCInst*, unsigned int, llvm::raw_ostream&): Assertion `Value <= 1 && "Invalid u1imm argument!"' failed. Input: 12 d0 e2 0d llvm/lib/Target/PowerPC/InstPrinter/PPCInstPrinter.cpp:277: void llvm::PPCInstPrinter::printU4ImmOperand(const llvm::MCInst*, unsigned int, llvm::raw_ostream&): Assertion `Value <= 15 && "Invalid u4imm argument!"' failed. Input: 7f 1f ce 5d llvm/lib/Target/PowerPC/Disassembler/PPCDisassembler.cpp:210: DecodeStatus decodeRegisterClass(llvm::MCInst&, uint64_t, const unsigned int (&)[N]) [with long unsigned int N = 8ul; DecodeStatus = llvm::MCDisassembler::DecodeStatus; uint64_t = long unsigned int]: Assertion `RegNo < N && "Invalid register number"' failed. Input: 7c 96 36 1d llvm/include/llvm/MC/MCInst.h:75: int64_t llvm::MCOperand::getImm() const: Assertion `isImm() && "This is not an immediate"' 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 30465] Produce a warning when the entry symbol is not found
https://llvm.org/bugs/show_bug.cgi?id=30465 Rafael Ávila de Espíndola changed: What|Removed |Added Status|ASSIGNED|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 30497] Xcode toolchain issue
https://llvm.org/bugs/show_bug.cgi?id=30497 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED CC||chris.biene...@me.com Resolution|--- |WONTFIX --- Comment #2 from Chris Bieneman --- The Xcode-toolchain support isn't critical enough to justify pulling into the release branches, especially not to support newer versions of Xcode. As a result this will be fixed in LLVM 4.0 and later. -- 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 30427] Tonga Unreal elemental bad rendering since [AMDGPU] Refactor MUBUF/MTBUF instructions
https://llvm.org/bugs/show_bug.cgi?id=30427 valery.pykhtin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from valery.pykhtin --- The patch has been submitted as r282296, thanks for reporting this. -- 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 30508] New: modulemap umbrellas check for folder existence
https://llvm.org/bugs/show_bug.cgi?id=30508
Bug ID: 30508
Summary: modulemap umbrellas check for folder existence
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Modules
Assignee: unassignedclangb...@nondot.org
Reporter: vvasi...@cern.ch
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
cat T.cxx
#include "A.h"
int i;
cat includes/A.h
cat includes/module.modulemap
module NonExistent1 {
umbrella "NonExistent"
module * { export * }
}
module NonExistent2 {
module H1 { header "NonExistent/H1" export * }
module H2 { header "NonExistent/H2" export * }
}
clang++ -I includes -fmodules -fsyntax-only T.cxx
includes/module.modulemap:2:12: error: umbrella directory 'NonExistent' not
found umbrella "NonExistent"
If I comment out module NonExistent1 but leave NonExistent2 it compiles just
fine, even if the folder NonExistent does not exist.
IMO, the umbrella module NonExistent1 should behave as NonExistent2, i.e. not
complain if the folder doesn't exist.
This would help users (including our frameworks) shorten the modulemaps, adding
umbrella modules for optional components.
--
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 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://llvm.org/bugs/show_bug.cgi?id=26299 Bug 26299 depends on bug 30337, which changed state. Bug 30337 Summary: Don't emit Win64 pdata/xdata for "leaf" functions https://llvm.org/bugs/show_bug.cgi?id=30337 What|Removed |Added Status|NEW |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 30337] Don't emit Win64 pdata/xdata for "leaf" functions
https://llvm.org/bugs/show_bug.cgi?id=30337 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- r282185 -- 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 30509] New: [REGRESSION] Compiler aborts in LTO
https://llvm.org/bugs/show_bug.cgi?id=30509 Bug ID: 30509 Summary: [REGRESSION] Compiler aborts in LTO Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: elena.demikhov...@intel.com Reporter: santosh.zanju...@amd.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Compiler aborts while building one of our internal benchmarks with following build error: trunk/llvm/lib/LTO/LTO.cpp:335: llvm::Error llvm::lto::LTO::addRegularLTO(std::unique_ptr, llvm::ArrayRef): Assertion `ResI != Res.end()' failed. clang-4.0: error: unable to execute command: Aborted (core dumped) I shall try to come up with a test case. The regression is introduced in r281853. -- 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 30510] New: clang-4.0: tools/clang/lib/Basic/SourceManager.cpp:1411: clang::SrcMgr::CharacteristicKind clang::SourceManager::getFileCharacteristic(clang::SourceLocation) const: Assert
https://llvm.org/bugs/show_bug.cgi?id=30510 Bug ID: 30510 Summary: clang-4.0: tools/clang/lib/Basic/SourceManager.cpp:1411: clang::SrcMgr::CharacteristicKind clang::SourceManager::getFileCharacteristic(clang::Sou rceLocation) const: Assertion `Loc.isValid() && "Can't get file characteristic of invalid loc!"' failed. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: r...@rink.nu CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17341 --> https://llvm.org/bugs/attachment.cgi?id=17341&action=edit Source file I've recently cleaned out some header files for my OS and I was hit by an assertion failure as illustrated below. This is clang r278597 - it is quite possible that this is my own doing, but it shouldn't assert. Here goes: /home/rink/build/src/llvm-build/bin/clang -m64 -march=athlon64 -mcmodel=large -I../../../../../include -I../../../.. -I. -std=c99 -mno-red-zone -fno-stack-protector -DKERNEL -Wall -Werror -c -o acpi-smp.o ../../../../arch/x86/acpi-smp.c clang-4.0: /home/rink/build/src/llvm/tools/clang/lib/Basic/SourceManager.cpp:1411: clang::SrcMgr::CharacteristicKind clang::SourceManager::getFileCharacteristic(clang::SourceLocation) const: Assertion `Loc.isValid() && "Can't get file characteristic of invalid loc!"' failed. #0 0x012a3ed5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x12a3ed5) #1 0x012a1bce llvm::sys::RunSignalHandlers() (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x12a1bce) #2 0x012a1d32 SignalHandler(int) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x12a1d32) #3 0x7f3da74f3eb0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10eb0) #4 0x7f3da62b2198 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x33198) #5 0x7f3da62b361a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3461a) #6 0x7f3da62ab0d7 (/lib/x86_64-linux-gnu/libc.so.6+0x2c0d7) #7 0x7f3da62ab182 (/lib/x86_64-linux-gnu/libc.so.6+0x2c182) #8 0x013ebd38 clang::SourceManager::getFileCharacteristic(clang::SourceLocation) const (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x13ebd38) #9 0x01fee782 clang::Sema::MergeTypedefNameDecl(clang::Scope*, clang::TypedefNameDecl*, clang::LookupResult&) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1fee782) #10 0x01fee898 clang::Sema::ActOnTypedefNameDecl(clang::Scope*, clang::DeclContext*, clang::TypedefNameDecl*, clang::LookupResult&, bool&) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1fee898) #11 0x01feee55 clang::Sema::ActOnTypedefDeclarator(clang::Scope*, clang::Declarator&, clang::DeclContext*, clang::TypeSourceInfo*, clang::LookupResult&) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1feee55) #12 0x0200f3e8 clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x200f3e8) #13 0x0200f99a clang::Sema::ActOnDeclarator(clang::Scope*, clang::Declarator&) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x200f99a) #14 0x01d737fd clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1d737fd) #15 0x01d80eca clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1d80eca) #16 0x01d83c24 clang::Parser::ParseSimpleDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1d83c24) #17 0x01d83f16 clang::Parser::ParseDeclaration(unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1d83f16) #18 0x01d64e71 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1d64e71) #19 0x01d65789 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1d65789) #20 0x01d5ad7b clang::ParseAST(clang::Sema&, bool, bool) (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1d5ad7b) #21 0x01a11f37 clang::CodeGenAction::ExecuteAction() (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1a11f37) #22 0x01736a36 clang::FrontendAction::Execute() (/extra0/rink/build/src/llvm-build/bin/clang-4.0+0x1736a36) #23 0x0
