[llvm-bugs] [Bug 48354] New: clang crashes on "-v --target=powerpc-apple-darwin8 --print-supported-cpus"
https://bugs.llvm.org/show_bug.cgi?id=48354 Bug ID: 48354 Summary: clang crashes on "-v --target=powerpc-apple-darwin8 --print-supported-cpus" Product: clang Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: crabbedhaloablut...@icloud.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk saga ~ # clang-11 -v --target=powerpc-apple-darwin8 --print-supported-cpus clang version 11.0.0 Target: powerpc-apple-darwin8 Thread model: posix InstalledDir: /usr/lib/llvm/11/bin (in-process) "/usr/lib/llvm/11/bin/clang-11" -cc1 -triple powerpc-apple-darwin8 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -fsyntax-only -disable-free -disable-llvm-verifier -discard-value-names -main-file-name -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-rounding-math -munwind-tables -faligned-alloc-unavailable -fcompatibility-qualified-id-block-type-checking -target-cpu ppc -mfloat-abi hard -fno-split-dwarf-inlining -debugger-tuning=lldb -v -resource-dir /usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0 -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm/11/bin/../../../../lib/clang/11.0.0/include -internal-externc-isystem /usr/include -fdebug-compilation-dir /root -ferror-limit 19 -fblocks -fblocks-runtime-optional -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -fcolor-diagnostics -faddrsig -x c --print-supported-cpus LLVM ERROR: Darwin is no longer supported for PowerPC PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: clang-11 -v --target=powerpc-apple-darwin8 --print-supported-cpus #0 0x7fc04c45e30a llvm::sys::PrintStackTrace(llvm::raw_ostream&) /usr/src/debug/sys-devel/llvm-11.0.0/llvm/lib/Support/Unix/Signals.inc:568:3 #1 0x7fc04c45c544 llvm::sys::RunSignalHandlers() /usr/src/debug/sys-devel/llvm-11.0.0/llvm/lib/Support/Signals.cpp:68:20 #2 0x7fc04c38bad8 HandleCrash /usr/src/debug/sys-devel/llvm-11.0.0/llvm/lib/Support/CrashRecoveryContext.cpp:77:5 #3 0x7fc04c38bad8 CrashRecoverySignalHandler /usr/src/debug/sys-devel/llvm-11.0.0/llvm/lib/Support/CrashRecoveryContext.cpp:382:62 #4 0x7fc04b4ec2f0 (/lib64/libc.so.6+0x392f0) #5 0x7fc04b4ec271 raise /usr/src/debug/sys-libs/glibc-2.32-r3/glibc-2.32/signal/../sysdeps/unix/sysv/linux/raise.c:50:1 #6 0x7fc04b4d5536 abort /usr/src/debug/sys-libs/glibc-2.32-r3/glibc-2.32/stdlib/abort.c:81:7 #7 0x7fc04c39b27a llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl&) /usr/src/debug/sys-devel/llvm-11.0.0/llvm/include/llvm/Support/raw_ostream.h:566:64 #8 0x7fc04c39b27a llvm::report_fatal_error(llvm::Twine const&, bool) /usr/src/debug/sys-devel/llvm-11.0.0/llvm/lib/Support/ErrorHandling.cpp:114:34 #9 0x7fc04c39b3b5 (/usr/lib/llvm/11/bin/../lib64/libLLVM-11.so+0xa613b5) #10 0x7fc04e6528ac computeTargetABI /usr/src/debug/sys-devel/llvm-11.0.0/llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:202:23 #11 0x7fc04e6528ac llvm::PPCTargetMachine::PPCTargetMachine(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optional, llvm::Optional, llvm::CodeGenOpt::Level, bool) /usr/src/debug/sys-devel/llvm-11.0.0/llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:313:33 #12 0x7fc04e652cdc llvm::RegisterTargetMachine::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optional, llvm::Optional, llvm::CodeGenOpt::Level, bool) /usr/src/debug/sys-devel/llvm-11.0.0/llvm/include/llvm/Support/TargetRegistry.h:1121:12 #13 0x560b32bd21da std::__cxx11::basic_string, std::allocator >::_M_data() const /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/bits/basic_string.h:187:28 #14 0x560b32bd21da std::__cxx11::basic_string, std::allocator >::_M_is_local() const /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/bits/basic_string.h:222:23 #15 0x560b32bd21da std::__cxx11::basic_string, std::allocator >::_M_dispose() /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/bits/basic_string.h:231:18 #16 0x560b32bd21da std::__cxx11::basic_string, std::allocator >::~basic_string() /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10/bits/basic_string.h:658:19 #17 0x560b32bd21da llvm::Triple::~Triple() /usr/lib/llvm/11/include/llvm/ADT/Triple.h:45:7 #18 0x560b32bd21da llvm::Target::createTargetMachine(llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optional, llvm::Optional, llvm::CodeGenOpt::Level, bool) const /usr/lib/llvm/11/include/llvm/Supp
[llvm-bugs] [Bug 48355] New: LSR produces worse assembly than without LSR
https://bugs.llvm.org/show_bug.cgi?id=48355
Bug ID: 48355
Summary: LSR produces worse assembly than without LSR
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: max.kazant...@azul.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Test: test/CodeGen/X86/2020_12_02_decrementing_loop.ll
IR:
define i32 @test(i32* %p, i64 %len, i32 %x) {
entry:
br label %loop
loop: ; preds = %backedge, %entry
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%iv.next = add nsw i64 %iv, -1
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %backedge
backedge: ; preds = %loop
%addr = getelementptr inbounds i32, i32* %p, i64 %iv.next
%loaded = load atomic i32, i32* %addr unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
br i1 %cond_2, label %failure, label %loop
exit: ; preds = %loop
ret i32 -1
failure: ; preds = %backedge
unreachable
}
Current asm:
LBB0_1: ## %loop
## =>This Inner Loop Header: Depth=1
subq$1, %rax
jb LBB0_4
## %bb.2: ## %backedge
## in Loop: Header=BB0_1 Depth=1
cmpl%edx, -4(%rdi,%rsi,4)
movq%rax, %rsi
jne LBB0_1
When LSR is disabled:
LBB0_1: ## %loop
## =>This Inner Loop Header: Depth=1
subq$1, %rsi
jb LBB0_4
## %bb.2: ## %backedge
## in Loop: Header=BB0_1 Depth=1
cmpl%edx, (%rdi,%rsi,4)
jne LBB0_1
A redundant move is generated when LSR decides to replace use of iv.next with
use of iv in the gep.
--
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 48357] New: Crash when building arm64 Linux kernel with --emit-relocs
https://bugs.llvm.org/show_bug.cgi?id=48357
Bug ID: 48357
Summary: Crash when building arm64 Linux kernel with
--emit-relocs
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: david.braz...@gmail.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
Hi,
I've been experimenting with relocs in the arm64 Linux kernel and managed to
get an LLD crash.
Checked llvm-project ToT (commit e0bf2349303f6b40e3ddd5377ea08a5c0867ece4) and
it still happens there.
>From quick debugging, it is a null-pointer `first` in
lld/ELF/OutputSections.cpp, OutputSection::finalize():
```
if (!config->copyRelocs || (type != SHT_RELA && type != SHT_REL))
return;
if (isa(first)) // HERE
return;
link = in.symTab->getParent()->sectionIndex;
```
The kernel is v5.10-rc1 built with `CONFIG_RELOCATABLE=n` and the following
diff:
```
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5789c2d18d43..aa68f6b6524a 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -18,6 +18,8 @@ ifeq ($(CONFIG_RELOCATABLE), y)
# with the relocation offsets always being zero.
LDFLAGS_vmlinux+= -shared -Bsymbolic -z notext \
$(call ld-option, --no-apply-dynamic-relocs)
+else
+LDFLAGS_vmlinux+= --emit-relocs
endif
ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
```
The crash:
+ ld.lld -EL -maarch64elf --no-undefined -X -z norelro --emit-relocs
--fix-cortex-a53-843419 --orphan-handling=warn --build-id=sha1 --strip-debug -o
.tmp_vmlinux.kallsyms1 -T ./arch/arm64/kernel/vmlinux.lds --whole-archive
arch/arm64/kernel/head.o init/built-in.a usr/built-in.a arch/arm64/built-in.a
kernel/built-in.a certs/built-in.a mm/built-in.a fs/built-in.a ipc/built-in.a
security/built-in.a crypto/built-in.a block/built-in.a
arch/arm64/lib/built-in.a lib/built-in.a arch/arm64/lib/lib.a lib/lib.a
drivers/built-in.a sound/built-in.a net/built-in.a virt/built-in.a
--no-whole-archive --start-group ./drivers/firmware/efi/libstub/lib.a
--end-group
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: ld.lld -EL -maarch64elf --no-undefined -X -z norelro
--emit-relocs --fix-cortex-a53-843419 --orphan-handling=warn --build-id=sha1
--strip-debug -o .tmp_vmlinux.kallsyms1 -T ./arch/arm64/kernel/vmlinux.lds
--whole-archive arch/arm64/kernel/head.o init/built-in.a usr/built-in.a
arch/arm64/built-in.a kernel/built-in.a certs/built-in.a mm/built-in.a
fs/built-in.a ipc/built-in.a security/built-in.a crypto/built-in.a
block/built-in.a arch/arm64/lib/built-in.a lib/built-in.a arch/arm64/lib/lib.a
lib/lib.a drivers/built-in.a sound/built-in.a net/built-in.a virt/
built-in.a --no-whole-archive --start-group
./drivers/firmware/efi/libstub/lib.a --end-group
#0 0x0162fa63 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x162fa63)
#1 0x0162d9be llvm::sys::RunSignalHandlers()
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x162d9be)
#2 0x016301f5 SignalHandler(int)
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x16301f5)
#3 0x7fc459efa140 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
#4 0x017b8e7e lld::elf::OutputSection::finalize()
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x17b8e7e)
#5 0x018eca68 (anonymous
namespace)::Writer
>::finalizeSections()
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x18eca68)
#6 0x018b868b void
lld::elf::writeResult
>() (/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x18b868b)
#7 0x0170fad6 void
lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&)
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x170fad6)
#8 0x017008e1 lld::elf::LinkerDriver::main(llvm::ArrayRef)
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x17008e1)
#9 0x016fe15f lld::elf::link(llvm::ArrayRef, bool,
llvm::raw_ostream&, llvm::raw_ostream&)
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x16fe15f)
#10 0x0159be55 lldMain(int, char const**, llvm::raw_ostream&,
llvm::raw_ostream&, bool)
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x159be55)
#11 0x0159b6c0 main
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x159b6c0)
#12 0x7fc4599eccca __libc_start_main ./csu/../csu/libc-start.c:308:16
#13 0x0159b3ba _start
(/usr/local/google/home/dbrazdil/dev/tc-build/install/bin/lld+0x159b3ba)
../scripts/link-vmlinux.sh: line 89: 43038 Segmentation fault ${LD}
${KBUILD_LDFLAGS} ${LDFLAGS_vmlinux} ${strip_debug#-Wl,} -o ${output}
[llvm-bugs] [Bug 48358] New: [analyzer] Plist macro-expansion crash
https://bugs.llvm.org/show_bug.cgi?id=48358
Bug ID: 48358
Summary: [analyzer] Plist macro-expansion crash
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: benicsbal...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 24225
--> https://bugs.llvm.org/attachment.cgi?id=24225&action=edit
complete stack trace
Here is the minimal repro (attached patch file):
```
// RUN: %clang_analyze_cc1 -analyzer-checker=core %s \
// RUN: -analyzer-output=plist -o %t.plist \
// RUN: -analyzer-config expand-macros=true
#define STRANGE_FN(x) STRANGE_FN(x, 0)
void test_strange_macro_expansion() {
char *path;
STRANGE_FN(path); // no-crash
// expected-warning@-1 {{implicit declaration of function}}
// expected-warning@-2 {{1st function call argument is an uninitialized
value}}
}
// CHECK: nameSTRANGE_FN
// CHECK-NEXT: expansionSTRANGE_FN(path, 0)
```
Analyzer call (debug build):
```
./bin/clang -cc1 -internal-isystem
git/llvm-project/build/debug/lib/clang/12.0.0/include -nostdsysteminc -analyze
-analyzer-constraints=range -setup-static-analyzer -analyzer-checker=core
git/llvm-project/clang/test/Analysis/plist-macros-with-expansion.c
-analyzer-output=plist -o tmp.plist-analyzer-config expand-macros=true
```
Assertion triggered:
```
clang: ../../clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1261:
{anonymous}::MacroExpansionInfo getMacroExpansionInfo(const
{anonymous}::MacroParamMap&, clang::SourceLocation, const
clang::Preprocessor&): Assertion `TheTok.is(tok::r_paren) && "Expanded macro
argument acquisition failed! After the end of the loop" " this token should be
')'!"' failed.
```
Relevant part of the backtrace:
```
#9 0x7efe6fb5cf77 getMacroExpansionInfo((anonymous
namespace)::MacroParamMap const&, clang::SourceLocation, clang::Preprocessor
const&)
git/llvm-project/build/debug/../../clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1259:0
#10 0x7efe6fb5c2ba getMacroNameAndPrintExpansion((anonymous
namespace)::TokenPrinter&, clang::SourceLocation, clang::Preprocessor const&,
(anonymous namespace)::MacroParamMap const&,
llvm::SmallPtrSet&)
git/llvm-project/build/debug/../../clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1015:0
#11 0x7efe6fb5c4d9 getMacroNameAndPrintExpansion((anonymous
namespace)::TokenPrinter&, clang::SourceLocation, clang::Preprocessor const&,
(anonymous namespace)::MacroParamMap const&,
llvm::SmallPtrSet&)
git/llvm-project/build/debug/../../clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1050:0
#12 0x7efe6fb5c108 getExpandedMacro(clang::SourceLocation,
clang::Preprocessor const&, clang::cross_tu::CrossTranslationUnitContext
const&)
git/llvm-project/build/debug/../../clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1002:0
#13 0x7efe6fb59900 (anonymous
namespace)::PlistPrinter::ReportMacroExpansions(llvm::raw_ostream&, unsigned
int)
git/llvm-project/build/debug/../../clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:393:0
#14 0x7efe6fb5a783 (anonymous
namespace)::PlistDiagnostics::printBugPath(llvm::raw_ostream&,
llvm::DenseMap,
llvm::detail::DenseMapPair > const&,
clang::ento::PathPieces const&)
git/llvm-project/build/debug/../../clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:603:0
```
Full trace attached.
Besides this, I've observed that the handwritten macro expansion in plist
diagnostics is non-conformant. There are several examples where it produces the
wrong expansion.
Such as for this:
- for the generated plist: https://godbolt.org/z/YhE8zY
- for the expected macro expansions:
https://cppinsights.io/lnk?code=dm9pZCBjbGFuZ19hbmFseXplcl93YXJuSWZSZWFjaGVkKCk7CgoKI2RlZmluZSByZXRBcmcoeCkgeAojZGVmaW5lIHJldEFyZ1VuY2xvc2VkIHJldEFyZyhjbGFuZ19hbmFseXplcl93YXJuSWZSZWFjaGVkKCkKCgojZGVmaW5lIEJCIENDCiNkZWZpbmUgYXBwbHlJbnQgQkIoaW50KQojZGVmaW5lIENDKHgpIHJldEFyZ1VuY2xvc2VkCgoKdm9pZCB1bmJhbGFuY2VkTWFjcm9zKCkgewogIGFwcGx5SW50ICk7Cn0KCiNkZWZpbmUgZXhwYW5kQXJnVW5jbG9zZWRDb21tYUV4cHIoeCkgKHgsIGNsYW5nX2FuYWx5emVyX3dhcm5JZlJlYWNoZWQoKSwgMQojZGVmaW5lIGYgZXhwYW5kQXJnVW5jbG9zZWRDb21tYUV4cHIKCnZvaWQgdW5iYWxhbmNlZE1hY3JvczIoKSB7CiAgaW50IHggPSAgZihmKDEpKSAgKSk7Cn0=&std=cpp2a&rev=1.0
The code:
```
void clang_analyzer_warnIfReached();
#define retArg(x) x
#define retArgUnclosed retArg(clang_analyzer_warnIfReached()
#define BB CC
#define applyInt BB(int)
#define CC(x) retArgUnclosed
void unbalancedMacros() {
applyInt );
}
#define expandArgUnclosedCommaExpr(x) (x, clang_analyzer_warnIfReached(), 1
#define f expandArgUnclosedCommaExpr
void unbalancedMacros2() {
int x = f(f(1)) )); // note the 'extra' rparens.
}
```
The code contains no typos, the parens are deliberately not matching at each
context.
Besides these bugs, I'm expecting many more - even crashing o
[llvm-bugs] [Bug 48360] New: Lack of visibility specification on forward declaration of class template may hide derived symbols
https://bugs.llvm.org/show_bug.cgi?id=48360
Bug ID: 48360
Summary: Lack of visibility specification on forward
declaration of class template may hide derived symbols
Product: clang
Version: trunk
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
Take a look at the following program
#include
template
class PublicTemplateClass;
class [[gnu::visibility("default")]] D {};
class E
{
PublicTemplateClass f ();
};
template
class [[gnu::visibility("default")]] PublicTemplateClass
{
};
PublicTemplateClass E::f ()
{
PublicTemplateClass v;
std::any a (v);
return v;
}
Running the following command:
clang++ -fvisibility=hidden -std=c++17 -shared -fPIC a.cpp && readelf -s a.out
| grep Manager
I see the following output:
15: 1c7039 FUNCLOCAL HIDDEN12
_ZNSt3any17_Manager_inter
16: 1b90 178 FUNCLOCAL HIDDEN12
_ZNSt3any17_Manager_inter
Manager...thingie is basically a function pointer which is compared in any_cast
in libstdc++. So the problem is that when it's hidden any_cast to correct type
will fail because user of the library will have different pointer to this
function.
If however I add [[gnu::visibility("default")]] to forward declaration of
PublicTemplateClass like this:
template
class [[gnu::visibility("default")]] PublicTemplateClass;
I receive the following:
10: 1ef0 178 FUNCWEAK DEFAULT 12
_ZNSt3any17_Manager_inter
13: 1fd039 FUNCWEAK DEFAULT 12
_ZNSt3any17_Manager_inter
28: 1fd039 FUNCWEAK DEFAULT 12
_ZNSt3any17_Manager_inter
29: 1ef0 178 FUNCWEAK DEFAULT 12
_ZNSt3any17_Manager_inter
I'm not 100% sure that this is not intended behavior but this seems to be very
unfortunate because:
1. Error is very subtle, hard to find, runtime only &c.
2. gcc does not behave like this
3. Normal classes do not seem to trigger such behavior with requiring
visibility specification for forward declarations.
If you need me to built full fledged example where executable + so lib fail to
perform any cast in such case I would be happy to provide that but I hope the
problem is already clear from this short sample.
--
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 48361] New: foo@v1 and foo@@v1 aren't handled properly
https://bugs.llvm.org/show_bug.cgi?id=48361
Bug ID: 48361
Summary: foo@v1 and foo@@v1 aren't handled properly
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: hjl.to...@gmail.com
CC: i...@maskray.me, llvm-bugs@lists.llvm.org,
smithp...@googlemail.com
[hjl@gnu-cfl-2 pr26978]$ cat main.c
extern void foo (void);
int
main ()
{
foo ();
return 0;
}
[hjl@gnu-cfl-2 pr26978]$ cat ver
v1 {};
[hjl@gnu-cfl-2 pr26978]$ cat def1w.s
.text
.weak foo
.symver foo, foo@@@v1
.type foo, %object
foo:
hlt
[hjl@gnu-cfl-2 pr26978]$ cat hid1.s
.text
.globl foo_v1
.symver foo_v1, foo@v1
.type foo_v1, %object
foo_v1:
ret
[hjl@gnu-cfl-2 pr26978]$
ld correctly rejects:
[hjl@gnu-cfl-2 pr26978]$ make
cc-c -o main.o main.c
as -o def1w.o def1w.s
as -o hid1.o hid1.s
ld -shared -o libfoo.so --version-script=ver def1w.o hid1.o
ld: hid1.o:(.text+0x0): multiple definition of `foo@v1'
ld: hid1.o:(*IND*+0x0): multiple definition of `foo'
make: *** [Makefile:10: libfoo.so] Error 1
[hjl@gnu-cfl-2 pr26978]$
lld generates a bogus libfoo.so:
[hjl@gnu-cfl-2 pr26978]$ make LD=ld.lld
ld.lld -shared -o libfoo.so --version-script=ver def1w.o hid1.o
cc -o x main.o libfoo.so -Wl,-R,.
/usr/local/bin/ld: libfoo.so:(.text+0x1): multiple definition of `foo@v1'
/usr/local/bin/ld: libfoo.so:(*IND*+0x0): multiple definition of `foo'
collect2: error: ld returned 1 exit status
make: *** [Makefile:7: x] Error 1
[hjl@gnu-cfl-2 pr26978]$
[hjl@gnu-cfl-2 pr26978]$ readelf --dyn-syms libfoo.so
Symbol table '.dynsym' contains 4 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 130d 0 OBJECT WEAK DEFAULT7 foo@@v1
2: 130e 0 OBJECT GLOBAL DEFAULT7 foo_v1
3: 130e 0 OBJECT GLOBAL DEFAULT7 foo@v1
[hjl@gnu-cfl-2 pr26978]$
foo@@v1 and foo@v1 define the same symbol. lld doesn't check the bogus
libfoo.so and let the weak definition to override the non-weak one:
[hjl@gnu-cfl-2 pr26978]$ cc -o x main.o libfoo.so -Wl,-R,. -fuse-ld=lld
[hjl@gnu-cfl-2 pr26978]$ ./x
Segmentation fault (core dumped)
[hjl@gnu-cfl-2 pr26978]$
--
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 34665] [AVX] wrong answer after SLP Vectorizer
https://bugs.llvm.org/show_bug.cgi?id=34665 Simon Pilgrim changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #3 from Simon Pilgrim --- (In reply to Simon Pilgrim from comment #2) > Is this still an issue? > > I can't repro against trunk but haven't managed to bisect a fix commit yet. Resolving - has worked in trunk for some time. https://godbolt.org/z/ePeonP This shows that it worked in 4.0.1, broke in 5.0.0 and was fixed in 6.0.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 34665] [AVX] wrong answer after SLP Vectorizer
https://bugs.llvm.org/show_bug.cgi?id=34665 Simon Pilgrim changed: What|Removed |Added Resolution|WORKSFORME |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 48362] New: opt -jump-threading hangs
https://bugs.llvm.org/show_bug.cgi?id=48362 Bug ID: 48362 Summary: opt -jump-threading hangs Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24227 --> https://bugs.llvm.org/attachment.cgi?id=24227&action=edit bbi-50589_reduced.ll reproducer Reproduce with: opt -o - bbi-50589_reduced.ll -S -jump-threading It doesn't seem to terminate. This starts happening after 5486e00dc3e3: [InstSimplify] remove poison-unsafe insertelement of undef value PR45481: https://bugs.llvm.org/show_bug.cgi?id=45481 SDAG has an identical transform to this, so there's little chance of any real-world impact. OTOH, that means we are effectively sweeping the bug out of sight because poison exists in codegen too. -- 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 48363] New: clang-format using over 5GB of RAM on a C file with many arrays
https://bugs.llvm.org/show_bug.cgi?id=48363 Bug ID: 48363 Summary: clang-format using over 5GB of RAM on a C file with many arrays Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: tma...@videolan.org CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Created attachment 24228 --> https://bugs.llvm.org/attachment.cgi?id=24228&action=edit Problematic source file I noticed that clang-format was running out of memory on a system with only 3.75GB available. It turns out that for a specific file (https://aomedia.googlesource.com/aom/+/c15883a29b9dc3c28caa03e22b7368ed8355d834/av1/common/quant_common.c) it is using over 5GB when invoked as follows: /usr/bin/time -v clang-format -i --style=file aom/av1/common/quant_common.c Command being timed: "clang-format -i --style=file aom/av1/common/quant_common.c" User time (seconds): 17.59 System time (seconds): 1.49 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:19.14 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 5479164< Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 1375531 Voluntary context switches: 2 Involuntary context switches: 136 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 The file in question is 12875 lines, and does contain a number of arrays, but this still seems like it shouldn't be quite so memory intensive. I've seen the same behavior with both clang 10 and 12. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 27686 in oss-fuzz: llvm: Fuzzing build failure
Comment #2 on issue 27686 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27686#c2 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-ad1a4aa4-ae4e-49c0-aa83-8f2af8489c27.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 48362] opt -jump-threading hangs
https://bugs.llvm.org/show_bug.cgi?id=48362 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||9d6d24c25 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- I suspect that we could have hit this bug with a less-undef test case even before 5486e00dc3e3. I don't know much about jumpthreading, so I put in a lower-level exit in the analysis that was getting tripped up: https://reviews.llvm.org/rG9d6d24c25056 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 47479, which changed state. Bug 47479 Summary: inlining of stack-protected functions into non-stack-protected functions dangerous https://bugs.llvm.org/show_bug.cgi?id=47479 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 47479] inlining of stack-protected functions into non-stack-protected functions dangerous
https://bugs.llvm.org/show_bug.cgi?id=47479 Nick Desaulniers changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Nick Desaulniers --- Ok, I backed out the previous patches that weren't cleanups, and went with a simpler approach based on feedback: https://reviews.llvm.org/rGbc044a88ee3c16e4164740732a7adc91a29b24f5 -- 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 25555 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: Out-of-memory in llvm-isel-fuzzer--aarch64-gisel
Updates: Labels: Deadline-Approaching Comment #1 on issue 2 by sheriffbot: llvm:llvm-isel-fuzzer--aarch64-gisel: Out-of-memory in llvm-isel-fuzzer--aarch64-gisel https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2#c1 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 48365] New: Compiler is using wrong template argument when a child class calls a templated constructor of a template class.
https://bugs.llvm.org/show_bug.cgi?id=48365
Bug ID: 48365
Summary: Compiler is using wrong template argument when a child
class calls a templated constructor of a template
class.
Product: libc++
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: nicolas.b...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The following code doesn't compile correctly:
<<
#include
template
struct CheckInt {
using success = std::bool_constant>;
static_assert(success());
};
template
class Base {
public:
template ::success>
Base(const U& v) {}
};
class Child : public Base {
public:
Child() : Base(1.0f) {}
};
int main()
{
Child child; // doesn't compile
//Base base(1.0f); // compiles
return 0;
}
>>
When instantiating Child, the static_assert() fires because U evaluates to
`Base` instead of `float`.
When instantiation Base directly, U evaluates to `float` correctly.
The compiler generates the following error:
"
:6:3: error: static_assert failed due to requirement
'std::integral_constant()'
static_assert(success());
^ ~
:12:47: note: in instantiation of template class 'CheckInt>'
requested here
template ::success>
"
The bug appears in all versions of clang (as well as gcc).
See https://godbolt.org/z/73c4Wd
--
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 48365] Compiler is using wrong template argument when a child class calls a templated constructor of a template class.
https://bugs.llvm.org/show_bug.cgi?id=48365
David Blaikie changed:
What|Removed |Added
Resolution|--- |INVALID
CC||dblai...@gmail.com
Status|NEW |RESOLVED
--- Comment #1 from David Blaikie ---
Looks reasonable to me - the rest of the error message says:
":13:5: note: in instantiation of default argument for
'Base>' required here
Base(const U& v) {
^~
:10:7: note: while substituting deduced template arguments into
function template 'Base' [with U = Base, $1 = (no value)]
class Base {
^
:17:7: note: while declaring the implicit copy constructor for 'Child'
class Child : public Base {
^"
So it's not while trying to evaluate "Child child;"'s call to the "Child()"
ctor, which does correctly use the Base::Base ctor, but it's while
trying to declare Child's copy ctor - which, is the absence of any other ctor,
tries to use Base::Base> to do the copy construction.
If you make the Base ctor not a valid ctor to use for copying (eg, by changing
its template parameter list to SFINAE out that option: "template >, typename = typename
CheckInt::success>") then the build error goes away.
https://godbolt.org/z/6fGjhd
Similarly, if the ctor in question had an extra parameter - there would be no
ambiguity: https://godbolt.org/z/oqGxhq
--
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 26472] x32: error in backend: Cannot select t145: ch, glue = X86ISD::TLSADDR t0, TargetGlobalTLSAddress:i32
https://bugs.llvm.org/show_bug.cgi?id=26472 Bug 26472 depends on bug 22676, which changed state. Bug 22676 Summary: PC-relative address isn't used for x32 https://bugs.llvm.org/show_bug.cgi?id=22676 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 22676] PC-relative address isn't used for x32
https://bugs.llvm.org/show_bug.cgi?id=22676 Harald van Dijk changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||18ce612353795da6838aade2b93 ||3503cbe3cf9b9 --- Comment #2 from Harald van Dijk --- Fixed by D16474. -- 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 48339] Bogus error/note about dependent base classes on template instantiation failure
https://bugs.llvm.org/show_bug.cgi?id=48339
Richard Smith changed:
What|Removed |Added
Fixed By Commit(s)||c4fb7720ceb30f25c38d994fb37
||5e4d1978de144
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Richard Smith ---
Now diagnosed as:
:11:5: error: no matching function for call to 'g'
g(typename T::type{});
^
:16:7: note: in instantiation of function template specialization
'S::f' requested here
S{}.f();
^
:7:15: note: candidate template ignored: couldn't infer template
argument 'T'
static void g(typename T::type) {}
^
1 error generated.
... as it should be.
--
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 48366] New: Random clang-format crash on Windows
https://bugs.llvm.org/show_bug.cgi?id=48366 Bug ID: 48366 Summary: Random clang-format crash on Windows Product: clang Version: 11.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: aminyahyaabad...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org ``` > clang-format -i src/core/*.cc src/core/*.h src/bindings/*.cc src/bindings/*.h > src/bindings/em/*.cc src/bindings/em/*.h PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: clang-format -i src/core/*.cc src/core/*.h src/bindings/*.cc src/bindings/*.h src/bindings/em/*.cc src/bindings/em/*.h #0 0x7ff657a1f651 C:\Program Files\LLVM\bin\clang-format.exe 0x5f651 C:\Program Files\LLVM\bin\clang-format.exe 0x60ec6 #1 0x7ff657a1f651 C:\Program Files\LLVM\bin\clang-format.exe 0xc15eb C:\Program Files\LLVM\bin\clang-format.exe 0x3f00 #2 0x7ff657a1f651 C:\Program Files\LLVM\bin\clang-format.exe 0x1ef6 C:\Program Files\LLVM\bin\clang-format.exe 0x153e44 #3 0x7ff657a1f651 (C:\Program Files\LLVM\bin\clang-format.exe+0x5f651) #4 0x7ff657a20ec6 (C:\Program Files\LLVM\bin\clang-format.exe+0x60ec6) 0x7FF657A1F651 (0x00D90C78F370 0x7FFFE62CE97B 0x0013 0x00D90C78E698) 0x7FF657A20EC6 (0xEA30D47F9ABB 0x7FF6 0x 0x025727292930) 0x7FF657A815EB (0x025727238C60 0x 0x025727239160 0x) 0x7FF6579C3F00 (0x02572721E490 0x7FFFE866786B 0x0015002B 0x7FFFE866786B) 0x7FF6579C1EF6 (0x 0x 0x 0x) 0x7FF657B13E44 (0x 0x 0x 0x) 0x7FFFE7057034 (0x 0x 0x 0x), BaseThreadInitThunk() + 0x14 bytes(s) 0x7FFFE869CEC1 (0x 0x 0x 0x), RtlUserThreadStart() + 0x21 bytes(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] Issue 28224 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: !isCompoundAssignmentOp() && "Use CompoundAssignOperator for compound assignment
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-03 Type: Bug New issue 28224 by ClusterFuzz-External: llvm:clang-objc-fuzzer: ASSERT: !isCompoundAssignmentOp() && "Use CompoundAssignOperator for compound assignment https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28224 Detailed Report: https://oss-fuzz.com/testcase?key=4899272751054848 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !isCompoundAssignmentOp() && "Use CompoundAssignOperator for compound assignment clang::BinaryOperator::Create clang::Sema::checkPseudoObjectAssignment Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011230606:202011240611 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4899272751054848 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] Issue 28225 in oss-fuzz: llvm:clang-format-fuzzer: ASSERT: !FormatTok->is(tok::l_brace)
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-03 Type: Bug New issue 28225 by ClusterFuzz-External: llvm:clang-format-fuzzer: ASSERT: !FormatTok->is(tok::l_brace) https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28225 Detailed Report: https://oss-fuzz.com/testcase?key=4743877613060096 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-format-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !FormatTok->is(tok::l_brace) clang::format::UnwrappedLineParser::parseStructuralElement clang::format::UnwrappedLineParser::parseStructuralElement Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201709130450:201709140449 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4743877613060096 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] Issue 28226 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupQualifiedName
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-03 Type: Bug New issue 28226 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::LookupQualifiedName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28226 Detailed Report: https://oss-fuzz.com/testcase?key=5647786230022144 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffea56898a0 Crash State: clang::Sema::LookupQualifiedName clang::Sema::DiagnoseEmptyLookup BuildRecoveryCallExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010250629:202010260620 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5647786230022144 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 48252] Adding an operator== breaks implicit operator== generation from defaulted <=>
https://bugs.llvm.org/show_bug.cgi?id=48252 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- Closing this for now: Clang's behavior is in line with the standard's rules (though those rules might be headed towards revision). -- 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 28228 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ParseSpecifierQualifierList
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-03 Type: Bug New issue 28228 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Parser::ParseSpecifierQualifierList https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28228 Detailed Report: https://oss-fuzz.com/testcase?key=6292991450546176 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff55f1af88 Crash State: clang::Parser::ParseSpecifierQualifierList clang::Parser::ParseBlockId clang::Parser::ParseBlockLiteralExpression Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202012020620 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6292991450546176 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
