[llvm-bugs] [Bug 50325] New: clang crash in llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp:1536: bool (anonymous namespace)::LSRUse::InsertFormula(const (anonymous namespace)::Formula &, const llvm
https://bugs.llvm.org/show_bug.cgi?id=50325
Bug ID: 50325
Summary: clang crash in
llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp:1536
: bool (anonymous
namespace)::LSRUse::InsertFormula(const (anonymous
namespace)::Formula &, const llvm::Loop &): Assertion
`F.isCanonical(L) && "Invalid canonical
representation"' failed
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hi all,
This program makes clang (only the trunk version) crash under -O3. The crash
file is the same as bug 49697 but with a different line, and I am not sure if
they are caused by the same issue. From the assertion and the stack
information, I don't think they are the same bugs.
$cat small.c
#include
int a, b, c, d, e;
void f() {
e = 30;
for (; e <= 37; e++) {
{
uint8_t *g = &a;
for (d = 3; d;)
d = *g -= c;
{
uint16_t *i = b;
uint8_t *j = &a;
if (*j -= *i) {
int32_t k;
for (c = 0; k;)
;
}
}
}
uint8_t *g = &a;
for (d = 3; d;)
d = *g -= c;
}
e = 30;
for (; e <= 37; e++) {
{
uint8_t *g = &a;
for (d = 3; d;)
d = *g -= c;
{
uint16_t *i = b;
uint8_t *j = &a;
if (*j -= *i) {
int32_t k;
for (c = 0; k;)
;
}
}
}
}
}
$clang -w -O3 small.c
clang-13:
/home/tuhaoxin/compilers/llvm-project/llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp:1536:
bool (anonymous namespace)::LSRUse::InsertFormula(const (anonymous
namespace)::Formula &, const llvm::Loop &): Assertion `F.isCanonical(L) &&
"Invalid canonical representation"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments:
/home/tuhaoxin/compilers/llvm-project/build/bin/clang-13 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj --mrelax-relocations -disable-free
-main-file-name small.c -mrelocation-model static -mframe-pointer=none
-fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb
-fcoverage-compilation-dir=/home/tuhaoxin/dut-research/covsmith-test
-resource-dir /home/tuhaoxin/compilers/llvm-project/build/lib/clang/13.0.0
-c-isystem /usr/local/include/csmith-2.4.0 -cxx-isystem
/usr/local/include/csmith-2.4.0 -internal-isystem
/home/tuhaoxin/compilers/llvm-project/build/lib/clang/13.0.0/include
-internal-isystem /usr/local/include -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O3
-w -fdebug-compilation-dir=/home/tuhaoxin/dut-research/covsmith-test
-ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops
-vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/small-015664.o
-x c small.c
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'small.c'.
4. Running pass 'Loop Pass Manager' on function '@f'
5. Running pass 'Loop Strength Reduction' on basic block '%for.cond1.2'
#0 0x02a8bbd3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/tuhaoxin/compilers/llvm-project/build/bin/clang-13+0x2a8bbd3)
#1 0x02a8991e llvm::sys::RunSignalHandlers()
(/home/tuhaoxin/compilers/llvm-project/build/bin/clang-13+0x2a8991e)
#2 0x02a8bf5f SignalHandler(int) Signals.cpp:0:0
#3 0x7f04664f63c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x7f0465f8b18b raise
/build/glibc-eX1tMB/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f0465f6a859 abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f0465f6a729 get_sysdep_segment_value
/build/glibc-eX1tMB/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f0465f6a729 _nl_load_domain
/build/glibc-eX1tMB/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f0465f7bf36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
#9 0x028a45c3 (anonymous
namespace)::LSRInstance::InsertFormula((anonymous namespace)::LSRUse&, unsigned
int, (anonymous namespace)::Formula const&) LoopStrengthReduce.cpp:0:0
#10 0x028948bc (anonymous
namespace)::LSRInstance::GenerateAllReuseFormulae() LoopStrengthReduce.cpp:0:0
#11 0x0288fcf3 (anonymous
namespace)::LSRInstance::LSRInstance(llvm::Loop*, llvm::IVUsers&,
llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::LoopInfo&,
llvm::Target
[llvm-bugs] [Bug 50326] New: [clang-format] AlignAfterOpenBracket AlwaysBreak does not keep to the ColumnLimit
https://bugs.llvm.org/show_bug.cgi?id=50326
Bug ID: 50326
Summary: [clang-format] AlignAfterOpenBracket AlwaysBreak does
not keep to the ColumnLimit
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: mydeveloper...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
With a .clang-format of
Language:Cpp
BasedOnStyle: LLVM
AlignAfterOpenBracket: AlwaysBreak
...
The follow file does not break the last line (foo4) at the ColumnLimit
--
void bar()
{
size_t foo1 = function(F, Bar, F, Ba, FoLong);
size_t foo2 = function(
F, Bar, F, Ba, FoLong, BaLong,
FoLong);
size_t foo3 = (*(function))(F, Bar, F, FoLong);
size_t foo4 = (*(
function))(F, Bar, F, Ba, FoLong,
BaLong, FoLong);
}
--
It fees like the correct should be
--
void bar()
{
size_t foo = function(F, Bar, F, Ba, FoLong);
size_t foo = function(
F, Bar, F, Ba, FoLong, BaLong,
FoLong);
size_t foo = (*(function))(F, Bar, F, FoLong);
size_t foo = (*(
function))(F, Bar, F, Ba, FoLong,
BaLong, FoLong);
}
--
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46621] [X86][AVX] Avoid vpsrlq $32, %xmm, %xmm split in v4u64 uint2fp v4f64
https://bugs.llvm.org/show_bug.cgi?id=46621 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||fb1d61b7257ccd5ba0c96bcea78 ||d6516384ce5b6 --- Comment #1 from Simon Pilgrim --- https://godbolt.org/z/4docGfYEK Fixed at rGfb1d61b7257ccd5ba0c96bcea78d6516384ce5b6 cvt_v4u64_v4f64: vxorps %xmm1, %xmm1, %xmm1 vblendps $170, %ymm1, %ymm0, %ymm2 # ymm2 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7] vshufps $221, %ymm1, %ymm0, %ymm0 # ymm0 = ymm0[1,3],ymm1[1,3],ymm0[5,7],ymm1[5,7] vorps .LCPI0_0(%rip), %ymm2, %ymm2 vpermilps $216, %ymm0, %ymm0 # ymm0 = ymm0[0,2,1,3,4,6,5,7] vorps .LCPI0_1(%rip), %ymm0, %ymm0 vsubpd .LCPI0_2(%rip), %ymm0, %ymm0 vaddpd %ymm0, %ymm2, %ymm0 retq -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50327] New: Incorrect call frame info on X86_64 target
https://bugs.llvm.org/show_bug.cgi?id=50327
Bug ID: 50327
Summary: Incorrect call frame info on X86_64 target
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: djordje.todoro...@syrmia.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
$ cat test.c
#include
int f2(char *input) { return crasher(input, 1); }
int crasher(char *input, int crash) {
if (crash)
input = NULL;
input[0] = '1';
input[1] = '2';
input[2] = '3';
input[3] = '\0';
f2(input);
if (crash)
return 0;
else
return 1;
}
int f1() {
char *input = (char *)malloc(sizeof(char) * 10);
return crasher(input, 0);
}
int main(int argc, char **argv) {
f1();
return 0;
}
This small example when compiled with -O1 produces call frame info that causes
incorrect backtrace in GDB.
$ clang -O1 test.c -o test
$ ./test
Segmentation fault (core dumped)
$ lldb test -c core.test
...
(lldb) bt
* thread #1, name = 'test', stop reason = signal SIGSEGV
* frame #0: 0x00401156 test`f2 + 6
frame #1: 0x0040116c test`crasher + 12
frame #2: 0x0040115b test`f2 + 11
frame #3: 0x0040116c test`crasher + 12
frame #4: 0x0040115b test`f2 + 11
frame #5: 0x0040116c test`crasher + 12
frame #6: 0x0040115b test`f2 + 11
frame #7: 0x0040116c test`crasher + 12
frame #8: 0x0040115b test`f2 + 11
frame #9: 0x0040116c test`crasher + 12
frame #10: 0x0040115b test`f2 + 11
frame #11: 0x0040116c test`crasher + 12
frame #12: 0x0040115b test`f2 + 11
frame #13: 0x0040116c test`crasher + 12
...
With gcc, it looks ok:
$ gcc -O1 test.c -o test-gcc
$ ./test-gcc
Segmentation fault (core dumped)
$ lldb ./test-gcc -c core.test-gcc
...
(lldb) bt
* thread #1, name = 'test-gcc', stop reason = signal SIGSEGV
* frame #0: 0x0040115b test-gcc`crasher + 14
frame #1: 0x0040118c test-gcc`f2 + 19
frame #2: 0x0040116f test-gcc`crasher + 34
frame #3: 0x004011ac test-gcc`f1 + 27
frame #4: 0x004011bf test-gcc`main + 14
frame #5: 0x7fea1df1c555 libc.so.6`__libc_start_main + 245
frame #6: 0x00401089 test-gcc`_start + 41
This has been reproduced with x86_64 GNU/Linux platform.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50328] New: clang12 fails to compile from Gcc 11.1
https://bugs.llvm.org/show_bug.cgi?id=50328 Bug ID: 50328 Summary: clang12 fails to compile from Gcc 11.1 Product: clang Version: 12.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: flo...@signbit.net CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Note: this bug has the same summary as https://bugs.llvm.org/show_bug.cgi?id=46746 but a whole different presentation. The following source file fails to build with Clang12 when using libstdc++ from Gcc11.0: -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< #include -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< -- 8< Here's the shell session: $ g++-11 -v Using built-in specs. COLLECT_GCC=g++-11 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.1.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-2V7zgg/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-2V7zgg/gcc-11-11.1.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~20.04) $ /tools/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04/bin/clang++ -v clang version 12.0.0 (https://github.com/llvm/llvm-project/ b978a93635b584db380274d7c8963c73989944a1) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /tools/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04/bin Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11 Candidate multilib: .;@m64 Selected multilib: .;@m64 $ /tools/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04/bin/clang++ -std=c++20 -c clang12_ranges.cpp In file included from clang12_ranges.cpp:1: /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ranges:3392:19: error: missing 'typename' prior to dependent type name 'iterator_traits>::iterator_category' using _Cat = iterator_traits>::iterator_category; ^ 1 error generated. The same translation unit compiles fine if I force clang to use a Gcc10.3 based toolchain. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49338] [AMDGPU][MC][DOC] Correct description of s_sendmsg* instructions
https://bugs.llvm.org/show_bug.cgi?id=49338 Dmitry changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dmitry --- *** This bug has been marked as a duplicate of bug 49648 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42235] [docs] Add remaining short options to help text
https://bugs.llvm.org/show_bug.cgi?id=42235 Owen Reynolds changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||gbrey...@gmail.com Fixed By Commit(s)||c74176ee31fad6ccaa1d8771be2 ||cc2b7e9fa988a --- Comment #1 from Owen Reynolds --- This was fixed by c74176ee31fad6ccaa1d8771be2cc2b7e9fa988a. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50145] [InstructionCombiner (?)] WRONG CODE involving @llvm.vector.reduce.xor
https://bugs.llvm.org/show_bug.cgi?id=50145 Nikita Popov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Nikita Popov --- The aforementioned patch has landed, and the select -> and fold no longer happens in Eli's example: https://llvm.godbolt.org/z/avEdha63o So I believe this is fixed 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50329] New: [C++4OpenCL] Constructor address space overloading not prioritizing specific address spaces
https://bugs.llvm.org/show_bug.cgi?id=50329
Bug ID: 50329
Summary: [C++4OpenCL] Constructor address space overloading not
prioritizing specific address spaces
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: olemarius.str...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
struct Foo {
int x;
Foo() __generic = default;
Foo() __private = default;
};
kernel void k() {
__private Foo f;
}
https://godbolt.org/z/nGrdPacWY
This gives the error: call to constructor of '__private Foo' is ambiguous
But since __private is more specific than __generic this should choose Foo()
__private as it is the most specific constructor, rather than consider them
equally specific.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50267] DAG combine misses to check address space when eliminating store
https://bugs.llvm.org/show_bug.cgi?id=50267 Hendrik Greving changed: What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 34198 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in clang::Sema::PushBlockScope
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 34198 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in clang::Sema::PushBlockScope https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34198#c1 ClusterFuzz testcase 4604460925059072 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202105120607:202105130607 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50330] New: -ansi is not equivalent to -std=c89 when it comes to linking
https://bugs.llvm.org/show_bug.cgi?id=50330
Bug ID: 50330
Summary: -ansi is not equivalent to -std=c89 when it comes to
linking
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: pub...@timruffing.de
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Test case:
Setup:
# echo "int main(void){return 0;}" > test.c
# clang -c -o test.o test.c
Now this just works fine:
# clang -std=c89 -o test test.o
But this outputs a warning:
# clang -ansi -o test test.o
clang-11: warning: argument unused during compilation: '-ansi'
[-Wunused-command-line-argument]
The man page describes -ansi as "Same as -std=c89."
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 34087 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::getPrimaryContext
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 34087 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::getPrimaryContext https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34087#c1 ClusterFuzz testcase 5353192239005696 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202105120607:202105130607 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50331] New: clang spend relative much time on a simple code at -O3 (affect clang-6.0 above versions)
https://bugs.llvm.org/show_bug.cgi?id=50331
Bug ID: 50331
Summary: clang spend relative much time on a simple code at -O3
(affect clang-6.0 above versions)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hi all.
As the title shows, clang-6.0 upwards versions spend much time (exceeded my
expectation) to compile the following simple C code. Is this a latent
performance bug existing for many years or it's just the intention of LLVM? If
it's the intention of LLVM, I apologize for the invalid report, and please
close it asap.
$cat small.c
#include
int a;
void b() {
int16_t *c;
uint8_t d;
int16_t e = 1;
int64_t f;
for (;; c++)
for (d = 30; d <= 63; d++)
for (f = -19; f <= 87; f++)
*c += e ^= a;
}
I tested the following versions on my machine:
$time clang-trunk -w -O3 small.c
real0m15.075s
user0m14.764s
sys 0m0.310s
$time clang-12 -w -O3 small.c
real0m20.437s
user0m20.080s
sys 0m0.289s
$time clang-11 -w -O3 small.c
real0m25.627s
user0m21.636s
sys 0m0.425s
$time clang-10 -w -O3 small.c
real0m28.128s
user0m24.602s
sys 0m0.423s
$time clang-6.0 -w -3 small.c
real0m14.500s
user0m14.240s
sys 0m0.243s
And reproduced in Godbolt: https://godbolt.org/z/KjfEdax7b
(Output is "Killed - processing time exceeded" on clang-6.0 above versions)
Thanks,
Haoxin
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 27686 in oss-fuzz: llvm: Fuzzing build failure
Comment #29 on issue 27686 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27686#c29 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-8dff61a5-5628-4891-b6fb-62584a666552.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50147] missing mflr/mtlr (link register save/restore) when using inline asm w/ "lr" clobber
https://bugs.llvm.org/show_bug.cgi?id=50147 Nathan Chancellor changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||15051f0b4a2e0a0af9da7cd5e5c ||faabb9f6aaa3d --- Comment #4 from Nathan Chancellor --- https://reviews.llvm.org/rG15051f0b4a2e0a0af9da7cd5e5cfaabb9f6aaa3d Tom, could you please make sure this gets applied to release/12.x? I have verified that the issue that was initially reported is resolved and all the tests pass. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 50147, which changed state. Bug 50147 Summary: missing mflr/mtlr (link register save/restore) when using inline asm w/ "lr" clobber https://bugs.llvm.org/show_bug.cgi?id=50147 What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=49317 Bug 49317 depends on bug 50147, which changed state. Bug 50147 Summary: missing mflr/mtlr (link register save/restore) when using inline asm w/ "lr" clobber https://bugs.llvm.org/show_bug.cgi?id=50147 What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50332] New: Incorrect g_tls_size type
https://bugs.llvm.org/show_bug.cgi?id=50332
Bug ID: 50332
Summary: Incorrect g_tls_size type
Product: compiler-rt
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: asan
Assignee: unassignedb...@nondot.org
Reporter: hjl.to...@gmail.com
CC: llvm-bugs@lists.llvm.org
When compiling for -mx32, I got
../../../../../src-master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp:
In function ??void __sanitizer::InitTlsSize()??:
../../../../../src-master/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp:209:55:
error: invalid conversion from ??__sanitizer::uptr*?? {aka ??long unsigned
int*??} to ??size_t*?? {aka ??unsigned int*??} [-fpermissive]
209 | ((void (*)(size_t *, size_t *))get_tls_static_info)(&g_tls_size,
&tls_align);
| ^~~
| |
|
__sanitizer::uptr* {aka long unsigned int*}
I am testing:
diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
index da19d3d2ceb..4f9577a97e2 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
@@ -197,7 +197,7 @@ __attribute__((unused)) static bool GetLibcVersion(int
*major, int *minor,
__attribute__((unused)) static int g_use_dlpi_tls_data;
#if SANITIZER_GLIBC && !SANITIZER_GO
-__attribute__((unused)) static uptr g_tls_size;
+__attribute__((unused)) static size_t g_tls_size;
void InitTlsSize() {
int major, minor, patch;
g_use_dlpi_tls_data =
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50333] New: array shaping not accepted in target update to/from clause
https://bugs.llvm.org/show_bug.cgi?id=50333
Bug ID: 50333
Summary: array shaping not accepted in target update to/from
clause
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: OpenMP
Assignee: unassignedclangb...@nondot.org
Reporter: michael.p.r...@intel.com
CC: llvm-bugs@lists.llvm.org
The array_shaping.1.c example from
https://www.openmp.org/wp-content/uploads/openmp-examples-5-0-1.pdf (p. 50)
does not compile with clang.
This seems to be explicitly allowed in page 208, line 15 of the 5.1
specification.
void array_shaping(double *a, int nx, int ny)
{
// map data to device and do work
#pragma omp target data map(a[0:nx*(ny+2)])
{
#pragma omp target update from( (([nx][ny+2])a)[0:nx][1], \
(([nx][ny+2])a)[0:nx][ny] )
}
}
$ clang -c -fopenmp t.c
t.c:6:39: error: OpenMP array shaping operation is not allowed here
#pragma omp target update from( (([nx][ny+2])a)[0:nx][1], \
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50334] New: Loosing optimization for X % C == 0
https://bugs.llvm.org/show_bug.cgi?id=50334
Bug ID: 50334
Summary: Loosing optimization for X % C == 0
Product: libraries
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: cassio.n...@gmail.com
CC: llvm-bugs@lists.llvm.org
Since version 9, the code generated for say, y % 400 == 0, uses the modular
inverse optimisation which performs just one multiplication (as opposed to two
as it used to do in (y/400)*400 == y).
However, in a reasonable implementation of is_leap_year the code generated
looses the optimisation and falls back to the old implementation. Here are C++
and corresponding assembly. (Notice that for y % 100 it has no issue in
applying the optimisation.)
auto is_leap_year(unsigned y) {
return y % 100 != 0 ? y % 4 == 0 : y % 400 == 0;
}
is_leap_year(unsigned int): # @is_leap_year(unsigned int)
imull $-1030792151, %edi, %eax # imm = 0xC28F5C29
rorl $2, %eax
cmpl $42949673, %eax # imm = 0x28F5C29
jb .LBB2_2
andl $3, %edi
testl %edi, %edi
sete %al
retq
.LBB2_2:
movl %edi, %eax
imulq $1374389535, %rax, %rax # imm = 0x51EB851F
shrq $39, %rax
imull $400, %eax, %eax # imm = 0x190 # <--- Multiplication by 400
subl %eax, %edi
testl %edi, %edi
sete %al
retq
Worse, when y has type type it doesn't even apply the old Granlund and
Montgomery optimisation and resorts to an idiv instruction. It seems it prefers
avoiding branching (using cmov). I doubt this is a good idea.
auto is_leap_year(int y) {
return y % 100 != 0 ? y % 4 == 0 : y % 400 == 0;
}
is_leap_year(int): # @is_leap_year(int)
movl %edi, %eax
imull $-1030792151, %edi, %ecx # imm = 0xC28F5C29
addl $85899344, %ecx # imm = 0x51EB850
rorl $2, %ecx
cmpl $42949673, %ecx # imm = 0x28F5C29
movl $400, %ecx # imm = 0x190
movl $4, %esi
cmovbl %ecx, %esi
cltd
idivl %esi # <-- Division by %esi which contains either 4 or 400
testl %edx, %edx
sete %al
retq
See the above and other relevant code here:
https://godbolt.org/z/zdGPTT83q
You might also be interested in these (non scientific) benchmarks:
https://quick-bench.com/q/zQp1vXKKpWFvH0Et7nxG6MHnNfI
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50332] Incorrect g_tls_size type
https://bugs.llvm.org/show_bug.cgi?id=50332 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from H.J. Lu --- Fixed by commit 72797dedb720fae22682fc884cbf741c5a2066c2 Author: H.J. Lu Date: Thu May 13 18:07:11 2021 -0700 [sanitizer] Use size_t on g_tls_size to fix build on x32 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50336] New: cubin files not cleaned up after linking
https://bugs.llvm.org/show_bug.cgi?id=50336 Bug ID: 50336 Summary: cubin files not cleaned up after linking Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: xw111lu...@gmail.com CC: llvm-bugs@lists.llvm.org tons of cubin files constantly fill /tmp ... -rw-rw-r-- 1 yeluo yeluo 39056 May 13 15:22 RPAJastrow-6b9e81.cubin -rw-rw-r-- 1 yeluo yeluo 39056 May 13 15:22 eeI_JastrowBuilder-f4a8b1.cubin ... I think these files are created when object files are unbundled for linking but never got removed from disk up completion. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50337] New: Concept subsumption broken with constrained + unconstrained parameter with terse syntax
https://bugs.llvm.org/show_bug.cgi?id=50337
Bug ID: 50337
Summary: Concept subsumption broken with constrained +
unconstrained parameter with terse syntax
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: davidfromonl...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following valid translation unit:
```
template
concept foo = true;
template
concept foo2 = foo and true;
void f(foo auto, auto) {
}
void f(foo2 auto, auto) {
}
void f() {
f(1, 1);
}
```
is rejected with
```
:13:2: fatal error: call to 'f' is ambiguous
f(1, 1);
^
:7:6: note: candidate function [with auto:1 = int, auto:2 = int]
void f(foo auto, auto) {
^
:9:6: note: candidate function [with auto:1 = int, auto:2 = int]
void f(foo2 auto, auto) {
^
1 error generated.
Compiler returned: 1
```
This was broken in a recent commit (past couple of days). It's fine with
46c17429bc86dc5ccddb5512b77bd1ede39c9ccd but fails with
72797dedb720fae22682fc884cbf741c5a2066c2.
See it live: https://godbolt.org/z/EaGMs8dhT
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50338] New: Wrong code generated with -fslp-vectorize
https://bugs.llvm.org/show_bug.cgi?id=50338
Bug ID: 50338
Summary: Wrong code generated with -fslp-vectorize
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: k...@google.com
CC: llvm-bugs@lists.llvm.org
I'm seeing a miscompilation triggered by -flp-vectorize, much like
PR50323. Unlike PR50323, this one is reproducible as of the latest
clang as of c82a0ae70e280c1c40b1af09ef275ddc7ed4254d.
Consider:
#include
#include
struct Float64x8 {
__m256d ymm_lo;
__m256d ymm_hi;
};
static inline double ExtractFloat64x8(Float64x8 a, int index) {
return (index < 4) ? a.ymm_lo[index] : a.ymm_hi[index - 4];
}
// This function appears to be miscompiled.
__attribute__((noinline)) __m256d Permute(Float64x8 a, __m256i map) {
double result[4];
for (int i = 0; i < 4; ++i)
result[i] = ExtractFloat64x8(a, map[i] & 0x7);
return _mm256_loadu_pd(result);
}
int main() {
Float64x8 v;
v.ymm_lo = _mm256_set_pd(3.0, 2.0, 1.0, 0.0);
v.ymm_hi = _mm256_set_pd(7.0, 6.0, 5.0, 4.0);
__m256d r = Permute(v, _mm256_set_epi64x(1, 0, 0, 0));
fprintf(stderr, "%f %f %f %f\n", r[3], r[2], r[1], r[0]);
return 0;
}
With the latest clang (c82a0ae70e280c1c40b1af09ef275ddc7ed4254d), I see:
$ ./debug/bin/clang++ -O3 -mavx -fno-slp-vectorize permute2.cc ; ./a.out
1.00 0.00 0.00 0.00
$ ./debug/bin/clang++ -O3 -mavx -fslp-vectorize permute2.cc ; ./a.out
0.00 2.00 0.00 0.00
Notice that the top two lanes are different. The former output is
correct. The latter is not.
Here is the assembly output for Permute with -fslp-vectorize:
.text
.file "permute2.cc"
.section.rodata.cst16,"aM",@progbits,16
.p2align4 # -- Begin function
_Z7Permute9Float64x8Dv4_x
.LCPI0_0:
.long 7 # 0x7
.long 7 # 0x7
.zero 4
.zero 4
.LCPI0_1:
.long 4 # 0x4
.long 4 # 0x4
.zero 4
.zero 4
.section.rodata.cst32,"aM",@progbits,32
.p2align5
.LCPI0_2:
.quad 2 # 0x2
.quad 2 # 0x2
.quad 2 # 0x2
.quad 2 # 0x2
.text
.globl _Z7Permute9Float64x8Dv4_x
.p2align4, 0x90
.type _Z7Permute9Float64x8Dv4_x,@function
_Z7Permute9Float64x8Dv4_x: # @_Z7Permute9Float64x8Dv4_x
.cfi_startproc
# %bb.0:# %entry
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
andq$-32, %rsp
subq$96, %rsp
vpextrd $2, %xmm0, %eax
movl%eax, %edx
andl$7, %edx
leal-4(%rdx), %ecx
andl$3, %eax
vmovaps 16(%rbp), %ymm1
vmovaps 48(%rbp), %ymm2
vmovaps %ymm1, 32(%rsp)
vmovsd 32(%rsp,%rax,8), %xmm1 # xmm1 = mem[0],zero
vmovd %xmm0, %eax
vmovaps %ymm2, (%rsp)
cmpl$4, %edx
jb .LBB0_2
# %bb.1:# %entry
andl$3, %ecx
vmovsd (%rsp,%rcx,8), %xmm1# xmm1 = mem[0],zero
.LBB0_2:# %entry
movl%eax, %ecx
andl$7, %ecx
subl$4, %ecx
jb .LBB0_3
# %bb.4:# %entry
andl$3, %ecx
vmovsd (%rsp,%rcx,8), %xmm2# xmm2 = mem[0],zero
jmp .LBB0_5
.LBB0_3:
andl$3, %eax
vmovsd 32(%rsp,%rax,8), %xmm2 # xmm2 = mem[0],zero
.LBB0_5:# %entry
vmovlhps%xmm1, %xmm2, %xmm1 # xmm1 =
xmm2[0],xmm1[0]
vextractf128$1, %ymm0, %xmm0
vpshufd $216, %xmm0, %xmm2 # xmm2 = xmm0[0,2,1,3]
vpand .LCPI0_0(%rip), %xmm2, %xmm2
vmovd %xmm0, %eax
addl$-4, %eax
vpmaxud .LCPI0_1(%rip), %xmm2, %xmm3
andl$3, %eax
vpcmpeqd%xmm3, %xmm2, %xmm3
vpcmpeqd%xmm4, %xmm4, %xmm4
vpxor %xmm4, %xmm3, %xmm3
vpextrd $2, %xmm0, %ecx
addl$-4, %ecx
vpaddq %xmm2, %xmm2, %xmm0
vmovapd 16(%rbp), %xmm2
vmovapd 32(%rbp), %xmm4
vpermilpd %xmm0, %xmm4, %xmm4
vpermilpd %xmm0, %xmm2, %xmm2
vpcmpgtq.LCPI0_2(%rip), %xmm0, %xmm0
vblendvpd %xmm0, %xmm4, %xmm2, %
