search for: bitcodecompil

...9;t had a chance to look, but as mentioned, the linker resolution for the symbol is exported, which explains the LTO side behavior. Someone from the linker will probably need to see what changed in the symbol info they are giving LTO is changing after that patch. If you want you can debug lld's BitcodeCompiler::add to see what info is different in the Resols array for that symbol that gets passed to LTO. Or what else is different in the Sym used to generate the resolution. Both of those are examined in LTO::addModuleToGlobalRes when we note that the symbol is external. Teresa On Thu, Jun 20, 2019 at...

...an initializer so that it is a def we no longer think it is exported and are able to internalize. So this seems to be due to a change in what the linker is telling LTO. I would have to dig in the debugger to confirm, but perhaps lld is now indicating that it might be used by a regular obj? I.e. in BitcodeCompiler::add. Teresa On Tue, Jun 11, 2019 at 5:48 AM Rui Ueyama <ruiu at google.com<mailto:ruiu at google.com>> wrote: Looks like this is indeed related to r360841. In C, there are distinctions between declarations, definitions and tentative definitions. Global variables declared with &quo...

...tioned, the linker resolution >> for the symbol is exported, which explains the LTO side behavior. Someone >> from the linker will probably need to see what changed in the symbol info >> they are giving LTO is changing after that patch. If you want you can debug >> lld's BitcodeCompiler::add to see what info is different in the Resols >> array for that symbol that gets passed to LTO. Or what else is different in >> the Sym used to generate the resolution. Both of those are examined in >> LTO::addModuleToGlobalRes when we note that the symbol is external. >&g...

Looks like this is indeed related to r360841. In C, there are distinctions between declarations, definitions and tentative definitions. Global variables declared with "extern" are declarations. Global variables that don't have "extern" and have initializers are definitions. If global variables have neither "extern" nor initializers, they are called tentative

...gned int)> AddStream, std::function<std::function<std::unique_ptr<llvm::lto::NativeObjectStream,std::default_delete<llvm::lto::NativeObjectStream> > __cdecl(unsigned int)> __cdecl(unsigned int,llvm::StringRef)> Cache) Line 793 C++ Symbols loaded. lld.exe!lld::coff::BitcodeCompiler::compile() Line 141 C++ Symbols loaded. lld.exe!lld::coff::SymbolTable::compileBitcodeFiles() Line 381 C++ Symbols loaded. lld.exe!lld::coff::SymbolTable::addCombinedLTOObjects() Line 389 C++ Symbols loaded. lld.exe!lld::coff::LinkerDriver::link(llvm::ArrayRef<char const *> Arg...

This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction in @_island_debug_invoke and many other functions. The code expects either pointer to a filter function or null in first operand, while you're passing pointer to structure: catchpad within %80 [{i8*, i8*}* anon..., ...] ________________________________________ От: Carlo Kok <ck at

...AddStream, std::function<std::function<std::unique_ptr<llvm::lto::NativeObjectStream,std::default_delete<llvm::lto::NativeObjectStream> > __cdecl(unsigned int)> __cdecl(unsigned int,llvm::StringRef)> Cache) Line 793 C++ Symbols loaded. lld.exe!lld::coff::BitcodeCompiler::compile() Line 141 C++ Symbols loaded. lld.exe!lld::coff::SymbolTable::compileBitcodeFiles() Line 381 C++ Symbols loaded. lld.exe!lld::coff::SymbolTable::addCombinedLTOObjects() Line 389 C++ Symbols loaded. lld.exe!lld::coff::LinkerDriver::link(llvm::ArrayRef...

Op 16-3-2018 om 20:16 schreef Evgeny Leviant: > Hello Carlo, > > I tried your reproducer and faced different problem from one you described > (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens > when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: > >