[llvm-bugs] [Bug 43554] New: Add a new option to ignore undefined symbols in DSO
https://bugs.llvm.org/show_bug.cgi?id=43554 Bug ID: 43554 Summary: Add a new option to ignore undefined symbols in DSO Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org lld used to ignore undefined symbols in DSOs, but I changed that behavior in https://reviews.llvm.org/rL325849 to improve compatibility with GNU linkers. That resulted in an unintended consequence on Android. First, let me explain why I made lld to try to resolve undefined symbols in DSO. The current lld's behavior is as follows. 1. When you are creating a DSO, Unix linkers traditionally allow undefined symbols to remain. Remaining undefined symbols from input object files are left as undefined symbols in a DSO. 2. When you are creating an executable, Unix linkers traditionally try to resolve all undefined symbols for all input files including DSOs. Undefined symbols in DSOs that cannot be resolved by any other DSOs or by a main executable are usually detected at this stage. If the linker doesn't do this, such undefined symbols would be detected at dynamic-link time (i.e. you can't find them until you try to run a program), which is much more inconvenient. I think the above (1) and (2) are coherent and make sense. Being said that, that doesn't seems like the only approach that make sense. Think about the following feature combination. 3. Do not allow undefined symbols in DSOs. This can be achieved by passing `--no-undefined` option to the linker along with `--shared`. 4. Do not try to resolve undefined symbols in DSOs when creating an executable, assuming all DSO undefined symbols will be resolved successfully at runtime. It seems (3) and (4) are also coherent and make sense. On Android, `--no-undefined` is actually always passed to the linker. So, on Android, we don't have to try to resolve DSO undefined symbols at link-time. The problem is that it seems like we don't have an option to achieve (4)'s behavior. Maybe we should add a new option for that. What do you think? -- 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 43555] New: crash when using "-ftime-trace" and "-o /dev/null"
https://bugs.llvm.org/show_bug.cgi?id=43555
Bug ID: 43555
Summary: crash when using "-ftime-trace" and "-o /dev/null"
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: mbear...@mathworks.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 22626
--> https://bugs.llvm.org/attachment.cgi?id=22626&action=edit
Preprocessed source(s) and associated run script(s)
The following clang command crashes:
$ clang-9 -o /dev/null -c -ftime-trace tiny.cpp
tiny.cpp contents are as follows (the actual program doesn't matter)
int foo();
int foo() {
return 5;
}
clang output/stack/etc:
$ clang-9 -o /dev/null -c -ftime-trace tiny.cpp
error: unable to open output file '/dev/null.json': 'Permission denied'
Stack dump:
0. Program arguments:
/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name tiny.cpp
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file
/dev/null.gcno -resource-dir
/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/lib/clang/9.0.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/x86_64-linux-gnu/c++/6.3.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/x86_64-linux-gnu/c++/6.3.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/backward
-internal-isystem /usr/local/include -internal-isystem
/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/lib/clang/9.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /home/mbeardsl/Desktop/cpp/cpp
-ferror-limit 19 -fmessage-length 0 -ftime-trace -fobjc-runtime=gcc
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-faddrsig -o /dev/null -x c++ tiny.cpp
#0 0x02087814 PrintStackTraceSignalHandler(void*)
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x2087814)
#1 0x020856ce llvm::sys::RunSignalHandlers()
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x20856ce)
#2 0x02087c08 SignalHandler(int)
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x2087c08)
#3 0x7f2a6c6da0c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#4 0x0208d2ba llvm::json::OStream::objectBegin()
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x208d2ba)
#5 0x02057e27 llvm::TimeTraceProfiler::Write(llvm::raw_pwrite_stream&)
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x2057e27)
#6 0x009e3dbb cc1_main(llvm::ArrayRef, char const*,
void*)
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x9e3dbb)
#7 0x009e1f5f main
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x9e1f5f)
#8 0x7f2a6b25d2b1 __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b1)
#9 0x009df129 _start
(/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang-9+0x9df129)
clang-9: error: unable to execute command: Segmentation fault
clang-9: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 9.0.0 (https://github.com/llvm-mirror/llvm
c62b24f070c9a4bb1a76409e623042a740cac4cd)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
/home/mbeardsl/clang9/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/bin
clang-9: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.llvm.org/ and include the crash backtrace, preprocessed source,
and associated run script.
clang-9: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-9: note: diagnostic msg: /tmp/tiny-95ec21.cpp
clang-9: note: diagnostic msg: /tmp/tiny-95ec21.sh
clang-9: note: diagnostic msg:
clang's generated files "/tmp/tiny-95ec21.cpp" and "/tmp/tiny-95ec21.sh" are
attached in clang_generated_repro_files.zip
When giving any real (non-/dev/null) file name for "-o", everything works of
course
--
You are receivi
[llvm-bugs] [Bug 43556] New: Auto type deduction of member variable template within class template fails to compile
https://bugs.llvm.org/show_bug.cgi?id=43556
Bug ID: 43556
Summary: Auto type deduction of member variable template within
class template fails to compile
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: ja...@invexed.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
https://godbolt.org/z/cGowWI
The following code fails to compile with Clang (but is accepted by GCC and
MSVC)
template
struct S {
template
static constexpr auto value = T{0};
};
int main()
{
return S::value;
}
This can be resolved by explicitly specifying the type of S::value instead:
template
static constexpr T value = T{0};
Furthermore, this bug only seems to occur if S and S::value are both templates.
--
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 43557] New: __builtin_constant_p returns 1 instead of 0 when there is a side effect
https://bugs.llvm.org/show_bug.cgi?id=43557
Bug ID: 43557
Summary: __builtin_constant_p returns 1 instead of 0 when there
is a side effect
Product: new-bugs
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: vincent-l...@vinc17.net
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
If the value of __builtin_constant_p is constant, 1 is returned even when there
is a side effect. This is a regression in Clang 9.
Testcase:
#include
int main (void)
{
int c, i = 0;
c = __builtin_constant_p ((i++, 0));
printf ("%d %d\n", c, i);
return 0;
}
which outputs "1 0" instead of "0 0" with:
clang version 9.0.0-1 (tags/RELEASE_900/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
(Debian package clang-9 1:9-1).
Note: This makes one test of GNU MPFR fail (tcmp_ui) and can affect code using
MPFR, when this user code is built with Clang 9.
--
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 43558] New: Compiled with clang-cl -fsanitize=address /MD std::strtol does not change errno correctly
https://bugs.llvm.org/show_bug.cgi?id=43558
Bug ID: 43558
Summary: Compiled with clang-cl -fsanitize=address /MD
std::strtol does not change errno correctly
Product: clang
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: predel...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following example prints 0 if both -fsanitize=address and /MD are passed as
arguments:
#include
#include
int main ()
{
char *eptr;
auto value = std::strtol ("9", &eptr,
10);
std::cout << errno << '\n';
}
The correct result is printing 34 (ERANGE)
I have checked that the rest of this funciton family (stdtoul, strtoll,
strtoull, strtof, strtod, strtold) are not affected which makes this problem
strangely specific to strtol.
--
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 43558] Compiled with clang-cl -fsanitize=address /MD std::strtol does not change errno correctly
https://bugs.llvm.org/show_bug.cgi?id=43558 Sergey Semushin changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Sergey Semushin --- Sorry, didn't find that bug was already filed on this, the first time. *** This bug has been marked as a duplicate of bug 35137 *** -- 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 15623 in oss-fuzz: llvm: Build failure
Comment #28 on issue 15623 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15623#c28 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-9f1f8ab7-b80f-476c-b8bf-dcb310691ee1.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 43559] New: Poor codegen for targets with no native shifts
https://bugs.llvm.org/show_bug.cgi?id=43559
Bug ID: 43559
Summary: Poor codegen for targets with no native shifts
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: joan.ll...@icloud.com
CC: llvm-bugs@lists.llvm.org
This is an extension of bug 43542. This is a report of the same issue for the
following functions:
DAGCombiner::SimplifySelectCC
DAGCombiner::foldSelectCCToShiftAnd
static SDValue foldExtendedSignBitTest
Creation of shifts as a replacement of selects or extensions should be avoided
in DAGCombiner if shifts are not efficiently supported by the target.
The following IR functions are originators or the reported issue through
slightly different paths for the MSP430 target:
; Function Attrs: norecurse nounwind readnone
define dso_local i16 @test0(i16 %a) local_unnamed_addr #0 {
entry:
%cmp = icmp slt i16 %a, 0
%cond = select i1 %cmp, i16 -1, i16 0
ret i16 %cond
}
; Function Attrs: norecurse nounwind readnone
define dso_local i16 @test1(i16 %a) local_unnamed_addr #0 {
entry:
%cmp = icmp slt i16 %a, 0
%cond = select i1 %cmp, i16 1, i16 0
ret i16 %cond
}
; Function Attrs: norecurse nounwind readnone
define dso_local i16 @test2(i16 %a) local_unnamed_addr #0 {
entry:
%cmp = icmp slt i16 %a, 0
%cond = select i1 %cmp, i16 2, i16 0
ret i16 %cond
}
; Function Attrs: norecurse nounwind readnone
define dso_local i16 @test3(i16 %a) local_unnamed_addr #0 {
entry:
%cmp = icmp slt i16 %a, 0
%cond = select i1 %cmp, i16 3, i16 0
ret i16 %cond
}
The resulting code for the MSP430 is this, which is suboptimal:
.globl test0
.p2align1
.type test0,@function
test0:
swpbr12
sxt r12
rra r12
rra r12
rra r12
rra r12
rra r12
rra r12
rra r12
ret
.Lfunc_end0:
.size test0, .Lfunc_end0-test0
.globl test1
.p2align1
.type test1,@function
test1:
swpbr12
mov.b r12, r12
clrc
rrc r12
rra r12
rra r12
rra r12
rra r12
rra r12
rra r12
ret
.Lfunc_end1:
.size test1, .Lfunc_end1-test1
.globl test2
.p2align1
.type test2,@function
test2:
swpbr12
mov.b r12, r12
clrc
rrc r12
rra r12
rra r12
rra r12
rra r12
rra r12
and #2, r12
ret
.Lfunc_end2:
.size test2, .Lfunc_end2-test2
.globl test3
.p2align1
.type test3,@function
test3:
swpbr12
sxt r12
rra r12
rra r12
rra r12
rra r12
rra r12
rra r12
rra r12
and #3, r12
ret
.Lfunc_end3:
.size test3, .Lfunc_end3-test3
--
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 43560] New: clang hang in RecursiveTransformLoop() in SemaExprCXX.cpp
https://bugs.llvm.org/show_bug.cgi?id=43560
Bug ID: 43560
Summary: clang hang in RecursiveTransformLoop() in
SemaExprCXX.cpp
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: karl-johan.karls...@ericsson.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
The following code:
- foo.c -
int v_63 ;
void v_2_0(int v_452, int v_454) {}
int v_3_0() {
for (int v_345 = 0 ; v_63;)
v_2_0(v_195, v_231);
}
-
compiled with:
clang -cc1 -triple x86_64-unknown-unknown -S -O0 -Wall -emit-llvm-bc -o - -x c
foo.c
get stuck and never returns from RecursiveTransformLoop().
Note: both 'v_195' and 'v_231' are undeclared identifiers.
Note: if the loop variable 'v_345' is renamed to say 'i' clang will not hang.
--
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 43561] New: Unwind augmentation on x86 is off by one instruction
https://bugs.llvm.org/show_bug.cgi?id=43561
Bug ID: 43561
Summary: Unwind augmentation on x86 is off by one instruction
Product: lldb
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: ja...@google.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
I believe the x86 augmentation of eh_frame info from assembly is broken: it
computes the unwinding info for offset x from instruction at offset x, but
instead it should be computed from the previous instruction (here is the loop
in question:
https://github.com/llvm/llvm-project/blob/c118a03e6945805edc88732a33ff51cc4d96db09/lldb/source/Plugins/UnwindAssembly/x86/x86AssemblyInspectionEngine.cpp#L1381).
Looking back at the history of the file, this was likely introduced by the very
first revision of the file
(https://github.com/llvm/llvm-project/commit/1c9858b298d79ce82c45a2954096718b39550109#diff-375a2be066db6f34bb9a71442c9b71fcL913);
the original version handled this properly by copying the previous instruction
out before advancing the instruction pointer.
It is quite nicely visible in the glibc’s raise function, which has the
following unwinding plan (according to “image show-unwind -a $pc”):
This UnwindPlan originally sourced from eh_frame CFI plus augmentation from
assembly parsing
This UnwindPlan is sourced from the compiler: no.
This UnwindPlan is valid at all instruction locations: yes.
Address range of this UnwindPlan: [libc.so.6..text + 79344-0x000136de)
row[0]:0: CFA=rsp +8 => rip=[CFA-8]
row[1]:1: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[2]: 28: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8] << Comes from
augmentation
row[3]: 35: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]
row[4]: 207: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8] << Comes from
augmentation
row[5]: 214: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[6]: 217: CFA=rsp +8 => rbx=[CFA-16] rip=[CFA-8]
row[7]: 218: CFA=rsp +8 => rbx=[CFA-16] rip=[CFA-8]
row[8]: 224: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]
This is already suspicious because of the duplicate lines. Disassembling
confirms the suspicion: offsets 28 and 207 should be still on their original
unwinding rows.
0x75e94f44: movl $0x8, %r10d
0x75e94f4a: xorl %edi, %edi
0x75e94f4c: subq $0x88, %rsp ;; offset 28
0x75e94f53: leaq -0x78(%rsp), %r9 ;; offset 35
0x75e94f58: movq %rax, 0x8(%rsp)
...
0x75e94ff8: movl $0xe, %eax
0x75e94ffd: syscall
0x75e94fff: addq $0x88, %rsp ;; offset 207
0x75e95006: movl %r8d, %eax;; offset 214
It is worth noting the the eh_frame unwinding info is actually correct:
This UnwindPlan originally sourced from eh_frame CFI
This UnwindPlan is sourced from the compiler: yes.
This UnwindPlan is valid at all instruction locations: no.
Address range of this UnwindPlan: [libc.so.6..text + 79344-0x000136de)
row[0]:0: CFA=rsp +8 => rip=[CFA-8]
row[1]:1: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[2]: 35: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]
row[3]: 214: CFA=rsp+16 => rbx=[CFA-16] rip=[CFA-8]
row[4]: 218: CFA=rsp +8 => rbx=[CFA-16] rip=[CFA-8]
row[5]: 224: CFA=rsp+152 => rbx=[CFA-16] rip=[CFA-8]
Here is my program and the lldb session that shows the missing stack entry for
the SHOULD_BE_ON_STACK function.
--- main.cpp ---
#include
void SHOULD_BE_ON_STACK() {
abort();
}
int main(int argc, char** argv) {
SHOULD_BE_ON_STACK();
}
$ lldb MissingStack
(lldb) target create "MissingStack"
Current executable set to 'MissingStack' (x86_64).
(lldb) r
Process 8262 launched: '/srv/game/assets/MissingStack' (x86_64)
Process 8262 stopped
* thread #1, name = 'MissingStack', stop reason = signal SIGABRT
frame #0: 0x75e94fff libc.so.6`__GI_raise(sig=6) at raise.c:51
(lldb) bt
* thread #1, name = 'MissingStack', stop reason = signal SIGABRT
* frame #0: 0x75e94fff libc.so.6`__GI_raise(sig=6) at raise.c:51
frame #1: 0xfffe7fff
frame #2: 0x00201174 MissingStack`main(argc=1,
argv=0x7fffe5e8) at main.cpp:8
frame #3: 0x75e822e1
libc.so.6`__libc_start_main(main=(MissingStack`main at main.cpp:7), argc=1,
argv=0x7fffe5e8, init=, fini=,
rtld_fini=, stack_end=0x7fffe5d8) at libc-start.c:291
frame #4: 0x0020102a MissingStack`_start + 42
--
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 43562] New: Speed degradation because of inlining a register clobbering function
https://bugs.llvm.org/show_bug.cgi?id=43562
Bug ID: 43562
Summary: Speed degradation because of inlining a register
clobbering function
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: antosh...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Consider the example that is a simplified version of
boost::container::small_vector:
#define MAKE_INLINING_BAD 1
struct vector {
int* data_;
int* capacity_;
int* size_;
void push_back(int v) {
if (capacity_ > size_) {
*size_ = v;
++size_;
} else {
reallocate_and_push(v);
}
}
void reallocate_and_push(int v)
#if MAKE_INLINING_BAD
{
// Just some code that clobbers many registers.
// You may skip reading it
const auto old_cap = capacity_ - data_;
const auto old_size = capacity_ - size_;
const auto new_cap = old_cap * 2 + 1;
auto new_data_1 = new int[new_cap];
auto new_data = new_data_1;
for (int* old_data = data_; old_data != size_; ++old_data, ++new_data)
{
*new_data = *old_data;
}
delete[] data_;
data_ = new_data_1;
size_ = new_data_1 + old_size;
capacity_ = new_data_1 + new_cap;
*size_ = v;
++size_;
}
#else
;
#endif
};
void bad_inlining(vector& v) {
v.push_back(42);
}
With `#define MAKE_INLINING_BAD 0` the generated code is quite good:
bad_inlining(vector&): # @bad_inlining(vector&)
mov rax, qword ptr [rdi + 16]
cmp qword ptr [rdi + 8], rax
jbe .LBB0_2
mov dword ptr [rax], 42
add rax, 4
mov qword ptr [rdi + 16], rax
ret
.LBB0_2:
mov esi, 42
jmp vector::reallocate_and_push(int) # TAILCALL
However, with `#define MAKE_INLINING_BAD 1` the compiler decides to inline the
`reallocate_and_push` function that clobbers many registers. So the compiler
stores the values of those registers on the stack before doing the cmompare and
ja:
bad_inlining(vector&): # @bad_inlining(vector&)
push rbp ; don't need those pushes for the `(capacity_ > size_)` case
push r15
push r14
push r13
push r12
push rbx
push rax
mov r14, rdi
mov r15, qword ptr [rdi + 8]
mov r13, qword ptr [rdi + 16]
mov rbp, r15
sub rbp, r13
ja .LBB0_14 ; hot path that does not clobbers registers
; vector::reallocate_and_push(int) implementation
add rsp, 8
pop rbx ; don't need those pops for the `(capacity_ > size_)` case
pop r12
pop r13
pop r14
pop r15
pop rbp
ret
This greatly degrades the performance of the first branch (more than x3
degradation in real code).
The possible fix would be to place all the push/pop operations near the inlined
`reallocate_and_push`:
bad_inlining(vector&):
mov rax, qword ptr [rdi + 16]
cmp qword ptr [rdi + 8], rax
jbe .LBB0_2
mov dword ptr [rax], 42
add rax, 4
mov qword ptr [rdi + 16], rax
ret
.LBB0_2:
push rbp
push r15
push r14
; ...
; vector::reallocate_and_push(int) implementation goes here
; ...
pop r14
pop r15
pop rbp
ret
Godbolt playground: https://godbolt.org/z/zM9bR0
Related GCC issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--
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 43483] [AMDGPU][MC][GFX10] Incorrect disassembly of FLAT SCRATCH instructions with negative offset
https://bugs.llvm.org/show_bug.cgi?id=43483 Dmitry changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||373736 -- 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 43563] New: clang-cl - llvm-lib fails to link two static libraries together.
https://bugs.llvm.org/show_bug.cgi?id=43563 Bug ID: 43563 Summary: clang-cl - llvm-lib fails to link two static libraries together. Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: gabr...@jadderson.com CC: llvm-bugs@lists.llvm.org Hello, i'm trying to create a program that links to a static library which in turn links to opengl32.lib. I get the following error: opengl32.lib: not a COFF object, bitcode or resource file "llvm-lib.exe" exited with code 1. I am able to do this completely fine with MSVC v142. I am running the latest version of clang-cl included with visual studio. -- 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 43485] [AMDGPU][MC][GFX10] SOP instructions with src0=null cannot be decoded
https://bugs.llvm.org/show_bug.cgi?id=43485 Dmitry changed: What|Removed |Added Fixed By Commit(s)||373740 Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43564] New: [InstCombine] Failure to recognize sign bit test if the high bit extract is followed by trunc
https://bugs.llvm.org/show_bug.cgi?id=43564
Bug ID: 43564
Summary: [InstCombine] Failure to recognize sign bit test if
the high bit extract is followed by trunc
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
https://godbolt.org/z/hzDvD_
Given
int bad(unsigned input, unsigned len) {
unsigned diff = input & ((1 << len)-1);
// If the first bit is 1 we need to turn this into a negative number
if (diff >> (len - 1))
diff -= (1 << len);
return diff;
}
we get
%5 = icmp slt i32 %0, 0
But for
int bad2(unsigned long input, unsigned len) {
unsigned diff = input >> (64 - len);
// If the first bit is 1 we need to turn this into a negative number
if (diff >> (len - 1))
diff -= (1 << len);
return diff;
}
we no longer recognize it, and remain with
%7 = add i32 %1, -1
%8 = lshr i32 %6, %7
%9 = icmp eq i32 %8, 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43484] [AMDGPU][MC][GFX10][WS32] Incorrect disassembly of v_cmp_*_sdwa opcodes
https://bugs.llvm.org/show_bug.cgi?id=43484 Dmitry changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||373745 -- 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 43565] New: Cannot call OpenMP functions from libiomp after calling from libomp
https://bugs.llvm.org/show_bug.cgi?id=43565 Bug ID: 43565 Summary: Cannot call OpenMP functions from libiomp after calling from libomp Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: jeremie.du-boisberran...@inria.fr CC: llvm-bugs@lists.llvm.org Created attachment 22627 --> https://bugs.llvm.org/attachment.cgi?id=22627&action=edit test program Hi, when a program loads both libiomp and libomp with dlopen, calling an OpenMP function from one then from the other one can cause the program to terminate, depending on the order of the calls. calling from libiomp first, then from libomp is fine. The issue is when calling from libomp first and then from libiomp. I attached a reproducing example (test.c) to reproduce: clang test.c -o test -ldl && ./test Error: OMP: Error #13: Assertion failure at z_Linux_util.cpp(2338). OMP: Hint Please submit a bug report with this message, compile and run commands used, and machine configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see http://www.intel.com/software/products/support/. Backtrace: #0 0x7783e428 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7784002a in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x76f7b2c3 in __kmp_abort_process () at ../../src/kmp_runtime.cpp:481 #3 0x76f66237 in __kmp_fatal (message=...) at ../../src/kmp_i18n.cpp:894 #4 0x76f3a82c in __kmp_debug_assert (msg=0x76c5 , file=0x76c5 , line=6) at ../../src/kmp_debug.cpp:100 #5 0x76fb57ee in __kmp_is_address_mapped (addr=0x76c5) at ../../src/z_Linux_util.cpp:2337 #6 0x76f78f87 in __kmp_register_library_startup () at ../../src/kmp_runtime.cpp:6684 #7 0x76f7a49b in _INTERNAL_25___src_kmp_runtime_cpp_ddfed41b::__kmp_do_serial_initialize () at ../../src/kmp_runtime.cpp:6834 #8 _INTERNAL_25___src_kmp_runtime_cpp_ddfed41b::__kmp_do_middle_initialize () at ../../src/kmp_runtime.cpp:7146 #9 __kmp_middle_initialize () at ../../src/kmp_runtime.cpp:7255 #10 0x76f5ad75 in __kmp_api_omp_get_max_threads () at ../../src/kmp_ftn_entry.h:366 #11 0x004006ab in main () Some remarks: - Based on the error message, the issue seems to come from libiomp. I still post here because it's caused by its interaction with libomp (and both are essentially the same). I'll also report it to intel. - Loading libgomp instead of libomp does not raise the error - Include libraries instead of dlopen does not raise the error - I know it's bad practice to load different OpenMP runtimes simultaneously. And in fact I have to set KMP_DUPLICATE_LIB_OK=TRUE otherwise it does not work at all. But in the python ecosystem, you can easily install packages from pre-built binaries and we don't know in advance which compiler has been used. For instance if one package uses MKL and another one uses OpenMP and is built with clang. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43556] Auto type deduction of member variable template within class template fails to compile
https://bugs.llvm.org/show_bug.cgi?id=43556 Erik Pilkington changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Erik Pilkington --- Looks like a duplicate of llvm.org/PR43459 *** This bug has been marked as a duplicate of bug 43459 *** -- 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 17997 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-04 Type: Bug New issue 17997 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17997 Detailed Report: https://oss-fuzz.com/testcase?key=5714241067155456 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b llvm::ConstantExpr::getBitCast FoldBitCast Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=201906300300 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5714241067155456 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 43531] clang-format damages "alternative representations" for operators
https://bugs.llvm.org/show_bug.cgi?id=43531 MyDeveloperDay changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r373750 --- Comment #4 from MyDeveloperDay --- Landed https://reviews.llvm.org/rGba12cec21f55cae6aaae0b57d08cab0de9358d51 -- 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 42417] clang-format inserts a space after '->' for operator->() overloading
https://bugs.llvm.org/show_bug.cgi?id=42417 MyDeveloperDay changed: What|Removed |Added Fixed By Commit(s)||r373746 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from MyDeveloperDay --- Landed in https://reviews.llvm.org/rGa37a6dcd04b0c0a0f9eea93ba0a5070a5421a29a -- 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 43338] [clang-format] C# Missing space after template > in Dictionary foo;
https://bugs.llvm.org/show_bug.cgi?id=43338 MyDeveloperDay changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||r373709 Resolution|--- |FIXED --- Comment #1 from MyDeveloperDay --- Landed in https://reviews.llvm.org/rG4c056583548ab59e2ad24deb2ca30790a290a8e3 -- 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 43333] [clang-format] Functions with C# attributes break before function name
https://bugs.llvm.org/show_bug.cgi?id=4 MyDeveloperDay changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r373707 Status|CONFIRMED |RESOLVED --- Comment #2 from MyDeveloperDay --- Landed https://reviews.llvm.org/rGa2f963bb61e3e83287ea9eecd39198051b0c1cef -- 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 43372] clang-format can't format file with includes
https://bugs.llvm.org/show_bug.cgi?id=43372 MyDeveloperDay changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r373388 --- Comment #18 from MyDeveloperDay --- Landed in https://reviews.llvm.org/rG603650213b1aee2a03ba879ba9d8e6eb65a06694 -- 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 43566] New: Assertion failed: getNumber() >= 0 && "cannot get label for unreachable MBB" when targeting x86_x64 windows
https://bugs.llvm.org/show_bug.cgi?id=43566
Bug ID: 43566
Summary: Assertion failed: getNumber() >= 0 && "cannot get
label for unreachable MBB" when targeting x86_x64
windows
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: mike.winterb...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 22629
--> https://bugs.llvm.org/attachment.cgi?id=22629&action=edit
crash reproducer script
Unfortunately, since I usually just use the pre-built prereleases, I don't know
when this first occurred, aside from sometime between
LLVM-9.0.0-r363781-win64.exe and LLVM-10.0.0-r372920-win64.exe.
The x86_64-pc-linux-gnu and i386-pc-windows-msvc19.16.27034 targets do not
reproduce the assertion. -O0, -O3, -Ofast all do not reproduce the assertion.
All other -O flags do.
> clang.exe --version
clang version 10.0.0 (https://github.com/llvm/llvm-project.git
9588ae772d6a3742e8429d86d65e3fd68f6d9444)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Users\mike.winterberg\llvm\llvm-project\build\bin
>type bob.cc
extern void f1();
extern void f();
void f()
{
bool threw = false;
try {
f1();
} catch (...) {
threw = true;
}
if (threw) {
f1();
return;
}
try {
f1();
} catch (...) {
threw = true;
}
if (threw) {
f1();
return;
}
}
>clang++.exe -target x86_64-pc-windows-msvc19.16.27034 -c -O2 bob.cc
Assertion failed: getNumber() >= 0 && "cannot get label for unreachable MBB",
file
C:\Users\mike.winterberg\llvm\llvm-project\llvm\lib\CodeGen\MachineBasicBlock.cpp,
line 64
Stack dump:
0. Program arguments:
C:\Users\mike.winterberg\llvm\llvm-project\build\bin\clang++.exe -cc1 -triple
x86_64-pc-windows-msvc19.16.27034 -emit-obj -mincremental-linker-compatible
-disable-free -main-file-name bob.cc -mrelocation-model pic -pic-level 2
-mthread-model posix -mframe-pointer=none -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info
-resource-dir C:\Users\mike.winterberg\llvm\llvm-project\build\lib\clang\10.0.0
-internal-isystem
C:\Users\mike.winterberg\llvm\llvm-project\build\lib\clang\10.0.0\include
-internal-isystem C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\ATLMFC\include
-internal-isystem C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\include -internal-isystem
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt
-internal-isystem C:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\shared -internal-isystem C:\Program Files
(x86)\Windows Kits\10\include\10.0.17763.0\um -internal-isystem C:\Program
Files (x86)\Windows Kits\10\include\10.0.17763.0\winrt -internal-isystem
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\cppwinrt -O2
-fdeprecated-macro -fdebug-compilation-dir
C:\Users\mike.winterberg\llvm\llvm-project\build\bin -ferror-limit 19
-fmessage-length 190 -fno-use-cxa-atexit -fms-extensions -fms-compatibility
-fms-compatibility-version=19.16.27034 -std=c++14 -fdelayed-template-parsing
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o bob.o -x c++
bob.cc
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'bob.cc'.
4. Running pass 'X86 Assembly Printer' on function '@"?f@@YAXXZ"'
#0 0x7ff6a0f30ef5 HandleAbort
c:\users\mike.winterberg\llvm\llvm-project\llvm\lib\support\windows\signals.inc:408:0
#1 0x7ffed647da2d (C:\Windows\System32\ucrtbase.dll+0x6da2d)
#2 0x7ffed647e901 (C:\Windows\System32\ucrtbase.dll+0x6e901)
#3 0x7ffed648031a (C:\Windows\System32\ucrtbase.dll+0x7031a)
#4 0x7ffed6480211 (C:\Windows\System32\ucrtbase.dll+0x70211)
#5 0x7ffed6480591 (C:\Windows\System32\ucrtbase.dll+0x70591)
#6 0x7ff6a035f8e3 llvm::MachineBasicBlock::getSymbol(void)const
c:\users\mike.winterberg\llvm\llvm-project\llvm\lib\codegen\machinebasicblock.cpp:64:0
#7 0x7ff69fd28929 `anonymous
namespace'::X86MCInstLower::GetSymbolFromOperand
c:\users\mike.winterberg\llvm\llvm-project\llvm\lib\target\x86\x86mcinstlower.cpp:151:0
#8 0x7ff69fd2aa2d `anonymous
namespace'::X86MCInstLower::LowerMachineOperand
c:\users\mike.winterberg\llvm\llvm-project\llvm\lib\target\x86\x86mcinstlower.cpp:428:0
#9 0x7ff69fd28e93 `anonymous namespace'::X86MCInstLower::Lower
c:\users\mike.winterberg\llvm\llvm-project\llvm\lib\target\x86\x86mcinstlower.cpp:469:0
#10 0x7ff69fd25488 llvm::X86AsmPrinter::EmitInstru
[llvm-bugs] [Bug 43555] crash when using "-ftime-trace" and "-o /dev/null"
https://bugs.llvm.org/show_bug.cgi?id=43555 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r373771 Status|NEW |RESOLVED --- Comment #2 from Reid Kleckner --- r373771. -- 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 43567] New: [IA] .ascii directive rejects hex escape codes
https://bugs.llvm.org/show_bug.cgi?id=43567 Bug ID: 43567 Summary: [IA] .ascii directive rejects hex escape codes Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: ndesaulni...@google.com CC: caij2...@gmail.com, kristof.be...@arm.com, lloz...@chromium.org, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk, srhi...@google.com $ cat arm.s .ascii "ARM\x64" $ clang arm.s arm.s:1:8: error: invalid escape sequence (unrecognized character) in '.ascii' directive .ascii "ARM\x64" ^ $ aarch64-linux-gnu-as arm.s $ echo $? 0 It looks like the arm64 Linux kernel embeds a magic string in the kernel image. It is not a null terminated C style string (hence .ascii not .asciz). \x64 is a hexadecimal escape code (corresponds to 'd' in ASCII, but is meant to be a cute joke I think). -- 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 43568] New: -Wall is interpreted as -Weverything in the windows driver
https://bugs.llvm.org/show_bug.cgi?id=43568 Bug ID: 43568 Summary: -Wall is interpreted as -Weverything in the windows driver Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: zahira.ammarguel...@intel.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk ksh-3.2$ cat t.cpp constexpr int const_expr = 0; ksh-3.2$ ksh-3.2$ clang-cl -c -Wall t.cpp t.cpp(1,1): warning: 'constexpr' specifier is incompatible with C++98 [-Wc++98-compat] constexpr int const_expr = 0; ^ t.cpp(1,15): warning: unused variable 'const_expr' [-Wunused-const-variable] constexpr int const_expr = 0; ^ 2 warnings generated. ksh-3.2$ ksh-3.2$ clang -c -Wall -### t.cpp "clang-cl.EXE" "-cc1" "-triple" "x86_64-pc-windows-msvc19.15.26726" "-emit-obj" "-mrelax-all" "-mincremental-linker-compatible" "-disable-free" "-main-file-name" "t.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mframe-pointer=none" "-relaxed-aliasing" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-mllvm" "-x86-asm-syntax=intel" "-D_MT" "-flto-visibility-public-std" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-stack-protector" "2" "-fms-volatile" "-fdiagnostics-format" "msvc" "-dwarf-column-info" "-resource-dir" "-Weverything" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "0" "-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.15.26726" "-std=c++14" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-faddrsig" "-o" "t.obj" "-x" "c++" "t.cpp" Shouldn't -Wall be translated to -Wall instead of -Weverything. -- 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 43569] New: [MemorySSA][SimpleUnswitch]Assertion `!NodePtr->isKnownSentinel()' failed
https://bugs.llvm.org/show_bug.cgi?id=43569
Bug ID: 43569
Summary: [MemorySSA][SimpleUnswitch]Assertion
`!NodePtr->isKnownSentinel()' failed
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: j...@us.ibm.com
CC: llvm-bugs@lists.llvm.org
$cat t.c
short a;
int b;
void c() {
for (;;) {
b = 0;
for (; b < a; b++)
;
}
}
$clang -fprofile-instr-generate -O3 -fexperimental-new-pass-manager -mllvm
-enable-nontrivial-unswitch t.c -c
llvm-project/llvm/include/llvm/ADT/ilist_iterator.h:139:
llvm::ilist_iterator::reference
llvm::ilist_iterator, false, false>::operator*() const [OptionsT =
llvm::ilist_detail::node_options,
IsReverse = false, IsConst = false]: Assertion `!NodePtr->isKnownSentinel()'
failed.
Assert in llvm::MemorySSAUpdater::moveAllAccesses.
--
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 43568] -Wall is interpreted as -Weverything in the windows driver
https://bugs.llvm.org/show_bug.cgi?id=43568 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||r...@google.com --- Comment #1 from Reid Kleckner --- This is intended behavior to match cl.exe, it was done in r319116. I can't find any public discussion about it, but I remember spending time on it. You can use -W[123] to get the regular -Wall group. -- 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 18003 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: !empty()
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-04 Type: Bug New issue 18003 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: !empty() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18003 Detailed Report: https://oss-fuzz.com/testcase?key=5708730590560256 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !empty() optimizeDoubleFP llvm::LibCallSimplifier::optimizeSqrt Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=201906300300 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5708730590560256 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 43570] New: testsuite: TestSBCommandReturnObject: object has no attribute 'dylibPath'
https://bugs.llvm.org/show_bug.cgi?id=43570
Bug ID: 43570
Summary: testsuite: TestSBCommandReturnObject: object has no
attribute 'dylibPath'
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: jan.kratoch...@redhat.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9530/steps/test/logs/stdio
AttributeError: 'TestSBCommandReturnObject' object has no attribute 'dylibPath'
Fix crash on SBCommandReturnObject & assignment
https://reviews.llvm.org/D67589
env = {self.dylibPath: self.getLLDBLibraryEnvVal()}
I do not know how to link with liblldb on Windows so marking it as failing on
Windows.
--
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 43564] [InstCombine] Failure to recognize sign bit test if the high bit extract is followed by trunc
https://bugs.llvm.org/show_bug.cgi?id=43564 Roman Lebedev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |lebedev...@gmail.com Fixed By Commit(s)||373801, 373802 --- Comment #4 from Roman Lebedev --- r373802 -- 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 43566] Assertion failed: getNumber() >= 0 && "cannot get label for unreachable MBB" when targeting x86_x64 windows
https://bugs.llvm.org/show_bug.cgi?id=43566 Reid Kleckner changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r373805 --- Comment #2 from Reid Kleckner --- (In reply to Reid Kleckner from comment #1) > Block placement seems to try to remove bb.5, which falls through to bb.6, > but it fails to consider that the block is address taken. :( It seems the MBP code that fails to consider address taken blocks was added in r371177 (mid September), so I went ahead and reverted that in r373805. -- 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 42832] -Wpessimizing-move and -Wredundant-move are applicable only when returned expression is id-expression
https://bugs.llvm.org/show_bug.cgi?id=42832 rtr...@google.com changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #2 from rtr...@google.com --- I've had to revert r368237 in r373421 since it introduced a regression in the warning. -- 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 18009 in oss-fuzz: llvm:clang-fuzzer: ASSERT: (!isa(LookupCtx) || LookupCtx->isDependentContext() || cast(Lo
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-10-05 Type: Bug New issue 18009 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: (!isa(LookupCtx) || LookupCtx->isDependentContext() || cast(Lo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18009 Detailed Report: https://oss-fuzz.com/testcase?key=5697741916733440 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (!isa(LookupCtx) || LookupCtx->isDependentContext() || cast(Lo clang::Sema::LookupQualifiedName clang::Sema::LookupTemplateName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201908140336:201908150335 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5697741916733440 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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
