[llvm-bugs] [Bug 32837] New: virtual destructor not called
http://bugs.llvm.org/show_bug.cgi?id=32837
Bug ID: 32837
Summary: virtual destructor not called
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: programmerj...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
the S2::~S2() is not called in the following code. This is easiest to see by
compiling with -O because main is optimized to return 0 and do nothing else.
struct S
{
virtual ~S()
{
}
};
struct S2 : public S
{
virtual ~S2()
{
__builtin_printf("never reached\n");
}
};
int main()
{
delete [] static_cast(new S2[1]);
}
clang version 4.0.0 (tags/RELEASE_400/final 299826)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/compiler-explorer/clang-4.0.0/bin
See: https://godbolt.org/g/SlDwMr
--
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 32838] New: clang crashes with "-mllvm -enable-newgvn": "Seem to have processed the same Value a lot"
https://bugs.llvm.org/show_bug.cgi?id=32838 Bug ID: 32838 Summary: clang crashes with "-mllvm -enable-newgvn": "Seem to have processed the same Value a lot" Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: helloqi...@gmail.com CC: llvm-bugs@lists.llvm.org The following code crashes the current trunk version at "-O2" and above with "-mllvm -enable-newgvn". Level "-O1" works fine. $ clang-trunk -v clang version 5.0.0 (trunk 301523) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/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.3 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/i686-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.1.1 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/3.4.6 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.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 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.1.1 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0 Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 $ clang-trunk -O2 -mllvm -enable-newgvn abc.c abc.c:22:9: warning: division by zero is undefined [-Wdivision-by-zero] 0 | 0 / 0 ? p1 /= 4 : 0; ^ ~ clang-5.0: /home/absozero/trunk/llvm/lib/Transforms/Scalar/NewGVN.cpp:2363: void (anonymous namespace)::NewGVN::updateProcessedCount(llvm::Value *): Assertion `ProcessedCount[V] < 100 && "Seem to have processed the same Value a lot"' failed. #0 0x01bfc884 PrintStackTraceSignalHandler(void*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1bfc884) #1 0x01bfcbb6 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1bfcbb6) #2 0x7febe33a3330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7febe1f20c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7febe1f24028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7febe1f19bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #6 0x7febe1f19ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x01aff8b4 (anonymous namespace)::NewGVN::updateProcessedCount(llvm::Value*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1aff8b4) #8 0x01af85a0 (anonymous namespace)::NewGVN::iterateTouchedInstructions() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1af85a0) #9 0x01af2b06 (anonymous namespace)::NewGVN::runGVN() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1af2b06) #10 0x01af0496 NewGVNLegacyPass::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1af0496) #11 0x017a986f llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x17a986f) #12 0x025e2d46 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x25e2d46) #13 0x017a9fc5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x17a9fc5) #14 0x01d83d0b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1d83d0b) #15 0x02473147 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x2473147) #16 0x028cfe26 clang::ParseAST(clang::Sema&, bool, bool) (/home/abs
[llvm-bugs] [Bug 32661] [Polly] miscompile after "Move GVNHoist to function simplificaiton pipeline"
https://bugs.llvm.org/show_bug.cgi?id=32661 Tobias Grosser changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Tobias Grosser --- This seems to work again in 301582 -- 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 32839] New: [X86] Missing _mm256_zextpd128_pd256 et al. helper intrinsics
https://bugs.llvm.org/show_bug.cgi?id=32839 Bug ID: 32839 Summary: [X86] Missing _mm256_zextpd128_pd256 et al. helper intrinsics Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Headers Assignee: unassignedclangb...@nondot.org Reporter: llvm-...@redking.me.uk CC: llvm-bugs@lists.llvm.org ICC provides these helper intrinsics that are similar to their '_mm256_castpd128_pd256' etc. siblings but guarantee zero extension of the upper vector lanes. avxintrin.h: __m256d _mm256_zextpd128_pd256 (__m128d a) __m256 _mm256_zextps128_ps256 (__m128 a) __m256i _mm256_zextsi128_si256 (__m128i a) avx512fintrin.h: __m512d _mm512_zextpd128_pd512 (__m128d a) __m512d _mm512_zextpd256_pd512 (__m256d a) __m512 _mm512_zextps128_ps512 (__m128 a) __m512 _mm512_zextps256_ps512 (__m256 a) __m512i _mm512_zextsi128_si512 (__m128i a) __m512i _mm512_zextsi256_si512 (__m256i a) -- 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 32827] _mm_set_pd1 missing from emmintrin.h
https://bugs.llvm.org/show_bug.cgi?id=32827 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- Fixed rL301637 (clang) and rL301638 (llvm codegen test) -- 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 32840] New: NONDETERMINIZM: It seems, ThreadSanitizer does not understand OpenMP's critical section in C++
https://bugs.llvm.org/show_bug.cgi?id=32840
Bug ID: 32840
Summary: NONDETERMINIZM: It seems, ThreadSanitizer does not
understand OpenMP's critical section in C++
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Example one: (good)
#include
int main() {
#ifdef _OPENMP
#pragma omp parallel num_threads(2)
#endif
#ifdef _OPENMP
#pragma omp critical(io)
#endif
{
printf("thread\n");
}
return 0;
}
$ clang-5.0 openmp-critical.c -fsanitize=thread
$ ./a.out
thread
As you can see, TSan does not complain, and there were only one print.
Let's enable OpenMP.
$ clang-5.0 openmp-critical.c -fsanitize=thread -fopenmp
$ ./a.out
thread
thread
As you can see, TSan does not complain, and there were two prints.
Now, let's check C++.
Example two (bad):
#include
#include
int main() {
#ifdef _OPENMP
#pragma omp parallel num_threads(2)
#endif
#ifdef _OPENMP
#pragma omp critical(io)
#endif
{
std::cout << "thread\n";
}
return 0;
}
$ clang++-5.0 openmp-critical.cpp -fsanitize=thread
$ ./a.out
thread
Again all fine. Let's enable OpenMP.
$ clang++-5.0 openmp-critical.cpp -fsanitize=thread -fopenmp
$ ./a.out
==
WARNING: ThreadSanitizer: data race (pid=30729)
Atomic read of size 1 at 0x7b680b00 by main thread:
#0 pthread_mutex_lock (a.out+0x432067)
#1 (libomp.so.5+0x477a2)
#2 __libc_start_main (libc.so.6+0x202b0)
Previous write of size 1 at 0x7b680b00 by thread T2:
#0 pthread_mutex_init (a.out+0x42ae0a)
#1 (libomp.so.5+0x44c51)
Location is heap block of size 1440 at 0x7b680600 allocated by main
thread:
#0 malloc (a.out+0x4296dd)
#1 getenv (libomp.so.5+0x18202)
#2 __libc_start_main (libc.so.6+0x202b0)
Thread T2 (tid=30732, running) created by main thread at:
#0 pthread_create (a.out+0x42ab26)
#1 (libomp.so.5+0x458bb)
#2 __libc_start_main (libc.so.6+0x202b0)
SUMMARY: ThreadSanitizer: data race (/tmp/a.out+0x432067) in pthread_mutex_lock
==
thread
thread
ThreadSanitizer: reported 1 warnings
I'd expect that it should not complain.
And now the weirdest part: it only happens if the system is not in idle, i.e.
if there are some other computational/compilation processes running!
--
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 32841] New: [X86][SSE] Use PHMINPOSUW for i8/i16 min/max reductions
http://bugs.llvm.org/show_bug.cgi?id=32841
Bug ID: 32841
Summary: [X86][SSE] Use PHMINPOSUW for i8/i16 min/max
reductions
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: fil...@gmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
With suitable bit twiddling, PHMINPOSUW can be used to determine the
signed/unsigned min/max element of v16i8/v8i16 vectors, not just umin v8i16.
e.g.
unsigned char umin_v16i8(__m128i a) {
__m128i result = a;
result = _mm_min_epu8( result, _mm_srli_epi16( result, 8 ) );
result = _mm_minpos_epu16( result );
return _mm_extract_epi8(result, 0);
}
char smax_v16i8(__m128i a) {
__m128i k127 = _mm_set1_epi8(127);
__m128i result = a;
result = _mm_xor_si128( k127, result );
result = _mm_min_epu8( result, _mm_srli_epi16( result, 8 ) );
result = _mm_minpos_epu16( result );
result = _mm_xor_si128( k127, result );
return _mm_extract_epi8(result, 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 32842] New: MemorySanitizer false negatives on comparisons
http://bugs.llvm.org/show_bug.cgi?id=32842
Bug ID: 32842
Summary: MemorySanitizer false negatives on comparisons
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: gli...@google.com
CC: dvyu...@google.com, eugeni.stepa...@gmail.com,
k...@google.com, llvm-bugs@lists.llvm.org
Created attachment 18378
--> http://bugs.llvm.org/attachment.cgi?id=18378&action=edit
Reproducer
For the attached program MSan generates code that produces a false negative
when comparing two integers.
Consider iphdr is declared as:
5 struct iphdr {
6 u8 ihl:4, version: 4;
..
12 };
And in the following code iph->ihl is uninitialized (see ub.c for full code):
15 int raw_send_hdrinc(unsigned long int length) {
16 struct iphdr *iph;
17 unsigned int iphlen;
18 int err = 0;
19 iph = get_iphdr();
20 iphlen = iph->ihl * 4;
21 printf("&iphlen: %p\n", &iphlen);
22 err = -1;
23 if (iphlen > length) {
24 printf("error!\n");
25 goto error_free;
26 }
Looking at the IR built with the default flags I see the following
chunk corresponding to the comparison:
90 %27 = load i32, i32* %iphlen, align 4, !tbaa !2
91 %_msld6 = load i32, i32* %21, align 4
92 %_msprop7 = zext i32 %_msld6 to i64
93 %conv2 = zext i32 %27 to i64
94 %_msprop8 = or i64 %1, %_msprop7
95 %28 = and i64 %_msprop8, 1
96 %29 = icmp eq i64 %28, 0
97 %cmp = icmp ugt i64 %conv2, %length
98 br i1 %29, label %34, label %30, !prof !1
Here %1 is the shadow for |length| and %_msld6 is the shadow for |iphlen|.
In the case |length| is fully initialized, the lowest bit of %_msprop8 is zero
(because the two lowest bits of iphlen are initialized).
Then despite the result of comparison is uninitialized and %_msprop8 is
non-zero, it's truncated to a zero bit, so the uninitializedness is lost.
--
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 32835] wrong code (compiled code segfaults) at -O1 and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://bugs.llvm.org/show_bug.cgi?id=32835 Sanjay Patel changed: What|Removed |Added CC||spatel+l...@rotateright.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Sanjay Patel --- I see xors and more xors... :) After viewing the IR, I think this reduces identically to bug 32830, and I can't reproduce the crash using clang built after: https://reviews.llvm.org/rL301594 *** This bug has been marked as a duplicate of bug 32830 *** -- 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 32843] New: Multiple crashes when all analyzers enabled
https://bugs.llvm.org/show_bug.cgi?id=32843 Bug ID: 32843 Summary: Multiple crashes when all analyzers enabled Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: demioben...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18379 --> https://bugs.llvm.org/attachment.cgi?id=18379&action=edit Compressed tar file containing preprocessed source files and logs When all analyzers are enabled, the Clang static analyzer crashes. I have attached preprocessed source files and STDERR output. -- 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 32837] virtual destructor not called
http://bugs.llvm.org/show_bug.cgi?id=32837
Reid Kleckner changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW |RESOLVED
CC||r...@google.com
--- Comment #2 from Reid Kleckner ---
I believe the sample code has UB. Array delete isn't polymorphic, you can't
delete an array of S2 objects as a pointer to an array of S objects. Consider
how this would go wrong for a two-element array when sizeof(S2) != sizeof(S):
struct S { virtual ~S(); };
struct S2 { virtual ~S2() { __builtin_printf("asdf\n"); } int grow; };
int main() { delete [] static_cast(new S2[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 32844] New: Assertion failed: (getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!") function AssertOK, fi
https://bugs.llvm.org/show_bug.cgi?id=32844 Bug ID: 32844 Summary: Assertion failed: (getOperand(0)->getType() == cast(getOperand(1)->getType())->getElemen tType() && "Ptr must be a pointer to Val type!") function AssertOK, file llvm/lib/IR/Instructions.cpp, line 1416 Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: compn...@compnerd.org CC: llvm-bugs@lists.llvm.org Created attachment 18380 --> https://bugs.llvm.org/attachment.cgi?id=18380&action=edit reduced.m See reduced test case. -- 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 32845] New: clang crashes with "-mllvm -enable-newgvn": "New class for instruction should not be dominated by instruction"
https://bugs.llvm.org/show_bug.cgi?id=32845 Bug ID: 32845 Summary: clang crashes with "-mllvm -enable-newgvn": "New class for instruction should not be dominated by instruction" Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: helloqi...@gmail.com CC: llvm-bugs@lists.llvm.org The following code crashes the current trunk version at "-Os" with "-mllvm -enable-newgvn". $ clang-trunk -v clang version 5.0.0 (trunk 301630) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/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.3 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/i686-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.1.1 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/3.4.6 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.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 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.1.1 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0 Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 $ clang-trunk -Os -mllvm -enable-newgvn abc.c abc.c:19:7: warning: incompatible pointer to integer conversion assigning to 'short' from 'int *' [-Wint-conversion] c = g; ^ ~ clang-5.0: /home/absozero/trunk/llvm/lib/Transforms/Scalar/NewGVN.cpp:1940: void (anonymous namespace)::NewGVN::moveValueToNewCongruenceClass(llvm::Instruction *, const llvm::GVNExpression::Expression *, CongruenceClass *, CongruenceClass *): Assertion `!isa(I) && "New class for instruction should not be dominated by instruction"' failed. #0 0x01c049a4 PrintStackTraceSignalHandler(void*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1c049a4) #1 0x01c04cd6 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1c04cd6) #2 0x7f670208b330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7f6700c08c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7f6700c0c028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7f6700c01bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #6 0x7f6700c01ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x01b0b64c (anonymous namespace)::NewGVN::performCongruenceFinding(llvm::Instruction*, llvm::GVNExpression::Expression const*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1b0b64c) #8 0x01afc98a (anonymous namespace)::NewGVN::iterateTouchedInstructions() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1afc98a) #9 0x01af5fe6 (anonymous namespace)::NewGVN::runGVN() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1af5fe6) #10 0x01af3976 NewGVNLegacyPass::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1af3976) #11 0x017ab40f llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x17ab40f) #12 0x025eada6 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x25eada6) #13 0x017abb65 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x17abb65) #14 0x01d8beeb clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1d8beeb) #15 0x0247a527 clang::BackendCon
[llvm-bugs] [Bug 32834] r301144 cause build failure with LibreOffice
https://bugs.llvm.org/show_bug.cgi?id=32834 Luke changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Luke --- This appears to be fixed by r301594, so I'm closing. As of r301609, I can once again build LibreOffice with clang. All required Unit Tests are passing. *** This bug has been marked as a duplicate of bug 32830 *** -- 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 32847] New: wrong code at -Os and above on x86_64-linux-gnu (NewGVN)
https://bugs.llvm.org/show_bug.cgi?id=32847
Bug ID: 32847
Summary: wrong code at -Os and above on x86_64-linux-gnu
(NewGVN)
Product: clang
Version: trunk
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
$ clang -v
clang version 5.0.0 (trunk 301611)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.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.4
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.4.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.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -O0 small.c; ./a.out
$ clang -Os small.c; ./a.out
$
$ clang -Os -mllvm -enable-newgvn small.c
$ ./a.out
1
$
int printf (const char *, ...);
int a, b = -2;
int main ()
{
for (; a < 1; a++)
{
int c = ~b;
if (b > c || !c)
{
printf ("0");
continue;
}
if (c < 0)
printf ("1\n");
}
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 32848] New: -frewrite-includes asserts after file not found error: `LastInclusionLocation.isInvalid() && "Another inclusion directive was found before the previous one " "was processe
https://bugs.llvm.org/show_bug.cgi?id=32848 Bug ID: 32848 Summary: -frewrite-includes asserts after file not found error: `LastInclusionLocation.isInvalid() && "Another inclusion directive was found before the previous one " "was processed"' failed. Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: llvm-bugs@lists.llvm.org Testcase: #include "blah.h" #include "blah.h" $ ./bin/clang -E -frewrite-includes x.cpp x.cpp:1:10: fatal error: 'blah.h' file not found #include "blah.h" ^~~~ clang-4.0: tools/clang/lib/Frontend/Rewrite/InclusionRewriter.cpp:184: virtual void (anonymous namespace)::InclusionRewriter::InclusionDirective(clang::SourceLocation, const clang::Token &, llvm::StringRef, bool, clang::CharSourceRange, const clang::FileEntry *, llvm::StringRef, llvm::StringRef, const clang::Module *): Assertion `LastInclusionLocation.isInvalid() && "Another inclusion directive was found before the previous one " "was processed"' 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 32849] New: clang crashes with "-mllvm -enable-newgvn": "Any class with a store as a " "leader should have a " "representative stored value\n"
https://bugs.llvm.org/show_bug.cgi?id=32849 Bug ID: 32849 Summary: clang crashes with "-mllvm -enable-newgvn": "Any class with a store as a " "leader should have a " "representative stored value\n" Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: helloqi...@gmail.com CC: llvm-bugs@lists.llvm.org The following code crashes the current trunk version at "-O2" and above with "-mllvm -enable-newgvn". Level "-O1" works fine. $ clang-trunk -v clang version 5.0.0 (trunk 301630) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/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.3 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/i686-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.1.1 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/3.4.6 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.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 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.1.1 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0 Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0 Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 $ clang-trunk -O2 -mllvm -enable-newgvn abc.c abc.c:13:24: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] d += (*e += c) && 7; ^ ~ abc.c:13:24: note: use '&' for a bitwise operation d += (*e += c) && 7; ^~ & abc.c:13:24: note: remove constant to silence this warning d += (*e += c) && 7; ~^~~~ clang-5.0: /home/absozero/trunk/llvm/lib/Transforms/Scalar/NewGVN.cpp:2502: void (anonymous namespace)::NewGVN::verifyMemoryCongruency() const: Assertion `(CC->getStoredValue() || !isa(CC->getLeader())) && "Any class with a store as a " "leader should have a " "representative stored value\n"' failed. #0 0x01c049a4 PrintStackTraceSignalHandler(void*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1c049a4) #1 0x01c04cd6 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1c04cd6) #2 0x7faec2ff8330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7faec1b75c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7faec1b79028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7faec1b6ebf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #6 0x7faec1b6eca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x01af8abd (anonymous namespace)::NewGVN::runGVN() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1af8abd) #8 0x01af3976 NewGVNLegacyPass::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1af3976) #9 0x017ab40f llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x17ab40f) #10 0x025eada6 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x25eada6) #11 0x017abb65 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x17abb65) #12 0x01d8beeb clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1d8beeb) #13 0x0247a527 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/absozer
[llvm-bugs] [Bug 32850] New: ARM backend: Assetion Unknown addressing mode for CP reference in ARMConstantIslandPass.cpp!
https://bugs.llvm.org/show_bug.cgi?id=32850 Bug ID: 32850 Summary: ARM backend: Assetion Unknown addressing mode for CP reference in ARMConstantIslandPass.cpp! Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: sabua...@codeaurora.org CC: efrie...@codeaurora.org, kristof.be...@arm.com, llvm-bugs@lists.llvm.org Created attachment 18381 --> https://bugs.llvm.org/attachment.cgi?id=18381&action=edit test case that crashes hile creating a constant island, ARM backend. Command to reproduce: llc test_case_arm_const_island.ll Error: " Unknown addressing mode for CP reference! UNREACHABLE executed at /prj/llvm-arm/home/nightly/src/community-mainline/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:778! #0 0x013ff554 (llc+0x13ff554) #1 0x013ff8c6 (llc+0x13ff8c6) #2 0x7f03d54eb330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7f03d3ee2c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7f03d3ee6028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #5 0x013a933d (llc+0x13a933d) #6 0x006631be (llc+0x6631be) #7 0x00bbc335 (llc+0xbbc335) #8 0x00e8a2d4 (llc+0xe8a2d4) #9 0x00e8a523 (llc+0xe8a523) #10 0x00e8aa63 (llc+0xe8aa63) #11 0x005e17f1 (llc+0x5e17f1) #12 0x005de81b (llc+0x5de81b) #13 0x7f03d3ecdf45 __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0 #14 0x005dcc6d (llc+0x5dcc6d) Stack dump: 0. Program arguments: llc test_case_arm_const_island.ll -o /tmp/a.out 1. Running pass 'Function Pass Manager' on module 'test_case_arm_const_island.ll'. 2. Running pass 'ARM constant island placement and branch shortening pass' on function '@do_more_things'" This might be similar to PR:30470 -- 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 32818] wrong code (compiled code hangs) at -O3 on x86_64-linux-gnu in 64-bit mode (but not in 32-bit)
https://bugs.llvm.org/show_bug.cgi?id=32818 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Davide Italiano --- rL301722 -- 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 26771] -frewrite-includes: Lack of an exit line directive in case of an empty header
https://bugs.llvm.org/show_bug.cgi?id=26771 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk --- Comment #4 from Richard Smith --- Fixed in r301727. -- 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 32785] relocations pointing to SHF_MERGE are not supported
https://bugs.llvm.org/show_bug.cgi?id=32785 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Davide Italiano --- r301729. Thanks! -- 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 32851] New: fix "REQUIRES: system-darwin" tests to not depend on the OS
https://bugs.llvm.org/show_bug.cgi?id=32851 Bug ID: 32851 Summary: fix "REQUIRES: system-darwin" tests to not depend on the OS Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: llvm-bugs@lists.llvm.org We have a bunch of unit tests that say REQUIRES: system-darwin Some of these are just wrong: they work fine on other OSes. Others of them appear to be depending on Darwin system headers, which is inappropriate for Clang unit tests. We should fix these and then remove the ability to specify such a requirement (except perhaps for some extremely targeted driver tests, and even then it's unclear why we can't use a sysroot). -- 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 32852] New: wrong code in NewGVN (with "opt -inline -newgvn") on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=32852
Bug ID: 32852
Summary: wrong code in NewGVN (with "opt -inline -newgvn") on
x86_64-linux-gnu
Product: clang
Version: trunk
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
$ clang -v
clang version 5.0.0 (trunk 301611)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/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
$
$ clang -O0 small.c; ./a.out
$
$ clang -O3 -mllvm -disable-llvm-optzns -c -emit-llvm -o small.bc small.c
$ opt -inline -newgvn -o small-opt.bc small.bc
$ clang small-opt.bc
$ ./a.out
0
$
-
int a;
void foo ()
{
if ((a >= 0) && (a > 0))
__builtin_printf ("0\n");
}
int main ()
{
foo ();
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 32853] New: wrong code at -O2 and -O3 on x86_64-linux-gnu (in NewGVN with "-mllvm -enable-newgvn")
https://bugs.llvm.org/show_bug.cgi?id=32853
Bug ID: 32853
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu (in
NewGVN with "-mllvm -enable-newgvn")
Product: clang
Version: trunk
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
$ clang -v
clang version 5.0.0 (trunk 301611)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.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.4
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.4.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.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -O2 small.c; ./a.out
$ clang -Os -mllvm -enable-newgvn small.c; ./a.out
$
$ clang -O2 -mllvm -enable-newgvn small.c
$ ./a.out
0
$
char a;
int b, c = -1, d;
void foo ()
{
int f = c && 1, g = f + a;
if (d != 1)
{
b = c && (d && g);
if (c > 0)
__builtin_printf ("0\n");
}
}
int main ()
{
foo ();
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 32854] New: Loop-idiom recognition for memset in the inner-loop of a nested-loop interferes with vectorization
https://bugs.llvm.org/show_bug.cgi?id=32854
Bug ID: 32854
Summary: Loop-idiom recognition for memset in the inner-loop of
a nested-loop interferes with vectorization
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: brycelelb...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18382
--> https://bugs.llvm.org/attachment.cgi?id=18382&action=edit
Reduced Test Case
Compilation options, build environment, etc are documented in the attached file
and here:
https://wandbox.org/permlink/o06VeIxCKC1qIhUh
Summary: We have a nested loop like this (where A is a double* __restrict__):
for (ptrdiff_t j = 0; j != N; ++j)
for (ptrdiff_t i = 0; i != N; ++i)
A[i + j * N] = 0.0F;
Loop-idiom recognition determines that it can replace the inner loop with
memset, turning the code into:
for (ptrdiff_t j = 0; j != N; ++j)
std::memset(A + j * N, 0, sizeof(double) * N); // e.g. @llvm.memset
Later, the vectorizer sees this code and decides to bail out because it cannot
vectorize the inserted call to @llvm.memset.
I have so many questions here :)
0.) The diagnostic that the vectorizer pass remarks give is not very helpful:
'call instruction cannot be vectorized', BUT the source location it points to
isn't a call - it's the users original code. Many users may not divine the fact
that loop-idiom replacement occured and end up fruitfully trying to figure out
why assignment to double (the source location pointed to) is a call that cannot
be vectorized. At the very least, the pass remark (emitted from here:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Vectorize/LoopVectorize.cpp#L5422)
could give the name of the function in the function call that could not be
vectorized (which I assume would be something like "memset" or "@llvm.memset"
in this case).
1.) Why is there not a vector version of @llvm.memset in addition to the scalar
version? Is this a problem with the underlying C library on my target (x86
Linux)?
2.) Why does the vectorizer give up when it encounters a scalar function call?
If the function is noexcept, it should be able to take something like this:
// Assume A is an cache-line aligned double* __restrict__
// and N is divisible by some nice number, say 32.
for (ptrdiff_t i = 0; i != N; ++i)
{
double tmp = scalar_noexcept_f(i);
A[i] += B[i] * tmp;
}
And turn it into something like this:
// Assume A is an cache-line aligned double* __restrict__
// and N is divisible by some nice number, say 32.
for (ptrdiff_t i = 0; i != N; i += 8)
{
// Vectorize "around" the scalar call.
__m512d tmp = _mm512_set_pd(
scalar_noexcept_f(i)
, scalar_noexcept_f(i+1)
, scalar_noexcept_f(i+2)
, scalar_noexcept_f(i+3)
, scalar_noexcept_f(i+4)
, scalar_noexcept_f(i+5)
, scalar_noexcept_f(i+6)
, scalar_noexcept_f(i+7)
);
_mm512_store_pd(
A + i
, _mm512_fmadd_pd(
_mm512_load_pd(A + i)
, _mm512_load_pd(B + i)
, tmp
)
);
}
3.) Why isn't loop-idiom recognition "nested loop aware"? In this case, my
nested loops could be turned into a single memset.
--
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
