[llvm-bugs] Issue 3725 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t"
Comment #2 on issue 3725 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3725#c2 ClusterFuzz has detected this issue as fixed in range 201710300453:201710310454. Detailed report: https://oss-fuzz.com/testcase?key=6457754349731840 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: getMinSignedBits() <= 64 && "Too many bits for int64_t" AddressingModeMatcher::matchOperationAddr AddressingModeMatcher::matchAddr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710300453:201710310454 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6457754349731840 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 3725 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 3725 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: getMinSignedBits() <= 64 && "Too many bits for int64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3725#c3 ClusterFuzz testcase 6457754349731840 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] [Bug 35144] New: -Wdocumentation produces false positive for \tparam with instantiated function
https://bugs.llvm.org/show_bug.cgi?id=35144 Bug ID: 35144 Summary: -Wdocumentation produces false positive for \tparam with instantiated function Product: clang Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: techmeol...@techmeology.co.uk CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 19363 --> https://bugs.llvm.org/attachment.cgi?id=19363&action=edit Reproducer Steps to reproduce: 1) Compile the `bug.cpp` with `clang++ -Wdocumentation -c bug.cpp` using Clang 5.0 2) Comment out line 7, and recompile as in step 1. Expected results: No warning should be emitted for either of the two steps above. Actual results: The following warning is emitted at step 1, but not step 2: bug.cpp:2:5: warning: '\tparam' command used in a comment that is not attached to a template declaration [-Wdocumentation] * \tparam T The type of the inputs' elements. ^~ 1 warning 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] [Bug 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 33858, which changed state. Bug 33858 Summary: libunwind tests fail on the 5.0 branch https://bugs.llvm.org/show_bug.cgi?id=33858 What|Removed |Added Status|REOPENED|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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33858] libunwind tests fail on the 5.0 branch
https://bugs.llvm.org/show_bug.cgi?id=33858 Renato Golin changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #51 from Renato Golin --- Merged in r316991. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35145] New: Unstable indentation of comments within #ifdef with IndentPPDirectives: AfterHash
https://bugs.llvm.org/show_bug.cgi?id=35145
Bug ID: 35145
Summary: Unstable indentation of comments within #ifdef with
IndentPPDirectives: AfterHash
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: mikhail.matro...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Format this code several times with -style="{IndentPPDirectives: AfterHash}":
#ifndef ASMINF
// comment
# ifdef POSTINC
# endif
#endif
See how indentation of the comment appears and disappears.
--
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 35146] New: dllexported classes don't emit typeinfo (often enough) in the itanium ABI
https://bugs.llvm.org/show_bug.cgi?id=35146
Bug ID: 35146
Summary: dllexported classes don't emit typeinfo (often enough)
in the itanium ABI
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: mar...@martin.st
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
With both GCC (tested with GCC 5.3) and MSVC, and clang in MSVC mode, a
dllexported class declaration trigger emitting typeinfo (and the corresponding
export linker directives), while clang in itanium mode fails to do this.
This causes build failures when building Qt for MinGW with clang (unless RTTI
is disabled, which isn't officially supported in Qt).
Example case:
dllexport-rtti.cpp:
class __declspec(dllexport) VirtualClass {
public:
void virtual bar();
};
$ x86_64-w64-mingw32-g++ -c dllexport-rtti.cpp -o dllexport-rtti.o
$ llvm-nm dllexport-rtti.o
R _ZTI12VirtualClass
R _ZTS12VirtualClass
U _ZTVN10__cxxabiv117__class_type_infoE
$ llvm-readobj -coff-directives dllexport-rtti.o
File: dllexport-rtti.o
Format: COFF-x86-64
Arch: x86_64
AddressSize: 64bit
Directive(s): -export:"_ZTI12VirtualClass",data
With clang (clang -target x86_64-windows-gnu dllexport-rtti.cpp -c -o
dllexport-rtti.o), nothing gets emitted in this build.
This seems to be related to things that David Majnemer touched in SVN r244266
in this commit:
"[ItaniumCXXABI] Don't import RTTI data for classes with key functions"
(This particular test case behaves identically both before and after that
commit though, but it seems to be related.)
--
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 35147] New: Backslash is appended each time in multiline comment inside #define with AlignEscapedNewlines: DontAlign
https://bugs.llvm.org/show_bug.cgi?id=35147
Bug ID: 35147
Summary: Backslash is appended each time in multiline comment
inside #define with AlignEscapedNewlines: DontAlign
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: mikhail.matro...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Format this code with -style="{AlignEscapedNewlines: DontAlign}":
#define chSpaceSpell \
0x20 /* ' ' space. Also used to delimit \
"change always" pairs */
See how backslash is appended to the comment with each format.
--
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 35053] lldb-server fails to link on linux - undefined reference to 'pthread_atfork'
https://bugs.llvm.org/show_bug.cgi?id=35053 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from lab...@google.com --- fixed by r316997 -- 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 35148] New: [AMDGPU][MC][GFX9][disassembler] incorrect default value of op_sel_hi for v_mad_mix*
https://bugs.llvm.org/show_bug.cgi?id=35148 Bug ID: 35148 Summary: [AMDGPU][MC][GFX9][disassembler] incorrect default value of op_sel_hi for v_mad_mix* Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org v_mad_mix* opcodes aren't really packed instructions. They use op_sel and op_sel_hi in a different fashion than other VOP3P opcodes. The most important difference from other VOP3P instructions is that the default value of op_sel_hi bits is 0 rather than 1. Currently disassembler does not account for this difference. The following instruction is encoded as follows: v_mad_mix_f32 v0, v1, v2, v3 op_sel_hi:[1,1,1] [0x00,0x40,0xa0,0xd3,0x01,0x05,0x0e,0x1c] However, disassembler decodes it incorrectly assuming that default value of op_sel_hi is 0: v_mad_mix_f32 v0, v1, v2, v3 -- 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 35149] New: msvc2010 linker reports no symbol for COMDAT section with clang compiled object
https://bugs.llvm.org/show_bug.cgi?id=35149
Bug ID: 35149
Summary: msvc2010 linker reports no symbol for COMDAT section
with clang compiled object
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: comicfan...@gmail.com
CC: llvm-bugs@lists.llvm.org
I'm trying to use llvm-project-20170507 c252c437 (Oct 2) clang-cl to build our
codebase (emulate 2010 ,and link with msvc 2010 linker),two objects rejected by
msvc linker,report as :
fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section
0x87,
seems clang is generating code for code in C:\Program Files (x86)\Microsoft
Visual Studio 10.0\VC\atlmfc\include\statreg.h:
__declspec(selectany) const TCHAR* const CRegParser::rgszNeverDelete[] =
{
_T("AppID"),
_T("CLSID"),
_T("Component Categories"),
_T("FileType"),
_T("Interface"),
_T("Hardware"),
_T("Mime"),
_T("SAM"),
_T("SECURITY"),
_T("SYSTEM"),
_T("Software"),
_T("TypeLib")
};
while dumping with dumpbin /ALL with clang compiled obj, reported section as
following:
SECTION HEADER #86
.bss name
0 physical address
0 virtual address
8 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0401080 flags
Uninitialized Data
COMDAT; sym= "struct ATL::IAtlAutoThreadModule *
ATL::_pAtlAutoThreadModule"
(?_pAtlAutoThreadModule@ATL@@3PEAUIAtlAutoThreadModule@1@EA)
8 byte align
Read Write
SECTION HEADER #87 ==> reported by linker
.data name
0 physical address
0 virtual address
40 size of raw data
158C8 file pointer to raw data (000158C8 to 00015907)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0601040 flags
Initialized Data
COMDAT (no symbol)
32 byte align
Read Write
RAW DATA #87
: 41 70 70 49 44 00 00 00 00 00 00 00 00 00 00 00 AppID...
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SECTION HEADER #88
.data name
0 physical address
0 virtual address
40 size of raw data
15908 file pointer to raw data (00015908 to 00015947)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0601040 flags
Initialized Data
COMDAT (no symbol)
32 byte align
Read Write
RAW DATA #88
: 43 4C 53 49 44 00 00 00 00 00 00 00 00 00 00 00 CLSID...
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SECTION HEADER #89
.data name
0 physical address
0 virtual address
40 size of raw data
15948 file pointer to raw data (00015948 to 00015987)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0601040 flags
Initialized Data
COMDAT (no symbol)
32 byte align
Read Write
RAW DATA #89
: 43 6F 6D 70 6F 6E 65 6E 74 20 43 61 74 65 67 6F Component Catego
0010: 72 69 65 73 00 00 00 00 00 00 00 00 00 00 00 00 ries
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SECTION HEADER #8A
.data name
0 physical address
0 virtual address
40 size of raw data
15988 file pointer to raw data (00015988 to 000159C7)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0601040 flags
Initialized Data
COMDAT (no symbol)
32 byte align
Read Write
RAW DATA #8A
: 46 69 6C 65 54 79 70 65 00 00 00 00 00 00 00 00 FileType
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SECTION HEADER #8B
.data name
0 physical ad
[llvm-bugs] [Bug 35149] msvc2010 linker reports no symbol for COMDAT section with clang compiled object
https://bugs.llvm.org/show_bug.cgi?id=35149 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r317009 --- Comment #2 from Reid Kleckner --- Should be fixed by r317009. -- 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 3954 in oss-fuzz: llvm/clang-fuzzer: ASSERT: D.isPastIdentifier() && "Haven't past the location of the identifier yet?"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-31 New issue 3954 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-fuzzer: ASSERT: D.isPastIdentifier() && "Haven't past the location of the identifier yet?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3954 Detailed report: https://oss-fuzz.com/testcase?key=4843324394438656 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: D.isPastIdentifier() && "Haven't past the location of the identifier yet?" clang::Parser::ParseDirectDeclarator clang::Parser::ParseDeclaratorInternal Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4843324394438656 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 35151] New: wasm code gen assertion failure compiling this file
https://bugs.llvm.org/show_bug.cgi?id=35151 Bug ID: 35151 Summary: wasm code gen assertion failure compiling this file Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: j...@csquare.ca CC: llvm-bugs@lists.llvm.org Created attachment 19365 --> https://bugs.llvm.org/attachment.cgi?id=19365&action=edit Preprocessed source and run script I'm attempting to compile gzip with the trunk clang targeting wasm32-unknown-unknown-wasm. clang-6.0: /home/john/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:65: std::string llvm::WebAssemblyAsmPrinter::regToString(const llvm::MachineOperand &): Assertion `!MFI->isVRegStackified(RegNo)' failed. #0 0x02394bac llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/john/llvm/lib/Support/Unix/Signals.inc:398:0 #1 0x02394d59 PrintStackTraceSignalHandler(void*) /home/john/llvm/lib/Support/Unix/Signals.inc:462:0 #2 0x02393243 llvm::sys::RunSignalHandlers() /home/john/llvm/lib/Support/Signals.cpp:50:0 #3 0x023953ef SignalHandler(int) /home/john/llvm/lib/Support/Unix/Signals.inc:252:0 #4 0x7f507f5f0330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #5 0x7f507e196c37 gsignal /build/eglibc-SvCtMH/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x7f507e19a028 abort /build/eglibc-SvCtMH/eglibc-2.19/stdlib/abort.c:91:0 #7 0x7f507e18fbf6 __assert_fail_base /build/eglibc-SvCtMH/eglibc-2.19/assert/assert.c:92:0 #8 0x7f507e18fca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #9 0x0122e15a llvm::WebAssemblyAsmPrinter::regToString(llvm::MachineOperand const&) /home/john/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:66:0 #10 0x0122f499 llvm::WebAssemblyAsmPrinter::PrintAsmMemoryOperand(llvm::MachineInstr const*, unsigned int, unsigned int, char const*, llvm::raw_ostream&) /home/john/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:273:0 #11 0x03061b6c EmitGCCInlineAsmStr(char const*, llvm::MachineInstr const*, llvm::MachineModuleInfo*, int, int, llvm::AsmPrinter*, unsigned int, llvm::raw_ostream&) /home/john/llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp:431:0 #12 0x03060dcc llvm::AsmPrinter::EmitInlineAsm(llvm::MachineInstr const*) const /home/john/llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp:508:0 #13 0x03049f31 llvm::AsmPrinter::EmitFunctionBody() /home/john/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1029:0 #14 0x01230248 llvm::AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) /home/john/llvm/include/llvm/CodeGen/AsmPrinter.h:279:0 #15 0x0122fcf3 llvm::WebAssemblyAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) /home/john/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.h:49:0 #16 0x016d1d66 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/john/llvm/lib/CodeGen/MachineFunctionPass.cpp:62:0 #17 0x01bff43b llvm::FPPassManager::runOnFunction(llvm::Function&) /home/john/llvm/lib/IR/LegacyPassManager.cpp:1514:0 #18 0x01bff775 llvm::FPPassManager::runOnModule(llvm::Module&) /home/john/llvm/lib/IR/LegacyPassManager.cpp:1535:0 #19 0x01bfff6f (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/john/llvm/lib/IR/LegacyPassManager.cpp:1591:0 #20 0x01bffa5b llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/john/llvm/lib/IR/LegacyPassManager.cpp:1694:0 #21 0x01c004b1 llvm::legacy::PassManager::run(llvm::Module&) /home/john/llvm/lib/IR/LegacyPassManager.cpp:1725:0 #22 0x026bef23 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr >) /home/john/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:794:0 #23 0x026bc56f 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 >) /home/john/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1145:0 #24 0x03470131 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) /home/john/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:292:0 #25 0x04550c50 clang::ParseAST(clang::Sema&, bool, bool) /home/john/llvm/tools/clang/lib/Parse/ParseAST.cpp:161:0 #26 0x02e6a98e clang::ASTFrontendAction::ExecuteAction() /home/john/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:1000:0 #27 0x0346d4f7 clang::CodeGenAction::ExecuteAction() /home/john/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:1032:0 #28 0x02e6a3c8 clang::FrontendAction::Execute() /home/john/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:901:0 #29 0x02df5aa4 clang::CompilerInstance
[llvm-bugs] [Bug 35152] New: `Scope.hasEHBranches() == (EHEntry != nullptr)' assertion with openmp reproducer:
https://bugs.llvm.org/show_bug.cgi?id=35152
Bug ID: 35152
Summary: `Scope.hasEHBranches() == (EHEntry != nullptr)'
assertion with openmp reproducer:
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: erich.ke...@intel.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19366
--> https://bugs.llvm.org/attachment.cgi?id=19366&action=edit
Repro file, command line
See repro file, taken from our internal test suite. Only happens with -O1 for
some reason, and ONLY with a windows target, but it is reproduceable with a
Linux host (see command line in the repro).
Also, copied and pasted here for convenience:
//clang -cc1 -triple x86_64-pc-windows-msvc18.0.0 -emit-obj repro.cpp
-fexceptions -fcxx-exceptions -std=c++11 -fms-compatibility-version=18 -fopenmp
-fms-extensions -O1
void printf(const char*);
void exit(int);
struct Test {
static void main() {
int failed = 0;
int j = 2;
#pragma omp parallel
{
int local_j = 3;
#pragma omp single copyprivate(local_j)
{
local_j = 4;
}
// Assure reports a data race, but value written to "j"
// should always be the same.
j = local_j;
}
if(j != 4) failed = 1;
if(failed) {
printf("Test " __FILE__ " failed\n");
exit(1);
} else {
printf("Test " __FILE__ " passed\n");
exit(0);
}
}
};
int main() {
Test::main();
return 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34992] Fatal error: Offset not zero at the point of scalar access
https://bugs.llvm.org/show_bug.cgi?id=34992 Douglas Yung changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Douglas Yung --- (In reply to Ivan Kosarev from comment #4) > Douglas, can you please confirm the fix works for you? Hi Ivam, I can confirm that this fixes the internal test that uncovered the issue. Thanks for fixing it! -- 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 35153] New: Build failure on trunk
https://bugs.llvm.org/show_bug.cgi?id=35153 Bug ID: 35153 Summary: Build failure on trunk Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: deepankar.sha...@gmail.com CC: llvm-bugs@lists.llvm.org Building on Fedora 26 with following flags -> cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DLLVM_INCLUDE_DOCS=OFF -DCLANG_DEFAULT_CXX_STDLIB=libc++ -DCLANG_DEFAULT_LINKER=lld -DCLANG_INCLUDE_TESTS=OFF -DCMAKE_BUILD_TYPE=Release -DLIBCLANG_BUILD_STATIC=ON -DLIBCXXABI_ENABLE_STATIC_UNWINDER=ON -DLIBCXX_INCLUDE_TESTS=OFF -DLIBCXX_HAS_PTHREAD_API=ON -DLIBCXX_INCLUDE_BENCHMARKS=OFF -DLIBCXX_INCLUDE_DOCS=OFF -DLIBCXX_INCLUDE_TESTS=OFF -DLIBCXX_USE_COMPILER_RT=ON -DLLVM_ENABLE_LIBCXX=ON -DLLVM_ENABLE_FFI=ON -DLLVM_ENABLE_LTO=ON -DLLVM_ENABLE_OCAMLDOC=OFF -DLLVM_INCLUDE_DOCS=OFF -DSANITIZER_USE_COMPILER_RT=ON -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_GO_TESTS=OFF -DLLVM_INCLUDE_RUNTIMES=ON -DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_TOOLS=ON -DLLVM_INCLUDE_UTILS=ON -DLLVM_INSTALL_UTILS=ON -DLLVM_PARALLEL_COMPILE_JOBS=4 -DLLVM_PARALLEL_LINK_JOBS=4 -DLLVM_TOOL_LIBCXXABI_BUILD=ON -DLLVM_TOOL_LIBCXX_BUILD=ON -DLLVM_TOOL_LIBUNWIND_BUILD=ON -DLLVM_TOOL_LLDB_BUILD=ON -DLLVM_TOOL_LLD_BUILD=ON -DLLVM_TOOL_LLGO_BUILD=OFF -DLLVM_TOOL_OPENMP_BUILD=ON -DLLVM_TOOL_PARALLEL_LIBS_BUILD=ON -DLLVM_TARGETS_TO_BUILD="X86" -DLLVM_OPTIMIZED_TABLEGEN=ON -G Ninja .. Get the following compile failure FAILED: bin/llvm-tblgen : && /usr/bin/clang++ -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections -flto -O2 -DNDEBUG -stdlib=libc++ -flto -Wl,-allow-shlib-undefined -Wl,-rpath-link,/home/dman/programs/llvm/build/./lib -Wl,-O3 -Wl,--gc-sections utils/TableGen/CMakeFiles/llvm-tblgen.dir/AsmMatcherEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/AsmWriterEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/AsmWriterInst.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/Attributes.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CallingConvEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeEmitterGen.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenHwModes.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenInstruction.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenMapTable.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenSchedule.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenTarget.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcherEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcherGen.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcherOpt.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/DAGISelMatcher.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/DisassemblerEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/FastISelEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/FixedLenDecoderEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/InfoByHwMode.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/InstrInfoEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/IntrinsicEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/OptParserEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/PseudoLoweringEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/RegisterBankEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/RegisterInfoEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/SearchableTableEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/SubtargetEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/SubtargetFeatureInfo.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/TableGen.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/Types.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/X86DisassemblerTables.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/X86EVEX2VEXTablesEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/X86FoldTablesEmitter.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/X86ModRMFilters.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/X86RecognizableInstr.cpp.o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CTagsEmitter.cpp.o -o bin/llvm-tblgen -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libLLVMTableGen.a -lpthread lib/libLL
[llvm-bugs] [Bug 33930] Assertion `OpN.isUniqued() && "Only uniqued operands cannot be mapped immediately"' failed.
https://bugs.llvm.org/show_bug.cgi?id=33930 Wolfgang Pieb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Wolfgang Pieb --- Fixed with r317047 (cfe). Requires r317018 (llvm). See a detailed description in https://reviews.llvm.org/D39396. -- 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 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 33930, which changed state. Bug 33930 Summary: Assertion `OpN.isUniqued() && "Only uniqued operands cannot be mapped immediately"' failed. https://bugs.llvm.org/show_bug.cgi?id=33930 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35154] New: Clang's diagnostic suppression pragma fails in a particular macro expansion case
https://bugs.llvm.org/show_bug.cgi?id=35154
Bug ID: 35154
Summary: Clang's diagnostic suppression pragma fails in a
particular macro expansion case
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: arpha...@gmail.com
CC: llvm-bugs@lists.llvm.org
Clang fails to silence the -Wunused-value warning in the following test-case:
```
@class Test;
#define nil2 0
#define SOMETHING(macro) macro
#define Expected(invocation) \
({ \
SilenceWarning( \
Test *recorder = nil2; \
recorder; \
); \
})
#define SilenceWarning(macro) \
({ \
_Pragma("clang diagnostic push") \
_Pragma("clang diagnostic ignored \"-Wunused-value\"") \
macro \
_Pragma("clang diagnostic pop") \
})
int test1() {
return 5;
}
void foo(Test *other) {
SOMETHING(
Expected(test1());
)
}
```
Interestingly enough, if the use of `nil2` is replaced by `0` then the warning
is suppressed correctly.
--
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 35155] New: [X86] [CodeGen] Compiler not using SHLD/SHRD instructions when doing double shift pattern combine for 16bit or 8bit arguments
https://bugs.llvm.org/show_bug.cgi?id=35155
Bug ID: 35155
Summary: [X86] [CodeGen] Compiler not using SHLD/SHRD
instructions when doing double shift pattern combine
for 16bit or 8bit arguments
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: konstantin.belocha...@sony.com
CC: llvm-bugs@lists.llvm.org
Consider the following code which implements double shift left:
uint64_t shld64(uint64_t a, uint64_t b, uint64_t shift)
{
return (a << shift) | (b >> (64 - shift));
}
uint32_t shld32(uint32_t a, uint32_t b, uint32_t shift)
{
return (a << shift) | (b >> (32 - shift));
}
uint16_t shld16(uint16_t a, uint16_t b, uint16_t shift)
{
return (a << shift) | (b >> (16 - shift));
}
uint8_t shld8(uint8_t a, uint8_t b, uint8_t shift)
{
return (a << shift) | (b >> (8 - shift));
}
With optimization enabled, clang produces the following assembler code:
shld64:
movl%edx, %ecx
shldq %cl, %rsi, %rdi
movq%rdi, %rax
retq
shld32:
movl%edx, %ecx
shldl %cl, %esi, %edi
movl%edi, %eax
retq
shld16:
movl%edx, %ecx
shll%cl, %edi
movl$16, %ecx
subl%edx, %ecx
shrl%cl, %esi
orl %edi, %esi
movl%esi, %eax
retq
shld8:
movl%edx, %ecx
shll%cl, %edi
movl$8, %ecx
subl%edx, %ecx
shrl%cl, %esi
orl %edi, %esi
movl%esi, %eax
retq
Obviously uint16_t type gets promoted to 32 bit and the backend code no longer
can recognize the double shift pattern.
Even with the integer promotion the generated code can be shorter, four
instruction against seven:
shld16:
shll$16, %esi
movl%edx, %ecx
shldl %cl, %esi, %edi
movl%edi, %eax
retq
shld8:
shll$24, %esi
movl%edx, %ecx
shldl %cl, %esi, %edi
movl%edi, %eax
retq
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3958 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: TRI.getRegSizeInBits(*getRegClass(DstReg)) == TRI.getRegSizeInBits(*getRegClass(
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-11-01 New issue 3958 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: TRI.getRegSizeInBits(*getRegClass(DstReg)) == TRI.getRegSizeInBits(*getRegClass( https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3958 Detailed report: https://oss-fuzz.com/testcase?key=5578430327291904 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: TRI.getRegSizeInBits(*getRegClass(DstReg)) == TRI.getRegSizeInBits(*getRegClass( llvm::AArch64InstrInfo::foldMemoryOperandImpl llvm::TargetInstrInfo::foldMemoryOperand Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5578430327291904 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 35156] New: IR verification failed
https://bugs.llvm.org/show_bug.cgi?id=35156
Bug ID: 35156
Summary: IR verification failed
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: evstu...@gmail.com
CC: llvm-bugs@lists.llvm.org
Most likely related to https://bugs.llvm.org/show_bug.cgi?id=35152
Compilation of the following test:
void foo();
void bar();
int main ()
{
#pragma omp parallel
{
try {
foo();
}
catch (int t) {
#pragma omp critical
{
bar();
};
}
};
return 0;
}
clang -fopenmp --target=x86_64-pc-windows-msvc t.cpp -c
Result in:
Instruction does not dominate all uses!
%2 = catchpad within %1 [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i32*
%t]
%0 = call i32 @__kmpc_global_thread_num(%ident_t* @0) [ "funclet"(token %2) ]
fatal error: error in backend: Broken function found, compilation aborted!
--
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 3195 in oss-fuzz: llvm: Direct-leak in clang::Parser::ParseParameterDeclarationClause
Updates: Labels: ClusterFuzz-Top-Crash Comment #7 on issue 3195 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm: Direct-leak in clang::Parser::ParseParameterDeclarationClause https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3195#c7 Testcase 5752583010385920 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash. 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 3966 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!RS || !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-11-01 New issue 3966 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!RS | | !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3966 Detailed report: https://oss-fuzz.com/testcase?key=5598424608014336 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (!RS || !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out llvm::AArch64RegisterInfo::eliminateFrameIndex llvm::RegScavenger::spill Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5598424608014336 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 35157] New: Crash in ARM backend for VST1d64TPseudoWB_fixed instruction
https://bugs.llvm.org/show_bug.cgi?id=35157 Bug ID: 35157 Summary: Crash in ARM backend for VST1d64TPseudoWB_fixed instruction Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: srhi...@google.com CC: c...@google.com, kongy@gmail.com, kristof.be...@arm.com, lloz...@chromium.org, llvm-bugs@lists.llvm.org, pir...@google.com Created attachment 19367 --> https://bugs.llvm.org/attachment.cgi?id=19367&action=edit preprocessed input file that crashes in ARM backend To reproduce, just use TOT: $ clang -target arm-linux-androideabi -mcpu=cortex-a7 -c ref_vldX.i This results in an assertion failure where there is a mismatch between the number of operands used for the VST1d64TPseudoWB_fixed instruction (6 vs. 7). I was able to narrow it down to this using gdb, but I don't really know this part of the ARM backend well enough to spot/fix the error (and/or write a smaller test for it). The crash is as follows: clang-6.0: /a/llvm/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:802: void llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, llvm::DenseMap&): Assertion `NumMIOperands >= II.getNumOperands() && NumMIOperands <= II.getNumOperands() + II.getNumImplicitDefs() + NumImpUses && "#operands for dag node doesn't match .td file!"' failed. #0 0x03fffeb3 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /a/llvm/llvm/lib/Support/Unix/Signals.inc:398:0 #1 0x0344 PrintStackTraceSignalHandler(void*) /a/llvm/llvm/lib/Support/Unix/Signals.inc:462:0 #2 0x03ffe356 llvm::sys::RunSignalHandlers() /a/llvm/llvm/lib/Support/Signals.cpp:49:0 #3 0x03fff84a SignalHandler(int) /a/llvm/llvm/lib/Support/Unix/Signals.inc:252:0 #4 0x7fd547ef2330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #5 0x7fd546ceac37 gsignal /build/eglibc-SvCtMH/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x7fd546cee028 abort /build/eglibc-SvCtMH/eglibc-2.19/stdlib/abort.c:91:0 #7 0x7fd546ce3bf6 __assert_fail_base /build/eglibc-SvCtMH/eglibc-2.19/assert/assert.c:92:0 #8 0x7fd546ce3ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #9 0x04d7f560 llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, llvm::DenseMap, llvm::detail::DenseMapPair >&) /a/llvm/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:806:0 #10 0x04d7543b llvm::InstrEmitter::EmitNode(llvm::SDNode*, bool, bool, llvm::DenseMap, llvm::detail::D enseMapPair >&) /a/llvm/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.h:121:0 #11 0x04d73705 llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator&) /a/llvm/llvm/lib/CodeGen/SelectionDAG/ScheduleDAG SDNodes.cpp:848:0 #12 0x04ce1702 llvm::SelectionDAGISel::CodeGenAndEmitDAG() /a/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:880:0 #13 0x04cdfc54 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>, ll vm::ilist_iterator, false, true>, bool&) /a/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:66 5:0 #14 0x04ce5329 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) /a/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1610:0 #15 0x04cde8de llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) /a/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:467:0 #16 0x0265c5b4 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) /a/llvm/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp:71:0 #17 0x034b173d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /a/llvm/llvm/lib/CodeGen/MachineFunctionPass.cpp:62:0 #18 0x038fc674 llvm::FPPassManager::runOnFunction(llvm::Function&) /a/llvm/llvm/lib/IR/LegacyPassManager.cpp:1514:0 #19 0x038fc807 llvm::FPPassManager::runOnModule(llvm::Module&) /a/llvm/llvm/lib/IR/LegacyPassManager.cpp:1535:0 #20 0x038fcba2 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /a/llvm/llvm/lib/IR/LegacyPassManager.cpp:1591:0 #21 0x038fd2f2 llvm::legacy::PassManagerImpl::run(llvm::Module&) /a/llvm/llvm/lib/IR/LegacyPassManager.cpp:1694:0 #22 0x038fd533 llvm::legacy::PassManager::run(llvm::Module&) /a/llvm/llvm/lib/IR/LegacyPassManager.cpp:1726:0 #23 0x0429e13c (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr >) /a/llvm/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:794:0 #24 0x042a08b2 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std:
[llvm-bugs] [Bug 35158] New: ToT llvm+clang crashes when building ToT llvm+clang with "-march=knl”
https://bugs.llvm.org/show_bug.cgi?id=35158 Bug ID: 35158 Summary: ToT llvm+clang crashes when building ToT llvm+clang with "-march=knl” Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: d...@znu.io CC: llvm-bugs@lists.llvm.org ToT llvm+clang crashes when building ToT llvm+clang with "-march=knl”. Sorry, I don't have any of the metadata it requested handy. I did try and debug it a little bit though. It looks like a v64i8 register was requested, but "knl" doesn't support that register class. Maybe some custom lowering is missing? Or maybe a missing HasBWI flag is needed in the instruction tables? /usr/local/bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/IR -I../lib/IR -Iinclude -I../include -march=knl -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections -O2 -DNDEBUG-fno-exceptions -fno-rtti -MD -MT lib/IR/CMakeFiles/LLVMCore.dir/DebugInfoMetadata.cpp.o -MF lib/IR/CMakeFiles/LLVMCore.dir/DebugInfoMetadata.cpp.o.d -o lib/IR/CMakeFiles/LLVMCore.dir/DebugInfoMetadata.cpp.o -c ../lib/IR/DebugInfoMetadata.cpp clang-6.0: ../include/llvm/Target/TargetLowering.h:584: virtual const llvm::TargetRegisterClass *llvm::TargetLoweringBase::getRegClassFor(llvm::MVT) const: Assertion `RC && "This value type is not natively supported!"' failed. #0 0x023370a9 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/zarzycki/wt/llvm/d/../lib/Support/Unix/Signals.inc:398:11 #1 0x02337259 PrintStackTraceSignalHandler(void*) /home/zarzycki/wt/llvm/d/../lib/Support/Unix/Signals.inc:462:1 #2 0x02335853 llvm::sys::RunSignalHandlers() /home/zarzycki/wt/llvm/d/../lib/Support/Signals.cpp:0:5 #3 0x023375e7 SignalHandler(int) /home/zarzycki/wt/llvm/d/../lib/Support/Unix/Signals.inc:252:1 #4 0x7f9fb330c3b0 __restore_rt (/lib64/libpthread.so.0+0x123b0) #5 0x7f9fb22999fb __GI_raise (/lib64/libc.so.6+0x369fb) #6 0x7f9fb229b800 __GI_abort (/lib64/libc.so.6+0x38800) #7 0x7f9fb22920da __assert_fail_base (/lib64/libc.so.6+0x2f0da) #8 0x7f9fb2292152 (/lib64/libc.so.6+0x2f152) #9 0x01062626 llvm::TargetLoweringBase::getRegClassFor(llvm::MVT) const /home/zarzycki/wt/llvm/d/../include/llvm/Target/TargetLowering.h:585:12 #10 0x0339eb54 llvm::InstrEmitter::EmitSubregNode(llvm::SDNode*, llvm::DenseMap, llvm::detail::DenseMapPair >&, bool, bool) /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/InstrEmitter.cpp:573:32 #11 0x0339fbdb llvm::InstrEmitter::EmitMachineNode(llvm::SDNode*, bool, bool, llvm::DenseMap, llvm::detail::DenseMapPair >&) /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/InstrEmitter.cpp:752:5 #12 0x03394bb6 llvm::InstrEmitter::EmitNode(llvm::SDNode*, bool, bool, llvm::DenseMap, llvm::detail::DenseMapPair >&) /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/InstrEmitter.h:121:7 #13 0x03392063 llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator&) /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp:848:9 #14 0x032dfc1e llvm::SelectionDAGISel::CodeGenAndEmitDAG() /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:880:42 #15 0x032dd9a0 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>, llvm::ilist_iterator, false, true>, bool&) /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:665:1 #16 0x032dd6a1 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:0:7 #17 0x032da98d llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) /home/zarzycki/wt/llvm/d/../lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:467:22 #18 0x00ebb8db (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) /home/zarzycki/wt/llvm/d/../lib/Target/X86/X86ISelDAGToDAG.cpp:177:25 #19 0x016290d4 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/zarzycki/wt/llvm/d/../lib/CodeGen/MachineFunctionPass.cpp:62:8 #20 0x01bb0f8f llvm::FPPassManager::runOnFunction(llvm::Function&) /home/zarzycki/wt/llvm/d/../lib/IR/LegacyPassManager.cpp:1514:27 #21 0x01bb12a5 llvm::FPPassManager::runOnModule(llvm::Module&) /home/zarzycki/wt/llvm/d/../lib/IR/LegacyPassManager.cpp:1535:16 #22 0x01bb1a6a (anonymous namespace)
[llvm-bugs] Issue 3972 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: Ty && "Invalid GetElementPtrInst indices for type!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-11-01 New issue 3972 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: Ty && "Invalid GetElementPtrInst indices for type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3972 Detailed report: https://oss-fuzz.com/testcase?key=4799326548131840 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Ty && "Invalid GetElementPtrInst indices for type!" llvm::GetElementPtrInst::getGEPReturnType llvm::GetElementPtrInst::GetElementPtrInst Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4799326548131840 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 35159] New: Linker command failed
https://bugs.llvm.org/show_bug.cgi?id=35159
Bug ID: 35159
Summary: Linker command failed
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ishiura-compi...@ml.kwansei.ac.jp
CC: llvm-bugs@lists.llvm.org
$ cat prog.c
#define INT_MAX 0x7fff
char a[1][1] = { {1} };
int x = 0;
int y = -INT_MAX;
int main (void)
{
if (a[x][INT_MAX+y] != 1) __builtin_abort();
return 0;
}
$ clang-6.0 prog.c
$ clang-6.0 -O1 prog.c
/tmp/prog-b35125.o: In function `main':
prog.c:(.text+0x11): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .data section in /tmp/prog-b35125.o
clang-6.0: error: linker command failed with exit code 1 (use -v to see
invocation)
$ clang-6.0 -v
clang version 6.0.0 (trunk 316662) (llvm/trunk 316661)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.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.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
Reproduces on clang-3.6 or later with -O1.
--
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 3974 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: Null-dereference READ in llvm::IRMutator::mutateModule
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Unreproducible Engine-libfuzzer Proj-llvm Reported-2017-11-01 New issue 3974 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-O2: Null-dereference READ in llvm::IRMutator::mutateModule https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3974 Detailed report: https://oss-fuzz.com/testcase?key=5289625049366528 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: llvm::IRMutator::mutateModule LLVMFuzzerCustomMutator _start Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5289625049366528 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days. 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
