[llvm-bugs] Issue 7167 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-03-28 Type: Bug New issue 7167 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7167 Detailed report: https://oss-fuzz.com/testcase?key=5729224427044864 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::DWARFFormValue::extractValue llvm::DWARFDebugLine::Prologue::parse Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711160610:201712080609 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5729224427044864 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36928] New: [PPC64] V2 ABI: implement toc restore after calls.
https://bugs.llvm.org/show_bug.cgi?id=36928 Bug ID: 36928 Summary: [PPC64] V2 ABI: implement toc restore after calls. Product: lld Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: sfert...@ca.ibm.com CC: llvm-bugs@lists.llvm.org rewriting nops to toc restores works for big-endian, but not little-endian ppc64. Calls that cross dso-boundaries will set r2 to the toc pointer for the dso the callee resides in. The plt stub will save the local toc pointer into the toc save slot (sp + 24) and the compiler will have inserted a nop after any call that may not be local. LLD needs to recognize when a call is not local, and rewrite the nop to a load of the saved toc pointer into r2. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36927] New: 16-bit relocation problem (ELF32)
https://bugs.llvm.org/show_bug.cgi?id=36927 Bug ID: 36927 Summary: 16-bit relocation problem (ELF32) Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: nruslan_de...@yahoo.com CC: llvm-bugs@lists.llvm.org Consider the following example test.S: .code16 .global _start _start: movw $_start+0x8300,%ax Basically, it is 16-bit code inside ELF32. _start is 0x7C00. Therefore, the instruction will use 0x7C00+0x8300=0xFF00 (i.e., still fits in a 16-bit relocation). 1. Compile with clang: clang -c -Wall -O2 -m32 test.S -o test.o 2. GNU linker works fine: ld -melf_i386 -Ttext 0x7c00 -s --oformat binary test.o and generates expected code: 0xB8 0x00 0xFF 3. However, ld.lld linker incorrectly calculates the relocation in this case (it works with smaller offsets, though): ld.lld -melf_i386 -Ttext 0x7c00 -s --oformat binary test.o ld.lld: error: test.o:(.text+0x1): relocation R_386_16 out of range: 18446744073709551360 is not in [0, 65535] -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36926] New: Add a flag to disable emitting the custom event instrumentation points
https://bugs.llvm.org/show_bug.cgi?id=36926 Bug ID: 36926 Summary: Add a flag to disable emitting the custom event instrumentation points Product: XRay Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Clang Assignee: dber...@google.com Reporter: dber...@google.com CC: llvm-bugs@lists.llvm.org This allows us to control whether or not we want to emit the custom event instrumentation points. We want this for the following reasons: - The instrumentation points are not supported in all platforms yet. We can set the default for these flags differently for different targets/front-ends. - The instrumentation points are currently expensive in terms of impact in code size as well as runtime overheads. - Provide more controls of the XRay instrumentation features we're providing at compile-time to allow users to make trade-offs on which kinds of sleds should be emitted (as we add more instrumentation point types in the future). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34982] [coroutines] assertion failure diagnosing bad coroutine await_suspend function
https://bugs.llvm.org/show_bug.cgi?id=34982 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Fiselier --- Fixed in r328606 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36925] New: define of <=> spaceship causes spurious warning with Wc++2a-compat
https://bugs.llvm.org/show_bug.cgi?id=36925
Bug ID: 36925
Summary: define of <=> spaceship causes spurious warning with
Wc++2a-compat
Product: clang
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: kark...@karkhaz.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Clang emits this warning when compiling C++ code that contains a define for the
spaceship operator:
foo.cpp:4:12: warning: '<=>' is a single token in C++2a; add a space to
avoid a change in behavior [-Wc++2a-compat]
#define op <=>
^
Reproduce by compiling this code:
#include
#include
#define op <=>
#define xstr(s) str(s)
#define str(s) #s
const char *s1 = xstr(op);
const char *s2 = "<=>";
int main(int argc, char *argv[])
{
assert(strcmp(s1, s2) == 0);
return 0;
}
I do not expect this code to emit that warning, because the #define should be
preprocessed away. When the spaceship is used in the code (in the assignment to
s1), it has been stringified, so clang should not treat it as an operator.
Although a warning is emitted, the code compiles correctly (i.e. the string s1
is set to "<=>" and thus the assertion succeeds). So although clang is warning
about <=> being a token, it still knows to preprocess it to a string.
When only preprocessing the file using `clang -E`, the warning is still emitted
(I do not expect this behaviour), and the two declarations are compiled to the
following (as expected):
const char *s1 = "<=>";
const char *s2 = "<=>";
I have reproduced this behaviour with both the 6.0 release of Clang, and ToT as
of 2018-03-28 (LLVM 2c3af0c1 and clang 60cec38f) on Linux.
I found it difficult to bisect because Clang and LLVM are in different
repositories, even using a script similar to this one [0]. I would be happy to
bisect if somebody could point me to a maintained combined LLVM+clang
repository (using submodules or whatever) or let me know what your approach to
bisecting is.
The commit that introduced the warning and preprocessor code is is daf599b1b13,
so I'm copying in Richard Smith.
Thank you!
[0] https://lists.llvm.org/pipermail/llvm-dev/2014-July/074489.html
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36924] New: [X86] Split vector schedule classes by vector width only as necessary
https://bugs.llvm.org/show_bug.cgi?id=36924 Bug ID: 36924 Summary: [X86] Split vector schedule classes by vector width only as necessary Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: andrea.dibia...@gmail.com, clement.cour...@gmail.com, craig.top...@gmail.com, llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com Blocks: 36908 Many targets have different schedule costs for 128/256/512-bit rr and rm versions of various SSE instructions (e.g. WriteFADD: ADDSS/ADDPS/VADDPS/VADDPSY/VADDPSZ). Given that we're overriding them anyhow means that we will generate multiple scheduler class entries so we should probably just create separate schedule classes for them. But, similar to [Bug #35608], it'd be useful to avoid having to define all these classes for cases where they don't differ or are not supported - so some kind of default inheritence would be very useful. e.g. WriteFADD_SSE : WriteFADD WriteFADD_AVX128 : WriteFADD WriteFADD_AVX256 : WriteFADD WriteFADD_AVX512 : WriteFADD Or maybe some mechanism with SchedAlias, or could we introduce something like SchedDefaultAlias? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=36908 [Bug 36908] [meta][x86] Improve scheduler classes instruction coverage -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36923] New: R_X86_64_32S: error while loading shared libraries: unexpected reloc type 0x0b
https://bugs.llvm.org/show_bug.cgi?id=36923 Bug ID: 36923 Summary: R_X86_64_32S: error while loading shared libraries: unexpected reloc type 0x0b Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: shen...@google.com CC: llvm-bugs@lists.llvm.org Created attachment 20136 --> https://bugs.llvm.org/attachment.cgi?id=20136&action=edit test.cc that reproduces the problem Lld generated binary has R_X86_64_32S in dynamic relocation section, which is wrong and rejected by dynamic loader at launch time: "error while loading shared libraries: unexpected reloc type 0x0b" I have an attachment that reproduces: >> clang++ -fuse-ld=lld -O2 -pie -Wl,-z,notext -O2 test.cc >> readelf -WDr a.out 'RELA' relocation section at offset 0x550 contains 288 bytes: Offset Info Type Symbol's Value Symbol's Name + Addend ... ... 1150 000a000b R_X86_64_32S 1280 closedir@GLIBC_2.2.5 + 0 1177 000a000b R_X86_64_32S 1280 closedir@GLIBC_2.2.5 + 0 >> ./a.out ./a.out: error while loading shared libraries: unexpected reloc type 0x0b -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36922] New: data race in ThinLTO
https://bugs.llvm.org/show_bug.cgi?id=36922
Bug ID: 36922
Summary: data race in ThinLTO
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Linker
Assignee: unassignedb...@nondot.org
Reporter: l...@inglorion.net
CC: llvm-bugs@lists.llvm.org
This does not reproduce reliably, but here is one occurrence I saw while
building Chromium:
[10819/65270] LINK ./angle_translator_fuzzer
FAILED: angle_translator_fuzzer
python "../../build/toolchain/gcc_link_wrapper.py"
--output="./angle_translator_fuzzer" -- ../../../../clang/bin/clang++
-Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro
-Wl,-z,defs -Wl,--no-as-needed -lpthread -Wl,--as-needed -fuse-ld=lld
-Wl,--icf=all -flto=thin -Wl,--thinlto-jobs=8
-Wl,--thinlto-cache-dir=thinlto-cache
-Wl,--thinlto-cache-policy,cache_size=10\%:cache_size_bytes=10g:cache_size_files=10
-Wl,--lto-O0 -fwhole-program-vtables -m64 -Werror -Wl,-O2 -Wl,--gc-sections
-Wl,--fatal-warnings -nostdlib++
--sysroot=../../build/linux/debian_sid_amd64-sysroot
-L../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu
-Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu
-L../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu
-Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu
-L../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu
-Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu
-fsanitize=cfi-vcall -Wl,-rpath-link=. -Wl,--disable-new-dtags -o
"./angle_translator_fuzzer" -Wl,--start-group @"./angle_translator_fuzzer.rsp"
-Wl,--end-group -ldl -lpthread -lrt
==
WARNING: ThreadSanitizer: data race (pid=246055)
Read of size 1 at 0x03a32adb by thread T7:
#0 getOpcode
/home/inglorion/llvm/llvm/include/llvm/CodeGen/MachineInstr.h:293
(lld+0x18a83cb)
#1 handleZeroArgFP
/home/inglorion/llvm/llvm/lib/Target/X86/X86FloatingPoint.cpp:1095
(lld+0x18a83cb)
#2 processBasicBlock
/home/inglorion/llvm/llvm/lib/Target/X86/X86FloatingPoint.cpp:449
(lld+0x18a83cb)
#3 (anonymous namespace)::FPS::runOnMachineFunction(llvm::MachineFunction&)
/home/inglorion/llvm/llvm/lib/Target/X86/X86FloatingPoint.cpp:368
(lld+0x18a6fd5)
#4 llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/home/inglorion/llvm/llvm/lib/CodeGen/MachineFunctionPass.cpp:62
(lld+0x1d687f3)
#5 llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/inglorion/llvm/llvm/lib/IR/LegacyPassManager.cpp:1520 (lld+0x2ce4a97)
#6 llvm::FPPassManager::runOnModule(llvm::Module&)
/home/inglorion/llvm/llvm/lib/IR/LegacyPassManager.cpp:1541 (lld+0x2ce4ea2)
#7 runOnModule /home/inglorion/llvm/llvm/lib/IR/LegacyPassManager.cpp:1597
(lld+0x2ce568b)
#8 run /home/inglorion/llvm/llvm/lib/IR/LegacyPassManager.cpp:1700
(lld+0x2ce568b)
#9 llvm::legacy::PassManager::run(llvm::Module&)
/home/inglorion/llvm/llvm/lib/IR/LegacyPassManager.cpp:1731 (lld+0x2ce5eda)
#10 (anonymous namespace)::codegen(llvm::lto::Config&,
llvm::TargetMachine*,
std::function > (unsigned int)>, unsigned
int, llvm::Module&) /home/inglorion/llvm/llvm/lib/LTO/LTOBackend.cpp:291
(lld+0x12cf004)
#11 llvm::lto::thinBackend(llvm::lto::Config&, unsigned int,
std::function > (unsigned int)>,
llvm::Module&, llvm::ModuleSummaryIndex const&,
llvm::StringMap,
std::allocator > >,
llvm::MallocAllocator> const&, llvm::DenseMap,
llvm::detail::DenseMapPair > const&,
llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&)
/home/inglorion/llvm/llvm/lib/LTO/LTOBackend.cpp:479 (lld+0x12cfb85)
#12 (anonymous
namespace)::InProcessThinBackend::runThinLTOBackendThread(std::function > (unsigned int)>,
std::function > (unsigned int)> (unsigned
int, llvm::StringRef)>, unsigned int, llvm::BitcodeModule,
llvm::ModuleSummaryIndex&, llvm::StringMap, std::allocator > >, llvm::MallocAllocator> const&, std::unordered_set, std::equal_to,
std::allocator > const&, std::map,
std::allocator
> > const&, llvm::DenseMap, llvm::detail::DenseMapPair > const&, llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&,
llvm::DenseMap, std::allocator > const, llvm::TypeIdSummary>
const*>, llvm::DenseMapInfo, llvm::detail::DenseMapPair, std::allocator > const, llvm::TypeIdSummary>
const*> > >
const&)::{lambda(std::function > (unsigned
int)>)#1}::operator()(std::function > (unsigned int)>) const
/home/inglorion/llvm/llvm/lib/LTO/LTO.cpp:937 (lld+0x12c5847)
#13 runThinLTOBackendThread /home/inglorion/llvm/llvm/lib/LTO/LTO.cpp:956
(lld+0x12c54d9)
#14 operator() /home/inglorion/llvm/llvm/lib/LTO/LTO.cpp:980
(lld+0x12c54d9)
#15 __invoke_impl, std::allocator > >, llvm::MallocAllocator> &, const
std::unordered_set,
std::equal_to, std::allocator > &, co
[llvm-bugs] [Bug 31052] ThinLTO + switch table + O2 cause undefined symbols
https://bugs.llvm.org/show_bug.cgi?id=31052 Teresa Johnson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Teresa Johnson --- This was fixed by r288446. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36910] Incorrect deduplication of MergeInputSection's
https://bugs.llvm.org/show_bug.cgi?id=36910 Rui Ueyama changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |FIXED --- Comment #2 from Rui Ueyama --- Fixed in https://reviews.llvm.org/rL328624 by Andrew Ng. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36347] [AMDGPU][MC] Improve disassembler error handling
https://bugs.llvm.org/show_bug.cgi?id=36347 Tim Corringham changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Tim Corringham --- Review https://reviews.llvm.org/D44685 Implemented by commit https://reviews.llvm.org/rL328553 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36809] ppc64le fp128 instruction selection issue
https://bugs.llvm.org/show_bug.cgi?id=36809 l...@ca.ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from l...@ca.ibm.com --- Clean with rl328620 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36921] New: [MSVC compatibility] Compiled executable crashes when using multiple virtual bases
https://bugs.llvm.org/show_bug.cgi?id=36921
Bug ID: 36921
Summary: [MSVC compatibility] Compiled executable crashes when
using multiple virtual bases
Product: clang
Version: 6.0
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: bu...@tresorit.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20135
--> https://bugs.llvm.org/attachment.cgi?id=20135&action=edit
Minimal C++ source that produces the bug
Clang for Windows with MSVC 2017.
Consider the following source code:
struct A {
virtual ~A() {}
};
struct B {
virtual ~B() {}
};
struct C : virtual B {};
struct D : virtual A, C {};
int main()
{
delete new D;
}
Running:
$ clang source.cpp
from x64 Native Command Prompt for VS 2017 results in an executable that
crashes upon startup.
We've examined the generated output and found that, when the compiler generates
code for the destructors of `D` and its virtual base classes, the compiler
miscalculates the base offset of the `this` pointer for the virtual base class
`A`, it sets 16 instead of 8.
Here is the constructor of D:
"??0D@@QEAA@XZ":# @"\01??0D@@QEAA@XZ"
.LBB1_2:
xor edx, edx
mov rax, qword ptr [rsp + 56] # 8-byte Reload
mov rcx, rax
call"??0C@@QEAA@XZ"
lea rcx, [rip + "??_7D@@6BC@@@"]
lea r8, [rip + "??_7D@@6BA@@@"]
mov r9, qword ptr [rsp + 56] # 8-byte Reload
mov r10, qword ptr [r9]
movsxd r10, dword ptr [r10 + 8]
add r10, 0
mov qword ptr [r9 + r10], r8 # sets A's vtable to ??_7D@@6BA@@@
mov r8, qword ptr [r9]
movsxd r8, dword ptr [r8 + 4]
add r8, 0
mov qword ptr [r9 + r8], rcx
mov rcx, qword ptr [rsp + 80]
mov qword ptr [rsp + 32], rax # 8-byte Spill
# sets B/C's vtable to ??_7D@@6BC@@@
mov rax, rcx
add rsp, 88
ret
Vtable:
.globl "??_7D@@6BA@@@"
"??_7D@@6BA@@@" = .L__unnamed_1+8
.L__unnamed_1:
.quad "??_R4D@@6BA@@@"
.quad "??_GD@@UEAAPEAXI@Z"
Generated destructor for A:
"??_GD@@UEAAPEAXI@Z": # @"\01??_GD@@UEAAPEAXI@Z"
.seh_proc "??_GD@@UEAAPEAXI@Z"
# %bb.0:
sub rsp, 72
.seh_stackalloc 72
.seh_endprologue
mov dword ptr [rsp + 60], edx
mov qword ptr [rsp + 48], rcx
mov rcx, qword ptr [rsp + 48]
add rcx, -16 # note offset is 16 here
mov rax, rcx
mov qword ptr [rsp + 64], rax
mov edx, dword ptr [rsp + 60]
mov qword ptr [rsp + 40], rcx # 8-byte Spill
mov dword ptr [rsp + 36], edx # 4-byte Spill
call"??_DD@@QEAAXXZ"
mov edx, dword ptr [rsp + 36] # 4-byte Reload
cmp edx, 0
je .LBB5_2
But in the dumped record layout, A is at offset 8:
*** Dumping AST Record Layout
0 | struct A
0 | (A vftable pointer)
| [sizeof=8, align=8,
| nvsize=8, nvalign=8]
*** Dumping AST Record Layout
0 | struct B
0 | (B vftable pointer)
| [sizeof=8, align=8,
| nvsize=8, nvalign=8]
*** Dumping AST Record Layout
0 | struct C
0 | (C vbtable pointer)
8 | struct B (virtual base)
8 | (B vftable pointer)
| [sizeof=16, align=8,
| nvsize=8, nvalign=8]
*** Dumping AST Record Layout
0 | struct D
0 | struct C (base)
0 | (C vbtable pointer)
8 | struct A (virtual base)
8 | (A vftable pointer)
16 | struct B (virtual base)
16 | (B vftable pointer)
| [sizeof=24, align=8,
| nvsize=8, nvalign=8]
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4908 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Null-dereference READ in llvm::IRMutator::mutateModule
Updates: Labels: Deadline-Approaching Comment #7 on issue 4908 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-gisel: Null-dereference READ in llvm::IRMutator::mutateModule https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4908#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 4882 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Out-of-memory in llvm_llvm-isel-fuzzer--x86_64-O2
Updates: Labels: Deadline-Approaching Comment #4 on issue 4882 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--x86_64-O2: Out-of-memory in llvm_llvm-isel-fuzzer--x86_64-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4882#c4 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36920] New: Possible miscompilation by Xcode 9.2 clang on x86_64
https://bugs.llvm.org/show_bug.cgi?id=36920 Bug ID: 36920 Summary: Possible miscompilation by Xcode 9.2 clang on x86_64 Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: bspen...@blackberry.com CC: llvm-bugs@lists.llvm.org The version of clang included in Xcode 9.2 appears to miscompile the minimal test case program linked to below. When optimizing (-O2 or better) with debugging information enabled (with -g), the following program triggers a "double-free" error from the macOS memory allocator. https://github.com/b-spencer/xcode9.2-clang-miscompile Changing the shape of the code in many small ways, or removing any of the steps in the `broken()` function seems to avoid the bug. I haven't spent a lot of time examining the unwind tables or the disassembly, but it seems that during exception unwinding, the uncaught exception propagating out of `broken()` ends up trying to free the memory already deallocated when `std::unique_ptr thing` was reassigned on line 22 of `main.cc`. This bug manifests itself when targeting macOS x86_64 or the iOS x86_64 simulator, at least. The expected outcome is as follows: ``` $ make clean all && ./prog construct Thing=0x7fe7a0c002e0 construct Thing=0x7fe7a0c00340 destroy Thing=0x7fe7a0c002e0 destroy Thing=0x7fe7a0c00340 Pass ``` The actual outcome is: ``` $ make clean all && ./prog construct Thing=0x7f86434002e0 construct Thing=0x7f8643400340 destroy Thing=0x7f86434002e0 destroy Thing=0x7f8643400340 prog(42802,0x7fffb3c6b3c0) malloc: *** error for object 0x7f86434002e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap: 6 ``` The program is annotated with comments that mention some of the changes that can be made that cause the bug to be avoided. Running UBSan or ASan finds no problems in the program, but also avoids triggering the bug. (So does removing debug info by not passing `-g`, or by limiting debug info to line number information only.) The same program works on Xcode 8 as well as with other versions of clang and various other compilers on other operating systems. The clang used is the version that comes with Xcode 9.2. It self-reports its version as follows: ``` Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ``` This bug has been cross posted as https://bugreport.apple.com/web/?problemID=38868843 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36919] New: [Formatter/ObjC] ObjC dict literals do not obey SpacesInContainerLiterals
https://bugs.llvm.org/show_bug.cgi?id=36919
Bug ID: 36919
Summary: [Formatter/ObjC] ObjC dict literals do not obey
SpacesInContainerLiterals
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: bhamilto...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Running clang-format from r327805, Objective-C dictionary literals should
follow the same spacing rules as array literals, but they only apply spaces
around the colons, not after { and before }:
% echo '@[@"a", @"b", @"c"]' | clang-format -style '{SpacesInContainerLiterals:
true}'
@[ @"a", @"b", @"c" ]
% echo '@[@"a", @"b", @"c"]' | clang-format -style '{SpacesInContainerLiterals:
false}'
@[@"a", @"b", @"c"]
% echo '@{@"a": @"b", @"c": @"d"}' | clang-format -style
'{SpacesInContainerLiterals: true}'
@{@"a" : @"b", @"c" : @"d"}
% echo '@{@"a": @"b", @"c": @"d"}' | clang-format -style
'{SpacesInContainerLiterals: false}'
@{@"a": @"b", @"c": @"d"}
I would expect the third to be:
@{ @"a" : @"b", @"c" : @"d" }
or maybe:
@{ @"a": @"b", @"c": @"d" }
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36766] Namespaces with one function declaration get formatted incorrectly
https://bugs.llvm.org/show_bug.cgi?id=36766 Krasimir changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36918] New: Factorial function gets over-vectorized and slower with -O2
https://bugs.llvm.org/show_bug.cgi?id=36918
Bug ID: 36918
Summary: Factorial function gets over-vectorized and slower
with -O2
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: naslu...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Consider a simple factorial function with tail recursion:
```
int factorial(int n)
{
if (n <= 0) return 1;
return n * factorial(n - 1);
}
```
Compiling with -O2 on clang++ produces a lot of code compared to -O1, -Os, or
any of these flags on gcc. This holds for at least versions 3.8 and onwards.
A comparison can be found here: https://godbolt.org/g/fbztqo
Basic performance tests on Ubuntu 16.04 (core i7-6700 CPU) also shows the
non-super-vectorized version is considerably slower, at least for all values
that don't lead to overflow. The clang binary is also slightly larger.
I would expect clang to not attempt this "optimization".
Note: Using -Os gives a result almost identical to gcc with -O2.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36917] New: clang frontend command failed due to signal
https://bugs.llvm.org/show_bug.cgi?id=36917
Bug ID: 36917
Summary: clang frontend command failed due to signal
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: zhangju...@ict.ac.cn
CC: llvm-bugs@lists.llvm.org
I am try to compile the 401.bzip2 using the following commands:
COMP_CONF = -DSPEC_CPU -DNDEBUG -O2 -fno-strict-aliasing -DSPEC_CPU_LP64
-emit-llvm -c
comp_bc:
clang ${COMP_CONF} spec.c -o spec.bc
clang ${COMP_CONF} blocksort.c -o blocksort.bc
clang ${COMP_CONF} bzip2.c -o bzip2.bc
clang ${COMP_CONF} bzlib.c -o bzlib.bc
clang ${COMP_CONF} compress.c -o compress.bc
clang ${COMP_CONF} crctable.c -o crctable.bc
clang ${COMP_CONF} decompress.c -o decompress.bc
clang ${COMP_CONF} huffman.c -o huffman.bc
clang ${COMP_CONF} randtable.c -o randtable.bc
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36916] New: [possible regression] Supplying a builtin as a template argument
https://bugs.llvm.org/show_bug.cgi?id=36916 Bug ID: 36916 Summary: [possible regression] Supplying a builtin as a template argument Product: clang Version: 6.0 Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: y...@tsoft.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 20133 --> https://bugs.llvm.org/attachment.cgi?id=20133&action=edit testcase.cpp The attached testcase worked up to and including clang5, but breaks in clang6: testcase.cpp:18:15: error: no matching function for call to 'v4f_map' v4f_t x = v4f_map<__builtin_sinf> (w); ^~~ x.cpp:6:7: note: candidate template ignored: invalid explicitly-specified argument for template parameter 'fn' v4f_t v4f_map (v4f_t x) ^ 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 7148 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in TemplateArgs::printLeft
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 7148 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in TemplateArgs::printLeft https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7148#c3 ClusterFuzz testcase 6239312493412352 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 7144 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in FunctionType::printRight
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 7144 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in FunctionType::printRight https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7144#c3 ClusterFuzz testcase 5132098177335296 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 7144 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in FunctionType::printRight
Comment #2 on issue 7144 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in FunctionType::printRight https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7144#c2 ClusterFuzz has detected this issue as fixed in range 201803260521:201803270519. Detailed report: https://oss-fuzz.com/testcase?key=5132098177335296 Project: llvm Fuzzer: libFuzzer_llvm_llvm-demangle-fuzzer Fuzz target binary: llvm-demangle-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdfe788f98 Crash State: FunctionType::printRight Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201803250525:201803260521 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201803260521:201803270519 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5132098177335296 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 7148 in oss-fuzz: llvm/llvm-demangle-fuzzer: Stack-overflow in TemplateArgs::printLeft
Comment #2 on issue 7148 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Stack-overflow in TemplateArgs::printLeft https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7148#c2 ClusterFuzz has detected this issue as fixed in range 201803260521:201803270519. Detailed report: https://oss-fuzz.com/testcase?key=6239312493412352 Project: llvm Fuzzer: libFuzzer_llvm_llvm-demangle-fuzzer Fuzz target binary: llvm-demangle-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd84722f88 Crash State: TemplateArgs::printLeft NameWithTemplateArgs::printLeft Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201803250525:201803260521 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201803260521:201803270519 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6239312493412352 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
