[llvm-bugs] [Bug 37335] New: "Assertion `Val != nullptr && Val->getType()->isPointerTy()' failed." with -cfl-anders-aa -dse
https://bugs.llvm.org/show_bug.cgi?id=37335 Bug ID: 37335 Summary: "Assertion `Val != nullptr && Val->getType()->isPointerTy()' failed." with -cfl-anders-aa -dse Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 20263 --> https://bugs.llvm.org/attachment.cgi?id=20263&action=edit reproducer opt -S -cfl-anders-aa -dse -o - tr15970.ll gives opt: ../lib/Analysis/CFLGraph.h:208: void llvm::cflaa::CFLGraphBuilder::GetEdgesVisitor::addNode(llvm::Value *, AliasAttrs) [CFLAA = llvm::CFLAndersAAResult]: Assertion `Val != nullptr && Val->getType()->isPointerTy()' failed. Stack dump: 0. Program arguments: ../llvm-patch/build-all/bin/opt -S -cfl-anders-aa -dse -o - tr15970.ll 1. Running pass 'Function Pass Manager' on module 'tr15970.ll'. 2. Running pass 'Dead Store Elimination' on function '@f2' #0 0x01f68bf4 PrintStackTraceSignalHandler(void*) (../llvm-patch/build-all/bin/opt+0x1f68bf4) #1 0x01f69366 SignalHandler(int) (../llvm-patch/build-all/bin/opt+0x1f69366) #2 0x7ffbe637b330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7ffbe4f6ac37 gsignal /build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7ffbe4f6e028 abort /build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7ffbe4f63bf6 __assert_fail_base /build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0 #6 0x7ffbe4f63ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x014213b6 (../llvm-patch/build-all/bin/opt+0x14213b6) #8 0x01420095 llvm::cflaa::CFLGraphBuilder::buildGraphFrom(llvm::Function&) (../llvm-patch/build-all/bin/opt+0x1420095) #9 0x0141afa8 llvm::CFLAndersAAResult::buildInfoFrom(llvm::Function const&) (../llvm-patch/build-all/bin/opt+0x141afa8) #10 0x0141e2a0 llvm::CFLAndersAAResult::scan(llvm::Function const&) (../llvm-patch/build-all/bin/opt+0x141e2a0) #11 0x0141e766 llvm::CFLAndersAAResult::ensureCached(llvm::Function const&) (../llvm-patch/build-all/bin/opt+0x141e766) #12 0x0141e9a3 llvm::CFLAndersAAResult::query(llvm::MemoryLocation const&, llvm::MemoryLocation const&) (../llvm-patch/build-all/bin/opt+0x141e9a3) #13 0x013db8bf llvm::AAResults::alias(llvm::MemoryLocation const&, llvm::MemoryLocation const&) (../llvm-patch/build-all/bin/opt+0x13db8bf) #14 0x013f37f4 llvm::BasicAAResult::aliasCheck(llvm::Value const*, unsigned long, llvm::AAMDNodes, llvm::Value const*, unsigned long, llvm::AAMDNodes, llvm::Value const*, llvm::Value const*) (../llvm-patch/build-all/bin/opt+0x13f37f4) #15 0x013f2ca0 llvm::BasicAAResult::alias(llvm::MemoryLocation const&, llvm::MemoryLocation const&) (../llvm-patch/build-all/bin/opt+0x13f2ca0) #16 0x013db8bf llvm::AAResults::alias(llvm::MemoryLocation const&, llvm::MemoryLocation const&) (../llvm-patch/build-all/bin/opt+0x13db8bf) #17 0x014e4270 llvm::MemoryDependenceResults::getSimplePointerDependencyFrom(llvm::MemoryLocation const&, bool, llvm::ilist_iterator, false, false>, llvm::BasicBlock*, llvm::Instruction*, unsigned int*) (../llvm-patch/build-all/bin/opt+0x14e4270) #18 0x014e3f9e llvm::MemoryDependenceResults::getSimplePointerDependencyFrom(llvm::MemoryLocation const&, bool, llvm::ilist_iterator, false, false>, llvm::BasicBlock*, llvm::Instruction*, unsigned int*) (../llvm-patch/build-all/bin/opt+0x14e3f9e) #19 0x014e4bb3 llvm::MemoryDependenceResults::getDependency(llvm::Instruction*) (../llvm-patch/build-all/bin/opt+0x14e4bb3) #20 0x01d12812 eliminateDeadStores(llvm::BasicBlock&, llvm::AAResults*, llvm::MemoryDependenceResults*, llvm::DominatorTree*, llvm::TargetLibraryInfo const*) (../llvm-patch/build-all/bin/opt+0x1d12812) #21 0x01d12346 (anonymous namespace)::DSELegacyPass::runOnFunction(llvm::Function&) (../llvm-patch/build-all/bin/opt+0x1d12346) #22 0x01a0e298 llvm::FPPassManager::runOnFunction(llvm::Function&) (../llvm-patch/build-all/bin/opt+0x1a0e298) #23 0x01a0e4d8 llvm::FPPassManager::runOnModule(llvm::Module&) (../llvm-patch/build-all/bin/opt+0x1a0e4d8) #24 0x01a0e9b5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (../llvm-patch/build-all/bin/opt+0x1a0e9b5) #25 0x00738b35 main (../llvm-patch/build-all/bin/opt+0x738b35) #26 0x7ffbe4f55f45 __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0 #27 0x007225fd _start (../llvm-patch/build-all/bin/opt+0x7225fd) Abort This seems to be old, I've seen it already on binaries from november 2016. -- You are receiving this mail because: You are on the CC list for the bug._
[llvm-bugs] [Bug 37336] New: -rewrite-macros breaks for consecutive comments
https://bugs.llvm.org/show_bug.cgi?id=37336 Bug ID: 37336 Summary: -rewrite-macros breaks for consecutive comments Product: clang Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: jackan...@gmail.com CC: llvm-bugs@lists.llvm.org The following code: /* Comment 1 */ /* Comment 2 */ Gets rewritten by -rewrite-macros as: /* Comment 1 */ /*/* Comment 2 */*/ which then will fail to compile. This behaviour applies to the first pair of any consecutive comments separated only by whitespace, including in the context of other code. E.g. // Comment 3 /* Comment 4 */ becomes: // Comment 3 /*/* Comment 4 */*/ and // Comment 5 // Comment 6 // Comment 7 // Comment 8 becomes // Comment 5 /* // Comment 6 */ // Comment 7 // Comment 8 (The last one is legal code but still not desirable.) -- 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 37321] Regression in SVN r331337, "new fragment outside of original fragment"
https://bugs.llvm.org/show_bug.cgi?id=37321 bjorn.a.petters...@ericsson.com changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from bjorn.a.petters...@ericsson.com --- The assertion started to fail with SVN r331337. That commit was reverted in r331441. The reverted debug info enhancements that were reapplied in r331464, together with a fix to handle an existing DIExpression with fragments correctly. So I consider this issue as resolved now. -- 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 37337] New: Many new warnings with gcc-8
https://bugs.llvm.org/show_bug.cgi?id=37337 Bug ID: 37337 Summary: Many new warnings with gcc-8 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: developm...@jonas-toth.eu CC: llvm-bugs@lists.llvm.org Created attachment 20264 --> https://bugs.llvm.org/attachment.cgi?id=20264&action=edit Sorted, Unique Warnings from gcc-8 Using the new gcc-8 to build LLVM and clang results in many new warnings, that are most related to `-Wclass-memaccess`. Example: ``` llvm/include/llvm/ADT/SmallVector.h:312:11: warning: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘struct std::pair’ with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess] memcpy(this->end(), &Elt, sizeof(T)); ~~^~ ``` All unique and sorted warnings are in the attachment. -- 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 37338] New: Wrong (confusing) diagnostic messages for unsatisfied __target__ function attributes
https://bugs.llvm.org/show_bug.cgi?id=37338
Bug ID: 37338
Summary: Wrong (confusing) diagnostic messages for unsatisfied
__target__ function attributes
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: gabor.bue...@intel.com
CC: llvm-bugs@lists.llvm.org
Steps to reproduce
==
Compile the following source (without avx512f, or avx2 enabled):
static inline void __attribute__((__always_inline__, __target__("avx512f")))
x(void)
{
}
int main(void)
{
x();
}
Actual results
==
foo.c:7:2: error: always_inline function 'x' requires target feature 'avx2',
but would be inlined into function 'main' that is compiled without support for
'avx2'
x();
^
1 error generated.
Expected Results
foo.c:7:2: error: always_inline function 'x' requires target feature 'avx512f',
but would be inlined into function 'main' that is compiled without support for
'avx512f'
x();
^
1 error 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 37339] New: FunctionComparator::cmpInlineAsm is overly restrictive
https://bugs.llvm.org/show_bug.cgi?id=37339 Bug ID: 37339 Summary: FunctionComparator::cmpInlineAsm is overly restrictive Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: n.ox...@gmail.com CC: llvm-bugs@lists.llvm.org cmpInlineAsm will crash with an assertion if the two InlineAsm pointers aren't equal but their fields are all compared equal. This is overly restrictive, given two function types may compare equal even if they don't point to the same function type. This leads to https://godbolt.org/g/qn3ZNM failing to compile with assertions on. Found in https://github.com/rust-lang/rust/pull/49479#issuecomment-386406036. -- 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 37340] New: /fp in CL-compat does not produce OrderedCompares
https://bugs.llvm.org/show_bug.cgi?id=37340
Bug ID: 37340
Summary: /fp in CL-compat does not produce OrderedCompares
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: alexandre.ga...@ubisoft.com
CC: llvm-bugs@lists.llvm.org
The behavior between MSVC cl.exe and clang, in regards to the /fp flag, seems
to be different when comparing NaNs.
Consider:
// a.cpp
int main() {
unsigned long a = 0xffc0; // -Nan
float f = *(float*)&a;
if (f <= -1.f)
return 1;
return 0;
}
(MSVC) cl.exe a.cpp /arch:AVX2 /Z7 /fp:fast
if (f <= -1.f)
7FF6EA036586 vmovss xmm0,dword ptr [f]
7FF6EA03658C vcomiss xmm0,dword ptr [__real@bf80 (07FF6EA094F10h)]
7FF6EA036594 ja main+2Dh (07FF6EA03659Dh)
(MSVC) cl.exe a.cpp /arch:AVX2 /Z7 /fp:precise
if (f <= -1.f)
7FF70AF06586 vmovss xmm0,dword ptr [__real@bf80 (07FF70AF64F10h)]
7FF70AF0658E vcomiss xmm0,dword ptr [f]
7FF70AF06594 jb main+2Dh (07FF70AF0659Dh)
(Clang) clang-cl.exe a.cpp /arch:AVX2 /Z7 /fp:fast
if (f <= -1.f)
7FF7DAAF6598 vucomissxmm0,dword ptr [f]
7FF7DAAF659E jb main+41h (07FF7DAAF65B1h)
(Clang) clang-cl.exe a.cpp /arch:AVX2 /Z7 /fp:precise
if (f <= -1.f)
7FF7DAAF6598 vucomissxmm0,dword ptr [f]
7FF7DAAF659E jb main+41h (07FF7DAAF65B1h)
(same as above)
Actually, no matter which /fp: or -f*math* you pass to clang, the result is the
same (when using the clang-cl driver). As you can see, Clang generates
'ucomiss' instructions in all cases, instead of 'comiss' as in cl.exe. Omiting
/arch:AVX2 gives the same result.
I am at r331502.
--
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 37341] New: Missed optimization: optimize unnecessary std::sort
https://bugs.llvm.org/show_bug.cgi?id=37341
Bug ID: 37341
Summary: Missed optimization: optimize unnecessary std::sort
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: zamazan...@tut.by
CC: llvm-bugs@lists.llvm.org
clang trunk with -O3 for code below doesn't optimize std::sort (compiler must
remove it from output binary):
#include
#include
void foo(int* a, int size)
{
std::sort(a, a + size);
}
int bar(int* a, int b)
{
foo(a, b);
return std::accumulate(a, a + b, 0);
}
GCC has similar behaviour. Is it possible to optimize it?
--
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 37342] New: New Pass Manager loop passes can't get cached OptimizationRemarkEmitter when invalidated by earlier loop pass
https://bugs.llvm.org/show_bug.cgi?id=37342 Bug ID: 37342 Summary: New Pass Manager loop passes can't get cached OptimizationRemarkEmitter when invalidated by earlier loop pass Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tejohn...@google.com CC: llvm-bugs@lists.llvm.org I hit the following error when trying to use pass remarks with hotness: LLVM ERROR: LICM: OptimizationRemarkEmitterAnalysis not cached at a higher level from LICMPass, which is trying to get it as cached analysis. There was a fix done in r292058 to try to keep this analysis valid, however, that doesn't work if a prior loop pass invalidated it. In my case, it was being invalidated by LoopSimplifyPass. I reproduced this by running a loop simplification test with new options: opt test/Transforms/LoopSimplify/basictest.ll -disable-output -aa-pipeline=basic-aa 2>&1 -passes='require,invalidate,require,loop(licm)' -debug-pass-manager -pass-remarks=licm -pass-remarks-with-hotness (i.e. the same options being run in the test added for r292058). The tail end of the output is: ... Invalidating analysis: OptimizationRemarkEmitterAnalysis on test Running pass: RequireAnalysisPass> on test Running analysis: OptimizationRemarkEmitterAnalysis on test Running analysis: BlockFrequencyAnalysis on test Running pass: FunctionToLoopPassAdaptor > on test Starting llvm::Function pass manager run. Running pass: LoopSimplifyPass on test Running analysis: AssumptionAnalysis on test Invalidating all non-preserved analyses for: test Invalidating analysis: BranchProbabilityAnalysis on test Invalidating analysis: BlockFrequencyAnalysis on test Invalidating analysis: OptimizationRemarkEmitterAnalysis on test Running pass: LCSSAPass on test Finished llvm::Function pass manager run. Running analysis: AAManager on test Running analysis: BasicAA on test Running analysis: ScalarEvolutionAnalysis on test Running analysis: TargetIRAnalysis on test Running analysis: InnerAnalysisManagerProxy on test Starting Loop pass manager run. Running pass: LICMPass on Loop at depth 1 containing: %bb3 Running analysis: OuterAnalysisManagerProxy on bb3 LLVM ERROR: LICM: OptimizationRemarkEmitterAnalysis not cached at a higher level Not sure how this is supposed to work or should be 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 37343] New: The SSE _mm_invsqrt_ps intrinsic is missing.
https://bugs.llvm.org/show_bug.cgi?id=37343 Bug ID: 37343 Summary: The SSE _mm_invsqrt_ps intrinsic is missing. Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Headers Assignee: unassignedclangb...@nondot.org Reporter: gonzalob...@gmail.com CC: llvm-bugs@lists.llvm.org The intel intrinsic guide https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_invsqrt_ps&expand=4513,3028,3028 Shows the intrinsic as: __m128 _mm_invsqrt_ps (__m128 a) #include CPUID Flags: SSE Description Compute the inverse square root of packed single-precision (32-bit) floating-point elements in a, and store the results in dst. Operation FOR j := 0 to 3 i := j*32 dst[i+31:i] := InvSQRT(a[i+31:i]) ENDFOR dst[MAX:128] := 0 But it is not implemented in the clang headers. -- 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 37344] New: vector approximate reciprocal square root generates bad code on x86
https://bugs.llvm.org/show_bug.cgi?id=37344
Bug ID: 37344
Summary: vector approximate reciprocal square root generates
bad code on x86
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following LLVM IR (see it live: https://godbolt.org/g/88kuky) computes the
approximate vector reciprocal square root rsqrt(x) ~= 1/ sqrt(x):
declare <4 x float> @llvm.sqrt.v4f32(<4 x float>)
define <4 x float> @rsqrt(<4 x float>) {
%a = call afn <4 x float> @llvm.sqrt.v4f32(<4 x float> %0)
%c = fdiv <4 x float> , %a
ret <4 x float> %c
}
On x86_64 with -O3 and sse4.2 they generate the following assembly:
LCPI0_0:
.long 1065353216 # float 1
.long 1065353216 # float 1
.long 1065353216 # float 1
.long 1065353216 # float 1
rsqrt: # @rsqrt
sqrtps xmm1, xmm0
movaps xmm0, xmmword ptr [rip + .LCPI0_0]
divps xmm0, xmm1
ret
However, it should just generate a call to rsqrtps .
I've tried with fast math flags but haven't been able to generate rsqrtps yet.
--
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 37345] New: clang crashes on valid code at -Os and above: Assertion `idx < size()' failed
https://bugs.llvm.org/show_bug.cgi?id=37345 Bug ID: 37345 Summary: clang crashes on valid code at -Os and above: Assertion `idx < size()' failed Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Tested with trunk revision 331481. $ clangpolly -v clang version 7.0.0 (http://llvm.org/git/clang.git 448ee95831d1eca7143e7639718584faba754da2) (llvm/trunk 331481) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/su/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4 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.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 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.4 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 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clangpolly -O1 -c -w small.c $ $ clangpolly -Os -c -w small.c clang-6.0: /home/su/software/tmp/polly/llvm/include/llvm/ADT/SmallVector.h:149: T& llvm::SmallVectorTemplateCommon >::operator[](llvm::SmallVectorTemplateCommon >::size_type) [with T = llvm::Value*; = void; llvm::SmallVectorTemplateCommon >::reference = llvm::Value*&; llvm::SmallVectorTemplateCommon >::size_type = long unsigned int]: Assertion `idx < size()' failed. Stack dump: 0. Program arguments: /home/su/software/tmp/polly/llvm_build/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -coverage-notes-file /home/su/specres/good/20180501-clangpolly-m32-O3-Wall-Wextra-pedantic-std=c99-build-204641/small.gcno -resource-dir /home/su/software/tmp/polly/llvm_build/lib/clang/7.0.0 -internal-isystem /usr/local/include -internal-isystem /home/su/software/tmp/polly/llvm_build/lib/clang/7.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -Os -w -fdebug-compilation-dir /home/su/specres/good/20180501-clangpolly-m32-O3-Wall-Wextra-pedantic-std=c99-build-204641 -ferror-limit 19 -fmessage-length 116 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o small.o -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Jump Threading' on function '@m' #0 0x025414da llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/su/software/tmp/polly/llvm/lib/Support/Unix/Signals.inc:403:0 #1 0x0253f68e llvm::sys::RunSignalHandlers() /home/su/software/tmp/polly/llvm/lib/Support/Signals.cpp:50:0 #2 0x0253f7f0 SignalHandler(int) /home/su/software/tmp/polly/llvm/lib/Support/Unix/Signals.inc:243:0 #3 0x7fdc46513330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7fdc452fbc37 gsignal /build/eglibc-SvCtMH/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7fdc452ff028 abort /build/eglibc-SvCtMH/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7fdc452f4bf6 __assert_fail_base /build/eglibc-SvCtMH/eglibc-2.19/assert/assert.c:92:0 #7 0x7fdc452f4ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x01af01e0 llvm::isa_impl_cl::doit(llvm::Value const*) /home/su/software/tmp/polly/llvm/include/llvm/ADT/SmallVector.h:149:0 #9 0x01af01e0 llvm::isa_impl_wrap::doit(llvm::Value const* const&) /home/su/software/tmp/polly/llvm/include/llvm/Support/Casti
[llvm-bugs] [Bug 37340] /fp in CL-compat does not produce OrderedCompares
https://bugs.llvm.org/show_bug.cgi?id=37340 Alexandre Ganea changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED -- 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 37209] Assertio failure in clang::ento::SValBuilder::evalBinOp
https://bugs.llvm.org/show_bug.cgi?id=37209 Artem Dergachev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Artem Dergachev --- Fixed in r331558. -- 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 18953] svn r202006: analyzer crash analyzing 'crystal space' (cs)
https://bugs.llvm.org/show_bug.cgi?id=18953 Artem Dergachev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Artem Dergachev --- Fixed in 331561. -- 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 36458] Assertion failure in clang::ento::ElementRegion::ElementRegion
https://bugs.llvm.org/show_bug.cgi?id=36458 Artem Dergachev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Artem Dergachev --- Fixed in r331562. Np, i'm enjoying it :) -- 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
