[llvm-bugs] [Bug 43950] New: Segfault while building zircon
https://bugs.llvm.org/show_bug.cgi?id=43950 Bug ID: 43950 Summary: Segfault while building zircon Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: leonardc...@google.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22787 --> https://bugs.llvm.org/attachment.cgi?id=22787&action=edit reproducer.tar.gz We hit the following segfault when building zircon: ``` [2806/49927] CXX kernel-arm64-clang/obj/kernel/dev/interrupt/arm_gic/v3/v3.arm_gicv3.cc.o FAILED: kernel-arm64-clang/obj/kernel/dev/interrupt/arm_gic/v3/v3.arm_gicv3.cc.o ../../../../llvm-monorepo/llvm-build-2-master-fuchsia-toolchain/install/bin//clang++ -MD -MF kernel-arm64-clang/obj/kernel/dev/interrupt/arm_gic/v3/v3.arm_gicv3.cc.o.d -o kernel-arm64-clang/obj/kernel/dev/interrupt/arm_gic/v3/v3.arm_gicv3.cc.o -DTOOLCHAIN_VERSION=/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-2-master-fuchsia-toolchain/install/bin/ -DZX_DEBUGLEVEL=2 -DLK_DEBUGLEVEL=2 -DWITH_FRAME_POINTERS=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -DKERNEL_BASE=0x -DSMP_MAX_CPUS=16 -D_KERNEL -DLK -DENABLE_PANIC_SHELL -DWITH_DEBUG_LINEBUFFER -DZIRCON_TOOLCHAIN -DWITH_KERNEL_PCIE -DWITH_FAIR_SCHEDULER=1 -DARCH_ARM64 -DKERNEL_ASPACE_BASE=0x -DKERNEL_ASPACE_SIZE=0x0001 -DUSER_ASPACE_BASE=0x0100 -DUSER_ASPACE_SIZE=0xfe00 -I../../zircon/kernel/include -I../../zircon/kernel/lib/libc/include -I../../zircon/kernel/lib/io/include -I../../zircon/kernel/lib/heap/include -I../../zircon/system/ulib/lazy_init/include -I../../zircon/system/ulib/lockdep/include -I../../zircon/system/ulib/ffl/include -I../../zircon/kernel/vm/include -I../../zircon/kernel/lib/user_copy/include -I../../zircon/system/ulib/zircon-internal/include -I../../zircon/kernel/lib/ktrace/include -I../../zircon/system/ulib/fbl/include -I../../zircon/kernel/lib/fbl/include -I../../zircon/system/public -I../../zircon/kernel/arch/arm64/include -I../../zircon/kernel/dev/interrupt/arm_gic/v3/include -I../../zircon/kernel/dev/interrupt/include -I../../zircon/kernel/dev/interrupt/arm_gic/common/include -I../../zircon/kernel/dev/interrupt/arm_gic/v2/include -I../../zircon/system/ulib/region-alloc/include -I../../zircon/kernel/dev/pcie/include -I../../zircon/kernel/dev/pdev/include -idirafter ../../zircon/kernel/lib/libc/limits-dummy -fno-common --target=aarch64-fuchsia -mcpu=cortex-a53 -ffixed-x18 -fcrash-diagnostics-dir=clang-crashreports -fcolor-diagnostics -fdebug-prefix-map=/usr/local/google/home/leonardchan/other-fuchsia-checkouts/fuchsia/out/default.zircon=. -fdebug-prefix-map=/usr/local/google/home/leonardchan/other-fuchsia-checkouts/fuchsia/out=.. -fdebug-prefix-map=/usr/local/google/home/leonardchan/other-fuchsia-checkouts/fuchsia=../.. -no-canonical-prefixes -O2 -g3 -Wall -Wextra -Wno-unused-parameter -Werror=unused-label -Werror=return-type -Wno-address-of-packed-member -Wnewline-eof -Wno-unknown-warning-option -Wno-c99-designator -Wno-int-in-bool-context -fno-omit-frame-pointer -ffunction-sections -fdata-sections -Wthread-safety -Wimplicit-fallthrough -fvisibility=hidden -ftrivial-auto-var-init=pattern -Werror -Wno-error=deprecated-declarations -fpie -ffreestanding -include ../../zircon/kernel/include/hidden.h -fno-unwind-tables -mgeneral-regs-only -Wformat=2 -Wvla -ffixed-x15 -mcmodel=kernel -fno-sanitize=safe-stack -fsanitize=shadow-call-stack -fdata-sections -Wno-gnu-string-literal-operator-template -std=c++17 -Wconversion -Wno-sign-conversion -Wextra-semi -Wno-deprecated-copy -ftemplate-backtrace-limit=0 -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -faligned-new=8 -fno-exceptions -c ../../zircon/kernel/dev/interrupt/arm_gic/v3/arm_gicv3.cc clang++: error: unable to execute command: Segmentation fault clang++: error: clang frontend command failed due to signal (use -v to see invocation) Fuchsia clang version 10.0.0 (https://github.com/llvm/llvm-project.git 01b10bc7b14963902405d202ac78cd88d44adbc5) (based on LLVM 10.0.0svn) Target: aarch64-unknown-fuchsia Thread model: posix InstalledDir: ../../../../llvm-monorepo/llvm-build-2-master-fuchsia-toolchain/install/bin clang++: 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++: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++: note: diagnostic msg: clang-crashreports/arm_gicv3-6dd0ee.cpp clang++: note: diagnostic msg: clang-crashreports/arm_gicv3-6dd0ee.sh clang++: note: diagnostic msg:
[llvm-bugs] [Bug 43793] Merge rG56d81104f145ad2ff65ec88b249262888f80e9bc into 9.0.1
https://bugs.llvm.org/show_bug.cgi?id=43793 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Fangrui Song --- release/9.x is based off revision 366426. The dependent commit rL372734 of this commit (llvmorg-10-init-8247-g56d81104f14) is not included in release/9.x, so llvmorg-10-init-8247-g56d81104f14 is not needed. I verified that the test case added in llvmorg-10-init-8247-g56d81104f14 does not segfault with release/9.x . This should be good enough. The test failure is due to different outputs between release/9.x and master (related to relocated entries in SHF_MERGE. This discrepancy should not matter in practice). Marking as resolved. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 43793, which changed state. Bug 43793 Summary: Merge rG56d81104f145ad2ff65ec88b249262888f80e9bc into 9.0.1 https://bugs.llvm.org/show_bug.cgi?id=43793 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 43949] New: Wrong debug info generated at -O3 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=43949
Bug ID: 43949
Summary: Wrong debug info generated at -O3 (-O0 is correct)
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: shu...@outlook.com
CC: dav...@freebsd.org, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
The expected output from lldb should be 0. However, compiled with "-O3", lldb
outputs 5.
$ clang-trunk -v
clang version 10.0.0 (trunk 375507)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/9
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/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.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.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$ clang-trunk -g abc.c -O3
$ lldb-trunk -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to '/home/sding/LLDB-testing/reduce/32221/report/a.out'
(x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/sding/LLDB-testing/reduce/32221/report/cmds'.
(lldb) b 22
Breakpoint 1: where = a.out`main + 671 at abc.c:22:7, address =
0x004007df
(lldb) r
Process 24738 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004007df a.out`main at abc.c:22:7
19 h((char)i);
20 i = 0;
21 for (; i < 2; i++) {
-> 22 h(d[i]); // optimize_me_not0
23 }
24 }
Process 24738 launched: '/home/sding/LLDB-testing/reduce/32221/report/a.out'
(x86_64)
(lldb) p i
(int) $0 = 5
$ clang-trunk -g abc.c -O0
$ lldb-trunk -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to '/home/sding/LLDB-testing/reduce/32221/report/a.out'
(x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/sding/LLDB-testing/reduce/32221/report/cmds'.
(lldb) b 22
Breakpoint 1: where = a.out`main + 104 at abc.c:22:7, address =
0x004005c8
(lldb) r
Process 30349 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004005c8 a.out`main at abc.c:22:7
19 h((char)i);
20 i = 0;
21 for (; i < 2; i++) {
-> 22 h(d[i]); // optimize_me_not0
23 }
24 }
Process 30349 launched: '/home/sding/LLDB-testing/reduce/32221/report/a.out'
(x86_64)
(lldb) p i
(int) $0 = 0
$ cat abc.c
int a[256];
int b, c;
static int d[] = {0, -4L};
void e(f) { b = b & 4095 ^ a[(b ^ f) & 5]; }
void h(f) {
unsigned long g = f;
b = b & 4095 ^ a[(b ^ g) & 255];
e(g >> 8);
e(g >> 6);
e(g >> 4);
e(g >> 2);
e(g >> 56);
}
int main() {
int i = 0;
if (c)
d[1] = 3;
for (; i < 5; i++)
h((char)i);
i = 0;
for (; i < 2; i++) {
h(d[i]); // optimize_me_not0
}
}
$ cat cmds
b 22
r
p i
kill
q
--
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 43511] Regression(373168): "error in backend: Size expression must be absolute." when building boringssl for arm
https://bugs.llvm.org/show_bug.cgi?id=43511 Fangrui Song changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #5 from Fangrui Song --- The boringssl bug has been fixed for more than one month https://boringssl.googlesource.com/boringssl/+/bd522862a0b4c84a0ed8e37096d1c361dc6beaa9 -- 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 43736] Please backport r372038 to 9.0
https://bugs.llvm.org/show_bug.cgi?id=43736 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|r372038 |r372038 4e858e4 Resolution|--- |FIXED --- Comment #2 from Tom Stellard --- Merged: 4e858e4 -- 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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 43736, which changed state. Bug 43736 Summary: Please backport r372038 to 9.0 https://bugs.llvm.org/show_bug.cgi?id=43736 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43787] Merge r374598 into the 9.0 branch : [mips] Store 64-bit `li.d' operand as a single 8-byte value
https://bugs.llvm.org/show_bug.cgi?id=43787 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED CC||tstel...@redhat.com Status|NEW |RESOLVED Fixed By Commit(s)|r374598 |r374598 8b0167f --- Comment #2 from Tom Stellard --- Merged: 8b0167f -- 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 43360] [meta] 9.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=43360 Bug 43360 depends on bug 43787, which changed state. Bug 43787 Summary: Merge r374598 into the 9.0 branch : [mips] Store 64-bit `li.d' operand as a single 8-byte value https://bugs.llvm.org/show_bug.cgi?id=43787 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43948] New: [SLPVectorizer] miscompile of reduction with extra uses
https://bugs.llvm.org/show_bug.cgi?id=43948
Bug ID: 43948
Summary: [SLPVectorizer] miscompile of reduction with extra
uses
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
This is modified/reduced from an existing test in
test/Transforms/SLPVectorizer/X86/horizontal-minmax.ll:
@arr = local_unnamed_addr global [32 x i32] zeroinitializer, align 16
@var = global i32 zeroinitializer, align 8
define i32 @horiz_max_multiple_uses() {
%t0 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 0), align 16
%t1 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 1), align 4
%t2 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 2), align 8
%t3 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 3), align 4
%t4 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 4), align 16
%t5 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 5), align 4
%c01 = icmp sgt i32 %t0, %t1
%s5 = select i1 %c01, i32 %t0, i32 %t1
%c012 = icmp sgt i32 %s5, %t2
%t8 = select i1 %c012, i32 %s5, i32 %t2
%c0123 = icmp sgt i32 %t8, %t3
%t11 = select i1 %c0123, i32 %t8, i32 %t3
%EXTRA_USE = icmp sgt i32 %t11, %t4
%t14 = select i1 %EXTRA_USE, i32 %t11, i32 %t4
%c012345 = icmp sgt i32 %t14, %t5
%t17 = select i1 %c012345, i32 %t14, i32 %t5
%THREE_OR_FOUR = select i1 %EXTRA_USE, i32 3, i32 4
store i32 %THREE_OR_FOUR, i32* @var, align 8
ret i32 %t17
}
$ ./opt -slp-vectorizer slpmax.ll -S
@arr = local_unnamed_addr global [32 x i32] zeroinitializer, align 16
@var = global i32 0, align 8
define i32 @horiz_max_multiple_uses() {
%1 = load <4 x i32>, <4 x i32>* bitcast ([32 x i32]* @arr to <4 x i32>*),
align 16
%t4 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 4), align 16
%t5 = load i32, i32* getelementptr inbounds ([32 x i32], [32 x i32]* @arr,
i64 0, i64 5), align 4
%rdx.shuf = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32>
%rdx.minmax.cmp = icmp sgt <4 x i32> %1, %rdx.shuf
%rdx.minmax.select = select <4 x i1> %rdx.minmax.cmp, <4 x i32> %1, <4 x i32>
%rdx.shuf
%rdx.shuf1 = shufflevector <4 x i32> %rdx.minmax.select, <4 x i32> undef, <4
x i32>
%rdx.minmax.cmp2 = icmp sgt <4 x i32> %rdx.minmax.select, %rdx.shuf1
%rdx.minmax.select3 = select <4 x i1> %rdx.minmax.cmp2, <4 x i32>
%rdx.minmax.select, <4 x i32> %rdx.shuf1
%2 = extractelement <4 x i32> %rdx.minmax.select3, i32 0
%3 = icmp sgt i32 %2, %t4
%4 = select i1 %3, i32 %2, i32 %t4
%c012345 = icmp sgt i32 %4, %t5
%t17 = select i1 %c012345, i32 %4, i32 %t5
%THREE_OR_FOUR = select i1 undef, i32 3, i32 4
store i32 %THREE_OR_FOUR, i32* @var, align 8
ret i32 %t17
}
-
Notice that the condition operand of %THREE_OR_FOUR was removed. That leads to
storing a potentially wrong value.
--
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 36706] [X86] Could commute some VEX encoded instructions to enable 2 byte VEX prefix
https://bugs.llvm.org/show_bug.cgi?id=36706 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||f65493a83e3bdb402fb1dfa92bc ||c25707e961147 --- Comment #2 from Craig Topper --- Fixed in f65493a83e3bdb402fb1dfa92bcc25707e961147 -- 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 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://bugs.llvm.org/show_bug.cgi?id=26299 Bug 26299 depends on bug 36706, which changed state. Bug 36706 Summary: [X86] Could commute some VEX encoded instructions to enable 2 byte VEX prefix https://bugs.llvm.org/show_bug.cgi?id=36706 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43947] New: mis-indentation caused by macro/template instantiation
https://bugs.llvm.org/show_bug.cgi?id=43947
Bug ID: 43947
Summary: mis-indentation caused by macro/template instantiation
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: s...@lukas-wirz.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
The problem I'm observing is not limited to clang-format-9 but also exists in 7
and 8 (I'm using the versions that are packaged in Debian/testing).
The .clang-format I'm using contains only "BasedOnStyle: LLVM".
The file that gets misformatted is
<<<
#define container_output(container)
\
template
\
ostream &operator<<(ostream &s, const container &v) {
\
s << "{";
\
for (typename container::const_iterator x(v.begin()); x != v.end();) {
\
s << *x;
\
if (++x != v.end())
\
s << ",";
\
}
\
s << "}";
\
return s;
\
}
container_output(vector)
int myfunc() {
return 0;
}
>>>
where the macro definition is irrelevant and can be outcommented.
Instantiating the template defined in the macro (correct without semicolon)
causes the following function to be indented as:
<<<
container_output(vector)
int myfunc() {
return 0;
}
>>>
which is clearly two indentation-levels too many in the first line.
cheers, Lukas Wirz
--
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 43946] New: Invocation of memset with incorrect number of arguments results in segfault
https://bugs.llvm.org/show_bug.cgi?id=43946
Bug ID: 43946
Summary: Invocation of memset with incorrect number of
arguments results in segfault
Product: clang
Version: 9.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: mpr...@synopsys.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
As a part of testing our product that is based on Clang, we run our tool
against many packages that ship as a part of the Debian Linux distribution.
We recently upgraded our tool to be based off of Clang 9, and our Debian
package tests exposed a segfault.
There are a handful of packages [see Threaded USENET news reader (trn4,
https://packages.debian.org/jessie/trn4) as well as the PennMUSH virtual world
server (pennmush 1.8.2p8-1.1, https://packages.debian.org/jessie/pennmush)]
that use a bash script to configure the build process. Part of this is probing
the compiler to see what features are available. As a part of that probing, it
attempts to compile a source code that is similar to:
int main () {
extern void memset();
memset();
}
This compiles fine in Clang 8, but in Clang 9 it causes a segfault. The issue
appears to be in the the function
`clang::Sema::checkFortifiedBuiltinMemoryFunction`. I suspect it's not prepared
to handle such an unexpected call to `memset`. My understanding is that this
function is intended to emit a runtime diagnostic letting the user that they've
misused this C library function.
Here is a Compiler Explorer link showing the source, and the differences
between Clang 8 and Clang 9 behavior. https://c.godbolt.org/z/7dJxjJ
The output that Clang 9 shows is:
==
:2:17: warning: incompatible redeclaration of library function 'memset'
[-Wincompatible-library-redeclaration]
extern void memset();
^
:2:17: note: 'memset' is a builtin with type 'void *(void *, int,
unsigned long)'
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-9.0.0/bin/clang-9 -cc1
-triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name example.c
-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 -debug-info-kind=limited -dwarf-version=4
-debugger-tuning=gdb -resource-dir
/opt/compiler-explorer/clang-9.0.0/lib/clang/9.0.0 -internal-isystem
/usr/local/include -internal-isystem
/opt/compiler-explorer/clang-9.0.0/lib/clang/9.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir /home/ubuntu -ferror-limit 19 -fmessage-length 0
-fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -mllvm
--x86-asm-syntax=intel -faddrsig -x c
1. :3:12: current parser token ')'
2. :1:13: parsing function body 'main'
3. :1:13: in compound statement ('{}')
#0 0x55cdbf2c476a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x27db76a)
#1 0x55cdbf2c2524 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x27d9524)
#2 0x55cdbf2c2662 SignalHandler(int)
(/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x27d9662)
#3 0x7f57ca88a890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x55cdc092fc8e
clang::Sema::checkFortifiedBuiltinMemoryFunction(clang::FunctionDecl*,
clang::CallExpr*) (/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x3e46c8e)
#5 0x55cdc0b61377 clang::Sema::BuildResolvedCallExpr(clang::Expr*,
clang::NamedDecl*, clang::SourceLocation, llvm::ArrayRef,
clang::SourceLocation, clang::Expr*, bool, clang::CallExpr::ADLCallKind)
(/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x4078377)
#6 0x55cdc0b61e7e clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation, clang::Expr*, bool)
(/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x4078e7e)
#7 0x55cdc0b631f2 clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation, clang::Expr*)
(/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x407a1f2)
#8 0x55cdc083d13f
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) (/opt/compiler-explorer/clang-9.0.0/bin/clang-9+0x3d5413f)
#9 0x55cdc0837e0f clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState, bool)
(/opt/compiler-explorer/clang-9.0.0/bi
[llvm-bugs] [Bug 43945] New: Loop Vectorization pass segfaults.
https://bugs.llvm.org/show_bug.cgi?id=43945 Bug ID: 43945 Summary: Loop Vectorization pass segfaults. Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: amy.zhu...@intel.com CC: llvm-bugs@lists.llvm.org Clang-10 crashed when compiling mkldnn. Stack dump: 0. Program arguments: /usr/lib/llvm-10/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name pooling.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-feature +sse4.1 -dwarf-column-info -debugger-tuning=gdb -resource-dir /usr/lib/llvm-10/lib/clang/10.0.0 -D DNNL_DLL -D DNNL_DLL_EXPORTS -D __STDC_CONSTANT_MACROS -D __STDC_LIMIT_MACROS -I /amy/mkl-dnn/include -I /amy/mkl-dnn/build/include -I /amy/mkl-dnn/src -I /amy/mkl-dnn/src/common -D NDEBUG -D _FORTIFY_SOURCE=2 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/backward -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-10/lib/clang/10.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -Wall -Wno-unknown-pragmas -Wformat -Wformat-security -Wno-pass-failed -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /amy/mkl-dnn/build/src/common -ferror-limit 19 -fmessage-length 0 -fvisibility internal -fvisibility-inlines-hidden -fopenmp -stack-protector 3 -fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o CMakeFiles/dnnl_common.dir/pooling.cpp.o -x c++ /amy/mkl-dnn/src/common/pooling.cpp 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Function Pass Manager' on module '/amy/mkl-dnn/src/common/pooling.cpp'. 4. Running pass 'Loop Vectorization' on function '@_ZN12_GLOBAL__N_117pooling_desc_initEP19dnnl_pooling_desc_t16dnnl_prop_kind_t15dnnl_alg_kind_tPK18dnnl_memory_desc_tS6_PKlS8_S8_S8_' #0 0x7f58b11050ff llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xaff0ff) #1 0x7f58b1102d80 llvm::sys::RunSignalHandlers() (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xafcd80) #2 0x7f58b1105501 (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xaff501) #3 0x7f58b82bd730 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12730) #4 0x7f58b20595c7 llvm::LoopVectorizationPlanner::buildVPlanWithVPRecipes(llvm::VFRange&, llvm::SmallPtrSetImpl&, llvm::SmallPtrSetImpl&) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x1a535c7) #5 0x7f58b205428f llvm::LoopVectorizationPlanner::buildVPlansWithVPRecipes(unsigned int, unsigned int) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x1a4e28f) #6 0x7f58b20537b2 llvm::LoopVectorizationPlanner::plan(unsigned int) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x1a4d7b2) #7 0x7f58b205c88f llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x1a5688f) #8 0x7f58b205f379 llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&, std::function&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x1a59379) #9 0x7f58b2061ddd (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x1a5bddd) #10 0x7f58b1246206 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xc40206) #11 0x7f58b1246643 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xc40643) #12 0x7f58b1246ba5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xc40ba5) #13 0x7f58b6a87f21 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 >) (/usr/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x15fdf21) #14 0x7f58b6d21240 (/usr/lib/x86_64-linux-gnu/libclang-cpp.so.10+0x1897240) #15 0x7f58b5c1cda5 clang::ParseAST(c
[llvm-bugs] [Bug 43944] New: Clang (front end) errors on variadic template operator=
https://bugs.llvm.org/show_bug.cgi?id=43944
Bug ID: 43944
Summary: Clang (front end) errors on variadic template
operator=
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: davidfink...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Clang determines a variadic template operator= as taking 0 arguments (which it
then errors on, since it requires 1), no matter what arguments are actually
passed.
See godbolt, or the same code below:
https://godbolt.org/z/cqqnCb
:21:20: error: overloaded 'operator=' must be a binary operator (has 1
parameter)
decltype(auto) operator=(Args&&... args) {
^
:40:7: note: in instantiation of function template specialization
'mynamespace::vector >::operator=<>' requested here
c.operator=({getc()});
#include
namespace mynamespace {
template >
class vector : public std::vector {
private:
using Base = std::vector;
public:
template
vector(Args&&... args)
: Base(std::forward(args)...) {
}
vector(std::initializer_list il)
: Base(il) {
}
template
decltype(auto) operator=(Args&&... args) {
Base::operator=(std::forward(args)...);
return *this;
}
};
} /* namespace mynamespace */
struct C {
int x;
};
C getc();
int main() {
mynamespace::vector c;
// works
c.operator=(mynamespace::vector{getc()});
// doesn't work (= template errors on 0 params)
c.operator=({getc()});
// also doesn't work
c = {getc()};
// also doesn't work
c = {getc(), getc()};
}
--
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 16523 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: F.isCanonical(L) && "Invalid canonical representation"
Updates: Labels: Deadline-Approaching Comment #2 on issue 16523 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: F.isCanonical(L) && "Invalid canonical representation" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16523#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 43805] [AMDGPU][MC][GFX10] src0 of v_movrelsd_b32 and v_movrelsd_2_b32 should be VGPRs
https://bugs.llvm.org/show_bug.cgi?id=43805 Dmitry changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Dmitry --- *** This bug has been marked as a duplicate of bug 40903 *** -- 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 40903] [AMDGPU][MC][GFX7][GFX8] src0 of v_movrelsd_b32 should accept vgprs only
https://bugs.llvm.org/show_bug.cgi?id=40903 Dmitry changed: What|Removed |Added Fixed By Commit(s)||e25bc5e 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 43527] Invalid PPC CTR loop when building node on FreeBSD/powerpc64
https://bugs.llvm.org/show_bug.cgi?id=43527 Alfredo Dal'Ava Júnior changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #7 from Alfredo Dal'Ava Júnior --- (In reply to Nemanja Ivanovic from comment #6) > Fix committed in > https://reviews.llvm.org/rG97e36260709c541044f30092b420238511e13e5b > > please verify the fix and close the PR if valid. Nemanja, I applied your patch over LLVM9 in FreeBSD base and it really fixes the issue. Thank you! Alfredo -- 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 43943] New: iplist_impl - use after move warnings
https://bugs.llvm.org/show_bug.cgi?id=43943
Bug ID: 43943
Summary: iplist_impl - use after move warnings
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Support Libraries
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: david.bolvan...@gmail.com, dexonsm...@apple.com,
llvm-bugs@lists.llvm.org
We're seeing static analyzer use after move warnings on both these cases:
iplist_impl(iplist_impl &&X)
: TraitsT(std::move(X)), IntrusiveListT(std::move(X)) {}
iplist_impl &operator=(iplist_impl &&X) {
*static_cast(this) = std::move(X);
*static_cast(this) = std::move(X);
return *this;
}
Duncan - you committed this back at rL281181 - any suggestions?
--
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 18815 in oss-fuzz: llvm:clangd-fuzzer: ASSERT: (uint16_t)DataLen == DataLen && (uint16_t)KeyLen == KeyLen
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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-11-08 Type: Bug New issue 18815 by ClusterFuzz-External: llvm:clangd-fuzzer: ASSERT: (uint16_t)DataLen == DataLen && (uint16_t)KeyLen == KeyLen https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18815 Detailed Report: https://oss-fuzz.com/testcase?key=5658847666765824 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clangd-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (uint16_t)DataLen == DataLen && (uint16_t)KeyLen == KeyLen clang::ASTWriter::WriteIdentifierTable clang::ASTWriter::WriteASTCore Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=201911070445 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5658847666765824 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 43942] New: Clang or lld generates invalid short relocation for Google Chrome with debuginfo
https://bugs.llvm.org/show_bug.cgi?id=43942 Bug ID: 43942 Summary: Clang or lld generates invalid short relocation for Google Chrome with debuginfo Product: clang Version: 9.0 Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: conrad.me...@isilon.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Possibly related to bug 15356 or bug 21423. When linking a debug build of recent Chrome (78.x), with recent Clang+LLD (9.0.0), ld.lld fails due to 32-bit relocations on >4GB offsets: > ld.lld: error: /usr/lib/crtn.o:(.debug_aranges+0x6): relocation R_X86_64_32 > out of range: 4357891405 is not in [0, 4294967295]; consider recompiling with > -fdebug-types-section to reduce size of debug sections I'm not sure what I'm supposed to do about this as an end-user. Chrome is just a gigantic program: $ c++ -Wl,--version-script=../../build/linux/chrome.map -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fuse-ld=lld -Wl,--color-diagnostics -m64 -rdynamic -pie -Wl,--disable-new-dtags -L/usr/local/lib -L/usr/local/lib/nss -fstack-protector-strong -L/usr/local/lib -o "./chrome" -Wl,--start-group @"./chrome.rsp" -Wl,--end-group ... (-lfoo -lbar from here) $ cat chrome.rsp | tr ' ' '\0' | xargs -0 du -csh ... 3.7G Should Clang (or lld?) emit 64-bit relocations automatically? Do I need to ask the Chrome folks to use some large data mode flag? They already use -fPIC rather than -fpic. -fPIC If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. (From the gcc manual page.) Also gcc: -mcmodel=small Generate code for the small code model: the program and its symbols must be linked in the lower 2 GB of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. This is the default code model. -mcmodel=medium Generate code for the medium model: the program is linked in the lower 2 GB of the address space. Small symbols are also placed there. Symbols with sizes larger than -mlarge-data-threshold are put into large data or BSS sections and can be located above 2GB. Programs can be statically or dynamically linked. -mcmodel=large Generate code for the large model. This model makes no assumptions about addresses and sizes of sections. Here's Clang's full documentation on -mcmodel: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mcmodel (Yeah, that's not helpful.) Maybe -mcmodel is passed through to cc1 as -mcode-model= here: https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Clang.cpp#L4320 The scenario seems pretty similar to this test case: https://github.com/llvm/llvm-project/blob/master/lld/test/ELF/x86-64-reloc-debug-overflow.s -- 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 43941] New: Add column headers for relocation printing
https://bugs.llvm.org/show_bug.cgi?id=43941 Bug ID: 43941 Summary: Add column headers for relocation printing Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org GNU objdump prints column headers for relocation printing, but llvm-objdump does not. We should add them for compatibility, and also readability: C:\Work\TempWork> objdump -r bar.o bar.o: file format elf64-x86-64 RELOCATION RECORDS FOR [.text.main]: OFFSET TYPE VALUE 000b R_X86_64_PC32 .L.str-0x0004 0012 R_X86_64_PLT32printf-0x0004 C:\Work\TempWork> C:\llvm\build\Debug\bin\llvm-objdump -r bar.o bar.o: file format ELF64-x86-64 RELOCATION RECORDS FOR [.text.main]: 000b R_X86_64_PC32 .L.str-4 0012 R_X86_64_PLT32 printf-4 -- 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 43940] New: Ubuntu packages have IR in .a files instead of native code
https://bugs.llvm.org/show_bug.cgi?id=43940 Bug ID: 43940 Summary: Ubuntu packages have IR in .a files instead of native code Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: kola...@mail.ru CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22784 --> https://bugs.llvm.org/attachment.cgi?id=22784&action=edit build.bash Recently in Ubuntu packages I started to see that libclang .a files contain .o files that contain LLVM bitcode instead of native code. This breaks linking other tools with ld and makes linking with ld.lld terribly slow because it has to rebuild bitcode into native code. There is a workaround (see build.bash), but relying on it defeats the purpose of using binary packages because it is also terribly slow. -- 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
