[llvm-bugs] [Bug 31112] New: libclang should not require that a CXUnsavedFile should exist on disk
https://llvm.org/bugs/show_bug.cgi?id=31112 Bug ID: 31112 Summary: libclang should not require that a CXUnsavedFile should exist on disk Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: nikolai.kos...@qt.io CC: kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified The documentation [1] states that an unsaved file must exist on disk. This requirement makes it hard to implement IDEs supporting in-memory files of code generators. If the libclang client provides unsaved files that do not exist on disk yet, the preamble generation will be part of every parse/reparse/completion operation, at least if CXTranslationUnit_PrecompiledPreamble is used and as a result, all those operations will be very slow. The specific case we have in Qt / Qt Creator: A Qt project can contain *.ui files. Those are the input for the uic tool, which generates "ui_*.h" header files. Part of the Qt Creator IDE is the feature that a *.ui file can be edited and behind the scenes the "ui_*.h" header will be updated automatically (without saving anything to disk; writing into the build directory is not an option), so that highlighting/completion in a *.cpp files including that header file will reflect those changes. This works fine as long unsaved file exist on disk (e.g. project was already build), but for the case that a project is opened for the very first time (no ui_*.h files generated yet on disk) or some new *.ui files are just added to the project this will result in the described performance regression. Also, because of the resulting performance regression once the requirement is not fulfilled, special care needs to be taken to check the unsaved files for actual existence in the file system. Please remove this requirement and fix the described performance issue. [1] http://clang.llvm.org/doxygen/structCXUnsavedFile.html#aa8bf5d4351628ee8502b517421e8b418 -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30853, which changed state. Bug 30853 Summary: Merge r284229 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30853 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 30853] Merge r284229 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30853 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jack Howarth --- Committed to 3.9 branch as r286970 -- 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 30852] Merge r284110 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30852 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jack Howarth --- Back ported to 3.9 branch as r286964 -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30852, which changed state. Bug 30852 Summary: Merge r284110 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30852 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 30811] Path used for passing `-lto_library` to the linker on Darwin confused by symlinks
https://llvm.org/bugs/show_bug.cgi?id=30811 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Jack Howarth --- Fixed by r285525 -- 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 30647] clang omits valid c++ search path when -isysroot is set to SDKs in Xcode.app
https://llvm.org/bugs/show_bug.cgi?id=30647 Jack Howarth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28127] lldb-server broken when LLVM_LINK_LLVM_DYLIB=ON
https://llvm.org/bugs/show_bug.cgi?id=28127 lab...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||lab...@google.com Resolution|--- |FIXED Assignee|lldb-...@lists.llvm.org |lab...@google.com --- Comment #6 from lab...@google.com --- LLVM_LINK_LLVM_DYLIB=ON should be fixed on master now. Please reopen if you still experience problems. -- 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 31113] New: Merge r279980 to 3.9.1
https://llvm.org/bugs/show_bug.cgi?id=31113 Bug ID: 31113 Summary: Merge r279980 to 3.9.1 Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: sanx...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This fixes a bug that hurts Rust pretty badly: https://github.com/rust-lang/rust/issues/36023 -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30970, which changed state. Bug 30970 Summary: Merge r283729 into 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30970 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 30970] Merge r283729 into 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30970 Nitesh Jain changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nitesh Jain --- Committed revision 287641 -- 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 31114] New: Clang crashed when trying to optimize bitcode file on -O3
https://llvm.org/bugs/show_bug.cgi?id=31114 Bug ID: 31114 Summary: Clang crashed when trying to optimize bitcode file on -O3 Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: pe...@trailofbits.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Note: It took a *LONG* time before it crashed. pag@sloth:~/Code/remill/build$ clang-3.9 -O3 -emit-llvm -c /tmp/nginx_core.bc -o /tmp/nginx_core_opt.bc warning: overriding the module target triple with x86_64-unknown-linux-gnu [-Woverride-module] terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc 0 clang-3.9 0x028132ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 72 1 clang-3.9 0x02813689 2 clang-3.9 0x0281162d llvm::sys::RunSignalHandlers() + 159 3 clang-3.9 0x02812a51 4 libpthread.so.0 0x7f45317253e0 5 libc.so.6 0x7f4530498428 gsignal + 56 6 libc.so.6 0x7f453049a02a abort + 362 7 libstdc++.so.6 0x7f4530dda84d __gnu_cxx::__verbose_terminate_handler() + 365 8 libstdc++.so.6 0x7f4530dd86b6 9 libstdc++.so.6 0x7f4530dd8701 10 libstdc++.so.6 0x7f4530dd8919 11 libstdc++.so.6 0x7f4530dd8ebc 12 clang-3.9 0x01e24e9a 13 clang-3.9 0x01e27fcd 14 clang-3.9 0x01e27720 15 clang-3.9 0x01e26a8d 16 clang-3.9 0x01e25101 17 clang-3.9 0x01e22c29 18 clang-3.9 0x01e1fd02 19 clang-3.9 0x01e1c4f5 20 clang-3.9 0x0284afed 21 clang-3.9 0x0284ba08 llvm::CloneAndPruneIntoFromInst(llvm::Function*, llvm::Function const*, llvm::Instruction const*, llvm::ValueMap > >&, bool, llvm::SmallVectorImpl&, char const*, llvm::ClonedCodeInfo*) + 753 22 clang-3.9 0x0284d00d llvm::CloneAndPruneFunctionInto(llvm::Function*, llvm::Function const*, llvm::ValueMap > >&, bool, llvm::SmallVectorImpl&, char const*, llvm::ClonedCodeInfo*, llvm::Instruction*) + 103 23 clang-3.9 0x028699f1 llvm::InlineFunction(llvm::CallSite, llvm::InlineFunctionInfo&, llvm::AAResults*, bool) + 2429 24 clang-3.9 0x02302945 25 clang-3.9 0x02304e65 llvm::Inliner::inlineCalls(llvm::CallGraphSCC&) + 3599 26 clang-3.9 0x02304053 llvm::Inliner::runOnSCC(llvm::CallGraphSCC&) + 65 27 clang-3.9 0x02302618 28 clang-3.9 0x0376d5bc 29 clang-3.9 0x0376e96f 30 clang-3.9 0x0376ecd8 31 clang-3.9 0x021d0b59 32 clang-3.9 0x021d12a3 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 271 33 clang-3.9 0x021d14af llvm::legacy::PassManager::run(llvm::Module&) + 39 34 clang-3.9 0x02ae012a 35 clang-3.9 0x02ae02fd clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) + 196 36 clang-3.9 0x0356b15f clang::CodeGenAction::ExecuteAction() + 2035 37 clang-3.9 0x030a6656 clang::FrontendAction::Execute() + 150 38 clang-3.9 0x03045d04 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1200 39 clang-3.9 0x031f255d clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1396 40 clang-3.9 0x016fb953 cc1_main(llvm::ArrayRef, char const*, void*) + 1069 41 clang-3.9 0x016ee392 42 clang-3.9 0x016eeea8 main + 2378 43 libc.so.6 0x7f4530483830 __libc_start_main + 240 44 clang-3.9 0x016ebac9 _start + 41 Stack dump: 0.Program arguments: /usr/local/bin/clang-3.9 -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -emit-llvm-uselists -disable-free -main-file-name nginx_core.bc -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -coverage-file /tmp/nginx_core_opt.bc -resource-dir /usr/local/bin/../lib/clang/3.9.0 -O3 -fdebug-compilation-dir /home/pag/Code/remill/build -ferror-limit 19 -fmessage-length 154 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/nginx_core_opt.bc -x ir /tmp/nginx_core.bc 1.Per-module optimization passes 2.Running pass 'CallGraph Pass Manager' on module '/tmp/nginx_core.bc'. clang-3.9: error: unable to execute command: Aborted clang-3.9: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.9.0 (tags/RELEASE_390/final)
[llvm-bugs] [Bug 31115] New: Braced-init-list misformatted with AlignAfterOpenBracket=AlwaysBreak
https://llvm.org/bugs/show_bug.cgi?id=31115
Bug ID: 31115
Summary: Braced-init-list misformatted with
AlignAfterOpenBracket=AlwaysBreak
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: gri...@griwes.info
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17633
--> https://llvm.org/bugs/attachment.cgi?id=17633&action=edit
an example
It seems that AlwaysBreak is disregarded for braced-init-lists, and instead
Align is used when either Align or AlwaysBreak are specified for
AlignAfterOpenBracket.
An example is attached. The config I'm using to run clang-format (reduced to
the necessary options) is:
-style='{BasedOnStyle: WebKit, AlignAfterOpenBracket: AlwaysBreak,
ColumnLimit: 80, BinPackArguments: false, Cpp11BracedListStyle: true}'
(Cpp11BracedListStyle doesn't matter; the only thing it changes is that with
it, the BinPackArguments option is respected. It'd be nice if it was possible
to respect it *without* removing the spaces from within the braces, but that's
not important here.)
The second line in main() in the example yields the expected result:
std::vector foo(
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname);
(This is obviously invalid code, but it illustrates the point.) The first line,
however, completely disregards AlignAfterOpenBracket=AlwaysBreak:
std::vector foo{verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname,
verylongname};
while the expected result is the same as for the second line, only with braces
instead of parentheses.
It wouldn't be *very* bad if not for some of my test files that construct
literals corresponding to an AST parsed by the tested code, which causes it to
be completely unreadable with Align. I *could* (and I guess I'll have to, for
now) run two configs, one for the tests that disables this and one for normal
code where this bug doesn't hurt readability that much (but does hurt it
nevertheless), but it's not very nice.
--
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 31116] New: SLP Vectorizer too aggressive with simple stores
https://llvm.org/bugs/show_bug.cgi?id=31116
Bug ID: 31116
Summary: SLP Vectorizer too aggressive with simple stores
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: ma...@braunis.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In a situation like the following (modeled after what happens in a C++
constructor with two base classes), the SLP vectorizer seems too aggressive:
struct C {
char *BaseA;
char *BaseB;
};
extern char VTab[];
void initC(C *c) {
c->BaseA = VTab + 48;
c->BaseB = VTab + 16;
}
The SLP Vectorizer transforms:
%BaseA = getelementptr inbounds %struct.C, %struct.C* %c, i64 0, i32 0
store i8* getelementptr inbounds ([0 x i8], [0 x i8]* @VTab, i64 0, i64 48),
i8** %BaseA, align 8, !tbaa !2
%BaseB = getelementptr inbounds %struct.C, %struct.C* %c, i64 0, i32 1
store i8* getelementptr inbounds ([0 x i8], [0 x i8]* @VTab, i64 0, i64 16),
i8** %BaseB, align 8, !tbaa !7
into:
%BaseA = getelementptr inbounds %struct.C, %struct.C* %c, i64 0, i32 0
%BaseB = getelementptr inbounds %struct.C, %struct.C* %c, i64 0, i32 1
%0 = bitcast i8** %BaseA to <2 x i8*>*
store <2 x i8*> , <2 x i8*>* %0, align 8, !tbaa !2
ret void
which results in this code on X86:
movq_VTab@GOTPCREL(%rip), %rax
leaq16(%rax), %rcx
movd%rcx, %xmm0
addq$48, %rax
movd%rax, %xmm1
punpcklqdq%xmm0, %xmm1## xmm1 = xmm1[0],xmm0[0]
movdqu%xmm1, (%rdi)
while it can be this if the SLP Vectorizer doesn't do anything:
movq_VTab@GOTPCREL(%rip), %rax
leaq48(%rax), %rcx
movq%rcx, (%rdi)
addq$16, %rax
movq%rax, 8(%rdi)
--
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 31117] New: crash on valid C code at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (Assertion `Headers.size() >= 2 && "Expected irreducible CFG; -loop-info is like
https://llvm.org/bugs/show_bug.cgi?id=31117 Bug ID: 31117 Summary: crash on valid C code at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (Assertion `Headers.size() >= 2 && "Expected irreducible CFG; -loop-info is likely invalid"' failed.) Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: chengnian...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ clang-trunk -v clang version 4.0.0 (trunk 287646) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -O3 small.c -w clang-4.0: /tmp/llvm-builder/llvm-source-trunk/lib/Analysis/BlockFrequencyInfoImpl.cpp:670: void findIrreducibleHeaders(const llvm::BlockFrequencyInfoImplBase&, const llvm::bfi_detail::IrreducibleGraph&, const std::vector&, llvm::BlockFrequencyInfoImplBase::LoopData::NodeList&, llvm::BlockFrequencyInfoImplBase::LoopData::NodeList&): Assertion `Headers.size() >= 2 && "Expected irreducible CFG; -loop-info is likely invalid"' failed. #0 0x01d1c425 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1d1c425) #1 0x01d1a3fe llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1d1a3fe) #2 0x01d1a562 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1d1a562) #3 0x7f02b50b6340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f02b3ea7cc9 gsignal /build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f02b3eab0d8 abort /build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f02b3ea0b86 __assert_fail_base /build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0 #7 0x7f02b3ea0c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x026348d8 llvm::BlockFrequencyInfoImplBase::analyzeIrreducible(llvm::bfi_detail::IrreducibleGraph const&, llvm::BlockFrequencyInfoImplBase::LoopData*, std::_List_iterator) (/usr/local/clang-trunk/bin/clang-4.0+0x26348d8) #9 0x0262a8d4 llvm::BlockFrequencyInfoImpl::calculate(llvm::Function const&, llvm::BranchProbabilityInfo const&, llvm::LoopInfo const&) (/usr/local/clang-trunk/bin/clang-4.0+0x262a8d4) #10 0x0262af90 llvm::BlockFrequencyInfo::calculate(llvm::Function const&, llvm::BranchProbabilityInfo const&, llvm::LoopInfo const&) (/usr/local/clang-trunk/bin/clang-4.0+0x262af90) #11 0x0163f0c2 (anonymous namespace)::CodeGenPrepare::eliminateMostlyEmptyBlocks(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x163f0c2) #12 0x01646690 (anonymous namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) [clone .part.1072] (/usr/local/clang-trunk/bin/clang-4.0+0x1646690) #13 0x01984663 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x1984663) #14 0x0198470c llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x198470c) #15 0x0198500f llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x198500f) #16 0x01e87c7a (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x1e87c7a) #17 0x01e89ab5 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::L
[llvm-bugs] [Bug 31118] New: AVX512: inefficient code generation
https://llvm.org/bugs/show_bug.cgi?id=31118
Bug ID: 31118
Summary: AVX512: inefficient code generation
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: roland.sch...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Compared to ICC 17u1 on KNL, clang produces inefficient code for intrinsic code
Steps to reproduce:
git clone -b clang https://github.com/rolandschulz/gromacs.git
cd gromacs
mkdir clang
cd clang
CC=clang CXX=clang++ cmake -DGMX_MPI=on -DGMX_SIMD=AVX_512_KNL
-DGMX_BUILD_HELP=OFF -DBUILD_SHARED_LIBS=no -DGMX_CYCLE_SUBCOUNTERS=yes ..
make
cd ..
mkdir icc
cd icc
CC=icc CXX=icpc cmake .. -DGMX_FFT_LIBRARY=mkl -DGMX_SIMD=AVX_512_KNL
-DGMX_MPI=on -DGMX_BUILD_HELP=OFF -DBUILD_SHARED_LIBS=no
-DGMX_CYCLE_SUBCOUNTERS=yes
On KNL (7250) for both binaries (clang/bin and icc/bin)
OMP_WAIT_POLICY=active mpirun -n 34 numactl -m 1 gmx_mpi mdrun -ntomp 4 -nsteps
8000 -resetstep 4000 -noconfout -nstlist 35 -npme 7 -notunepme -pin on
My results (values in second for function which is the most important compute
kernel and mostly intrinsics):
awk /Nonb/'{print $6}' md.log
ICC: 4.921
Clang: 5.349
--
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 31119] New: Infinite loop in SampleProfileLoader (inlineHotFunctions)
https://llvm.org/bugs/show_bug.cgi?id=31119
Bug ID: 31119
Summary: Infinite loop in SampleProfileLoader
(inlineHotFunctions)
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: greg_bedw...@sn.scee.net
CC: daniel...@gmail.com, dnovi...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
We've had a report from a user out in the field of a hang in the compiler that
occurs when -fprofile-sample-use is used. I can see that it's getting stuck in
SampleProfileLoader::inlineHotFunctions due to never breaking out of the
while(true). I've reduced the (large) user-provided testcase and constructed
the following simple one that demonstrates the behaviour:
$ type pgo.txt
#
==
_Z5alphav:102608:432
0.1: _Z4sort14GenericFunctor:105
#
==
$ type test.cpp
//
=
__attribute__((__nodebug__)) inline void _Sort(unsigned aa) {
if (aa)
_Sort(--aa);
}
struct GenericFunctor {
GenericFunctor() {}
};
unsigned depth;
__attribute__((__nodebug__)) inline void sort(GenericFunctor) { _Sort(depth); }
void alpha() { sort(GenericFunctor()); }
//
=
$ clang -target x86_64-unknown-unknown -v
clang version 4.0.0 (http://llvm.org/git/clang.git
76fd46ed36e54c6418eb2d9254d9b99d1528311b) (http://llvm.org/git/llvm.git
fcc1f76b4d065552630b28ec1d7959b692680c18)
Target: x86_64-unknown-unknown
Thread model: posix
InstalledDir:
C:\work\public-git\upstream-llvm\build-vs2015-ps4-master\Release\bin
$ clang -target x86_64-unknown-unknown -Rpass=sample -c test.cpp -O3 -g
$ clang -target x86_64-unknown-unknown -Rpass=sample -c test.cpp -O3 -g
-fprofile-sample-use=pgo.txt
test.cpp:11:16: remark: inlined hot callee '_Z4sort14GenericFunctor' with 105
samples into '_Z5alphav' [-Rpass=sample-profile]
void alpha() { sort(GenericFunctor()); }
^
test.cpp:11:16: remark: inlined hot callee '_Z5_Sortj' with 105 samples into
'_Z5alphav' [-Rpass=sample-profile]
test.cpp:11:16: remark: inlined hot callee '_Z5_Sortj' with 105 samples into
'_Z5alphav' [-Rpass=sample-profile]
test.cpp:11:16: remark: inlined hot callee '_Z5_Sortj' with 105 samples into
'_Z5alphav' [-Rpass=sample-profile]
test.cpp:11:16: remark: inlined hot callee '_Z5_Sortj' with 105 samples into
'_Z5alphav' [-Rpass=sample-profile]
test.cpp:11:16: remark: inlined hot callee '_Z5_Sortj' with 105 samples into
'_Z5alphav' [-Rpass=sample-profile]
test.cpp:11:16: remark: inlined hot callee '_Z5_Sortj' with 105 samples into
'_Z5alphav' [-Rpass=sample-profile]
test.cpp:11:16: remark: inlined hot callee '_Z5_Sortj' with 105 samples into
'_Z5alphav' [-Rpass=sample-profile]
^C
$
--
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 31120] New: Merge r287685 into the 3.9.x branch
https://llvm.org/bugs/show_bug.cgi?id=31120 Bug ID: 31120 Summary: Merge r287685 into the 3.9.x branch Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified r287685 is a follow-up to the changes merged in bug 30840. -- 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 31121] New: Clang crashes on dllexport inline methods with default arguments in PCH files in MS ABI mode
https://llvm.org/bugs/show_bug.cgi?id=31121
Bug ID: 31121
Summary: Clang crashes on dllexport inline methods with default
arguments in PCH files in MS ABI mode
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider:
$ cat t.h
struct __declspec(dllexport) Foo {
enum E { E0 } e;
Foo(E e = E0) : e(e) {}
};
$ cat t.cpp
$ clang-cl -FIt.h -Yct.h t.cpp
Assertion failed: DefaultArg && "sema forgot to instantiate default args", file
..\tools\clang\lib\CodeGen\MicrosoftCXXABI.cpp, line 3877
...
Basically, dllexport interacts with PCH in interesting ways that we should
seriously revisit.
This was reduced out of blink / WebKit, which had this issue here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/ViewportDescription.h?rcl=0&l=67
--
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 31122] New: [ARM] Assert in register allocation during last chance recoloring
https://llvm.org/bugs/show_bug.cgi?id=31122 Bug ID: 31122 Summary: [ARM] Assert in register allocation during last chance recoloring Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: llc Assignee: unassignedb...@nondot.org Reporter: ssija...@codeaurora.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17634 --> https://llvm.org/bugs/attachment.cgi?id=17634&action=edit Test case for register allocation There are two parts to this problem. Compiled using "llc -debug-only=regalloc test.ll", the attached test case fails with VirtRegMap.h:119: void llvm::VirtRegMap::clearVirt(unsigned int): Assertion `Virt2PhysMap[virtReg] != NO_PHYS_REG && "attempt to clear a not assigned virtual register"' failed. The code looks like: %vreg647 = COPY %vreg645; PR_with_dsub_7_then_ssub_0:%vreg647 PR:%vreg645 %vreg657 = COPY %vreg655; PR_with_dsub_7_then_ssub_0:%vreg657 PR:%vreg655 %vreg679 = COPY %vreg678; QPR_VFP2:%vreg679 QPR:%vreg678 %vreg657:dsub_7_then_ssub_0 = VDIVS %vreg679:ssub_2, %vreg647:dsub_7_then_ssub_0, pred:14, pred:%noreg; PR_with_dsub_7_then_ssub_0:%vreg657,%vreg647 QPR_VFP2:%vreg679 %vreg659 = COPY %vreg657; PR:%vreg659 PR_with_dsub_7_then_ssub_0:%vreg657 This problem occurs during last chance recoloring, where %vreg679 doesn’t get allocated (and is marked as not spillable), so last chance recoloring kicks in. It tries to allocate Q0 to %vreg679, where Q0 is assigned to %vreg647, which interferes with %vreg679. Upon trying to allocate a register to %vreg647, %vreg679 gets evicted from Q0. But %vreg679 is a fixed register, so it shouldn’t get evicted. Recoloring is thus deemed successful, and upon returning from tryRecoloringCandidates, we assert when trying to unassign %vreg679. I can get around this by moving the virtual register under consideration in tryLastChanceRecoloring (%vreg679) to RS_Done stage right before the call to tryRecolringCandidates, and then restoring the original stage afterward. This prevents the eviction of %vreg679 during recoloring. Alternatively, I can check FixedRegisters in canEvictInterference and return false. After this assert is gone, I run into “LLVM ERROR: ran out of registers during register allocation”. To get past this problem, we may need to spill an actual physical register to free it up for %vreg679 if last chance recoloring fails. -- 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 31123] New: [LTO] Reject modules without a datalayout
https://llvm.org/bugs/show_bug.cgi?id=31123 Bug ID: 31123 Summary: [LTO] Reject modules without a datalayout Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified In r287699, I changed lld to not emit an error when a bitcode file passed as input doesn't contain a datalayout. I previously added this check because we didn't set a default datalayout in lld and that caused the linker to crash. Now, lld switched to `lib/LTO` and we always call setDataLayout on the LTOModule. Mehdi (and Chandler) pointed out it would be a good thing(TM) to warn (or error?) on modules without a datalayout. I agree, and I think the right place to implement this (at least initially is lib/LTO). -- 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 31124] New: superlinear time in ARM instruction selection
https://llvm.org/bugs/show_bug.cgi?id=31124
Bug ID: 31124
Summary: superlinear time in ARM instruction selection
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: nlewy...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I have a testcase which looks like this:
void iTLB_bechmark_function() {
int a = 0, b = 0;
a = b + 1;
b = a + 1;
a = b + 1;
b = a + 1;
a = b + 1;
b = a + 1;
a = b + 1;
b = a + 1;
// ...
b = a + 1;
a = b + 1;
b = a + 1;
a = b + 1;
b = a + 1;
a = b + 1;
b = a + 1;
a = b + 1;
b = a + 1;
}
The unreduced testcase is 524291 lines long. With "clang -target
thumbv7-linux-gnueabi -S -o /dev/null iTLB_short.c -mthumb -ftime-report" we
can see that the ARM instruction selection is superlinear.
---User Time--- --System Time-- --User+System-- ---Wall Time--- ---
Name ---
At 100 lines:
0.0210 ( 68.7%) 0.0002 ( 54.8%) 0.0212 ( 68.6%) 0.0220 ( 70.2%) ARM
Instruction Selection
At 1000 lines:
0.2021 ( 78.8%) 0.0034 (100.0%) 0.2055 ( 79.1%) 0.2060 ( 79.3%) ARM
Instruction Selection
At 1 lines:
8.0935 ( 93.9%) 0.0120 (100.0%) 8.1055 ( 93.9%) 8.1029 ( 93.9%) ARM
Instruction Selection
At 10 lines:
1541.2256 ( 99.7%) 0.7040 ( 97.2%) 1541.9296 ( 99.7%) 1541.8429 ( 99.7%)
ARM Instruction Selection
Version: clang version 4.0.0 (trunk 287592) (llvm/trunk 287591)
Here's a sample backtrace:
#0 0x01ca3d9c in llvm::SDNode::getOpcode (this=0x1113c400) at
/usr/local/google/home/nlewycky/llvm/src/include/llvm/CodeGen/SelectionDAGNodes.h:541
#1 0x040c195c in (anonymous
namespace)::DAGCombiner::CombineToPostIndexedLoadStore (this=0x7fffa930,
N=0x10fa9710) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:10090
#2 0x040c3409 in (anonymous namespace)::DAGCombiner::visitLOAD
(this=0x7fffa930, N=0x10fa9710) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:10333
#3 0x04083a03 in (anonymous namespace)::DAGCombiner::visit
(this=0x7fffa930, N=0x10fa9710) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1459
#4 0x04083bad in (anonymous namespace)::DAGCombiner::combine
(this=0x7fffa930, N=0x10fa9710) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1480
#5 0x04082f9c in (anonymous namespace)::DAGCombiner::Run
(this=0x7fffa930, AtLevel=llvm::AfterLegalizeDAG) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1334
#6 0x040e2ce6 in llvm::SelectionDAG::Combine (this=0xdd44020,
Level=llvm::AfterLegalizeDAG, AA=..., OptLevel=llvm::CodeGenOpt::None) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:15464
#7 0x041c91eb in llvm::SelectionDAGISel::CodeGenAndEmitDAG
(this=0xa71ae10) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:844
#8 0x041c7e18 in llvm::SelectionDAGISel::SelectBasicBlock
(this=0xa71ae10, Begin=..., End=..., HadTailCall=@0x7fffb010: false) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:683
#9 0x041cc592 in llvm::SelectionDAGISel::SelectAllBasicBlocks
(this=0xa71ae10, Fn=...) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1558
#10 0x041c6d04 in llvm::SelectionDAGISel::runOnMachineFunction
(this=0xa71ae10, mf=...) at
/usr/local/google/home/nlewycky/llvm/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:504
#11 0x020b2ab4 in (anonymous
namespace)::ARMDAGToDAGISel::runOnMachineFunction (this=0xa71ae10, MF=...) at
/usr/local/google/home/nlewycky/llvm/src/lib/Target/ARM/ARMISelDAGToDAG.cpp:69
[...]
I don't know why, but it's only superlinear with arm+thumb, not on arm or on
x86.
--
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 31125] New: [InstCombine] pairs of icmps of phis of constants are not simplified
https://llvm.org/bugs/show_bug.cgi?id=31125
Bug ID: 31125
Summary: [InstCombine] pairs of icmps of phis of constants are
not simplified
Product: libraries
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: arie...@mail.tau.ac.il
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17635
--> https://llvm.org/bugs/attachment.cgi?id=17635&action=edit
A more complicated case that simplifycfg can't optimize
This seems to be the root cause of Rust issue
https://github.com/rust-lang/rust/issues/37930, which is causing slowness in
futures-rs.
Minified reproducer:
define i8 @start(i8* %addr) {
entry-block:
br label %main-loop
main-loop:
%phi = phi i8 [ 0, %entry-block ], [ 1, %core ]
%switch_0 = icmp eq i8 %phi, 0
store volatile i8 0, i8* %addr
br i1 %switch_0, label %busy-wait-phi-0, label %exit
busy-wait-phi-0:
%load = load volatile i8, i8* %addr
%icmp = icmp eq i8 %load, 0
br i1 %icmp, label %busy-wait-phi-0, label %core
core:
%switch_1 = icmp eq i8 %phi, 1
br i1 %switch_1, label %trap, label %main-loop
trap:
ret i8 1
exit:
ret i8 0
}
In the reproducer, `trap` can never be hit: %phi is obviously always 0 when you
enter core. SCCP should notice this (SimplifyCfg notices this simple case - but
it does not handle more complicated cases), but it seems to work only on
booleans, and relies on InstCombine to simplify integers to booleans.
If all icmps of the phi compare it against the same integer (e.g. if the `eq 1`
test is replaced with an `ne 0`), everything works well: InstCombine replaces
the integer with a boolean of the form
%phi = phi i1 [ true, %entry-block ], [ false, %core ]
and SCCP can work its magic.
However, if, as above, one of the icmps is against an `eq 1` and another is
against an `eq 0`, this optimization, and therefore SCCP, can't take place.
This might better be done by extending SCCP to integers instead of in
InstCombine.
--
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 31126] New: LLD does not understand --script=foo.ld
https://llvm.org/bugs/show_bug.cgi?id=31126 Bug ID: 31126 Summary: LLD does not understand --script=foo.ld Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: arichardson@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I worked around this issue by changing the build system to use -Wl,-T,foo.ld instead but it would be good if lld would also understand -Wl,--script=foo.ld -- 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 31119] Infinite loop in SampleProfileLoader (inlineHotFunctions)
https://llvm.org/bugs/show_bug.cgi?id=31119 Dehao Chen changed: 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 31126] LLD does not understand --script=foo.ld
https://llvm.org/bugs/show_bug.cgi?id=31126 Rui Ueyama changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |FIXED --- Comment #1 from Rui Ueyama --- Thank you for reporting. Fixed in r287711. -- 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 31127] New: PowerPC backend not parsing vector registers correctly
https://llvm.org/bugs/show_bug.cgi?id=31127
Bug ID: 31127
Summary: PowerPC backend not parsing vector registers correctly
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: sfan...@us.ibm.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
For the following input `a.s`
```
.text
.abiversion 2
.file"a.c"
.globlfoo
.p2align4
.typefoo,@function
foo:
xxswapd 0, 0
xxswapd 0, 0
```
If I run:
```
llvm-mc -triple powerpc64le-linux-gnu -mcpu pwr8 -filetype=obj a.s -o - |
llvm-objdump -disassemble -
```
I get:
```
:file format ELF64-ppc64
Disassembly of section .text:
foo:
0:56 02 00 f0 xxswapd 0, 32
4:56 02 00 f0 xxswapd 0, 32
```
Looks like the second register operand of the `xxswapd` instruction is being
parsed as vr32 instead of vr0.
This instruction is often used to implement the memcpy intrinsic, making codes
like:
```
#include
#include
int main(void) {
int A[10] = {0,1,2,3,4,5,6,7,8,9};
int B[10];
memcpy(&B[0], &A[0], sizeof(A));
for(int i=0; i<10; ++i)
printf("%d %d\n",A[i], B[i]);
return 0;
}
```
to return incorrect results if compiled with clang and the options -O0 and
-save-temps (or any other combination that separates the compile from the
assemble phases).
--
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 31128] New: Assigning to location counter without a space gives confusing error
https://llvm.org/bugs/show_bug.cgi?id=31128
Bug ID: 31128
Summary: Assigning to location counter without a space gives
confusing error
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: arichardson@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
in the following condensed linker script I get a confusing error message:
SECTIONS
{
/* ...*/
.= __code_body__;
/*...*/
}
Results in:
/home/alr48/cheri/output/sdk256/bin/cheri-unknown-freebsd-ld: error:
//sandbox.ld:66: : expected, but got ;
/home/alr48/cheri/output/sdk256/bin/cheri-unknown-freebsd-ld: error:
//sandbox.ld:66: .= __code_body__;
/home/alr48/cheri/output/sdk256/bin/cheri-unknown-freebsd-ld: error:
//sandbox.ld:66: ^
LLD will accept this script only after adding a space between '.' and '='
whereas GNU ld accepts this without complaining.
I am not sure if the space is required (all I can see is
https://sourceware.org/binutils/docs/ld/Simple-Assignments.html#Simple-Assignments
where there is no mention of spaces being required). In any case, a less
confusing error message would be great.
--
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 31129] New: Linker script: implement ALIGN(expr, align)
https://llvm.org/bugs/show_bug.cgi?id=31129 Bug ID: 31129 Summary: Linker script: implement ALIGN(expr,align) Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: arichardson@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified In the following linker script lld fails to parse the ALIGN() expression __bss_start = ADDR(.bss); __bss_end = ALIGN(__bss_start + SIZEOF(.bss), 0x8); The error I get is ") expected, but got ,". Looking at LinkerScript.cpp it seems that ALIGN currently only handles one argument. -- 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
