[llvm-bugs] [Bug 27931] New: PPC64 Target initDwarfEHRegSizeTable has wrong register size and there is no register 114, 115, 116
https://llvm.org/bugs/show_bug.cgi?id=27931
Bug ID: 27931
Summary: PPC64 Target initDwarfEHRegSizeTable has wrong
register size and there is no register 114, 115, 116
Product: clang
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: bluechristl...@163.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In the PPC64TargetCodeGenInfo, we have one function initDwarfEHRegSizeTable to
support built in function __builtin_init_dwarf_reg_size_table. However,
according to ABI ducumentation:
http://openpowerfoundation.org/?resource_lib=power-architecture-64-bit-elf-v2-abi-specification-also-openpower-abi-for-linux-supplement
page 91 Table 2-23 and GCC supplement output (see blow example), we can find
that register 64 to register 67 width is 8 bytes, but our implementatio is 4
bytes. code is here:
// 64-76 are various 4-byte special-purpose registers:
// 64: mq
// 65: lr
// 66: ctr
// 67: ap
// 68-75 cr0-7
// 76: xer
AssignToArrayRange(Builder, Address, Four8, 64, 76);
Meanwhile, according to this table and GCC supplement output, we can find we
omit register tfhar, register tfiar, register texasr, which are numbered as
114, 115 and 116. But now, we only have 113.
// 109: vrsave
// 110: vscr
// 111: spe_acc
// 112: spefscr
// 113: sfp
AssignToArrayRange(Builder, Address, Four8, 109, 113);
So, we should add it.
One test code of GCC output supplement:
[code]
int arr[1024];
int main() {
__builtin_init_dwarf_reg_size_table(arr);
return 0;
}
[/code]
gcc t.c -S
the assembly file is:
...
.LC0:
.quad arr
.LC1:
.quad arr+1
.LC2:
.quad arr+2
.LC3:
.quad arr+3
.LC4:
.quad arr+4
.LC5:
.quad arr+5
.LC6:
.quad arr+6
..
addis 10,2,.LC64@toc@ha
ld 9,.LC64@toc@l(10)
li 10,8
stb 10,0(9)
addis 10,2,.LC65@toc@ha
ld 9,.LC65@toc@l(10)
li 10,8
stb 10,0(9)
addis 10,2,.LC66@toc@ha
ld 9,.LC66@toc@l(10)
li 10,8
stb 10,0(9)
addis 10,2,.LC67@toc@ha
ld 9,.LC67@toc@l(10)
li 10,8
stb 10,0(9)
addis 10,2,.LC68@toc@ha
ld 9,.LC68@toc@l(10)
li 10,4
stb 10,0(9)
...
addis 10,2,.LC113@toc@ha
ld 9,.LC113@toc@l(10)
li 10,8
stb 10,0(9)
addis 10,2,.LC114@toc@ha
ld 9,.LC114@toc@l(10)
li 10,8
stb 10,0(9)
addis 10,2,.LC115@toc@ha
ld 9,.LC115@toc@l(10)
li 10,8
stb 10,0(9)
addis 10,2,.LC116@toc@ha
ld 9,.LC116@toc@l(10)
li 10,8
stb 10,0(9)
--
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 27932] New: build mesa error in backend: symbol 'x86_64_entry_start'
https://llvm.org/bugs/show_bug.cgi?id=27932 Bug ID: 27932 Summary: build mesa error in backend: symbol 'x86_64_entry_start' Product: new-bugs Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: hepha.l...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified hello build mesa 11.3.0-devel show this error How to deal with thank you OS : ARCH entry-909113.c http://paste.ubuntu.com/16831086/ entry-909113.sh http://paste.ubuntu.com/16831122/ fatal error: error in backend: symbol 'x86_64_entry_start' is already defined clang-3.9: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.9.0 (trunk) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin clang-3.9: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.9: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.9: note: diagnostic msg: /tmp/entry-909113.c clang-3.9: note: diagnostic msg: /tmp/entry-909113.sh clang-3.9: note: diagnostic msg: Makefile:1450: recipe for target 'shared_glapi_libglapi_la-entry.lo' failed make[4]: *** [shared_glapi_libglapi_la-entry.lo] Error 1 make[4]: *** Waiting for unfinished jobs make[4]: Leaving directory '/mnt/warehouse/aur/mesa-git/src/mesa/src/mapi' Makefile:1644: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/mnt/warehouse/aur/mesa-git/src/mesa/src/mapi' Makefile:1109: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/mnt/warehouse/aur/mesa-git/src/mesa/src/mapi' Makefile:696: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/mnt/warehouse/aur/mesa-git/src/mesa/src' Makefile:643: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 -- 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 27933] New: engine not emit location check callback where it should
https://llvm.org/bugs/show_bug.cgi?id=27933
Bug ID: 27933
Summary: engine not emit location check callback where it
should
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: hume...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I'm writing a plugin that do location check as in ArrayBoundCheck plugin, but
in some cases the callback is not called:
checkLocation(SVal location, bool isLoad, const Stmt* LoadS, CheckerContext
&checkerContext) const
for the folling test, it's ok
void test(int a, int b) {
if (a > 10 && b > 10)
{
char x[10];
int z = a+1+b;
x[z] = 5; // expected-warning{{out-of-bound}}
}
}
but for the second test no callback is emitted, I think this is obviously a
bug:
void test(int a, int b) {
if (a > 10 && b > 10)
{
char x[10];
x[a+1+b] = 5; // expected-warning{{out-of-bound}}
}
}
--
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 27759] [Meta] Remove exit-on-error flag
https://llvm.org/bugs/show_bug.cgi?id=27759 Bug 27759 depends on bug 27768, which changed state. Bug 27768 Summary: Remove exit-on-error from test/CodeGen/BPF/struct_ret1.ll https://llvm.org/bugs/show_bug.cgi?id=27768 What|Removed |Added Status|ASSIGNED|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 27768] Remove exit-on-error from test/CodeGen/BPF/struct_ret1.ll
https://llvm.org/bugs/show_bug.cgi?id=27768 Diana Picus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Diana Picus --- r271200 -- 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 27769] Remove exit-on-error from test/CodeGen/BPF/struct_ret2.ll
https://llvm.org/bugs/show_bug.cgi?id=27769 Diana Picus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Diana Picus --- r271200 -- 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 27759] [Meta] Remove exit-on-error flag
https://llvm.org/bugs/show_bug.cgi?id=27759 Bug 27759 depends on bug 27769, which changed state. Bug 27769 Summary: Remove exit-on-error from test/CodeGen/BPF/struct_ret2.ll https://llvm.org/bugs/show_bug.cgi?id=27769 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 27934] New: cannot find overload for unary expression
https://llvm.org/bugs/show_bug.cgi?id=27934 Bug ID: 27934 Summary: cannot find overload for unary expression Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: noelgran...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16433 --> https://llvm.org/bugs/attachment.cgi?id=16433&action=edit self-contained test case See attached test-case. This is a stripped down copy of a utility library from LibreOffice codebase. code was compiled with: clang++ -std=c++11 testcase.cxx and generates error: typed_flags_testcase.cxx:253:48: error: invalid argument type 'typename o3tl::typed_flags::Wrap' to unary expression ComplexTextLayoutFlags n1(nOldLayoutMode & ~(ComplexTextLayoutFlags::ComplexDisabled|ComplexTextLayoutFlags::BiDiStrong)); ^ 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27935] New: Linking CXX executable lldb-argdumper and lldb-mi fails
https://llvm.org/bugs/show_bug.cgi?id=27935 Bug ID: 27935 Summary: Linking CXX executable lldb-argdumper and lldb-mi fails Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: ved...@miletic.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified On Debian 8 with $ g++ --version g++ (Debian 4.9.2-10) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. building LLDB inside LLVM tree with $ cmake -DBUILD_SHARED_LIBS=ON -DLLVM_LIBDIR_SUFFIX= .. results in Linking CXX executable ../../../../bin/lldb-argdumper Linking CXX executable ../../../../bin/lldb-mi ../../../../lib/liblldbUtility.a(JSON.cpp.o): In function `lldb_private::JSONNumber::GetAsUnsigned() const': /home/vedranm/workspace/llvm/tools/lldb/source/Utility/JSON.cpp:76: undefined reference to `llvm::llvm_unreachable_internal(char const*, char const*, unsigned int)' ../../../../lib/liblldbUtility.a(JSON.cpp.o): In function `lldb_private::JSONNumber::GetAsSigned() const': /home/vedranm/workspace/llvm/tools/lldb/source/Utility/JSON.cpp:91: undefined reference to `llvm::llvm_unreachable_internal(char const*, char const*, unsigned int)' ../../../../lib/liblldbUtility.a(JSON.cpp.o): In function `lldb_private::JSONNumber::GetAsDouble() const': /home/vedranm/workspace/llvm/tools/lldb/source/Utility/JSON.cpp:106: undefined reference to `llvm::llvm_unreachable_internal(char const*, char const*, unsigned int)' collect2: error: ld returned 1 exit status tools/lldb/tools/argdumper/CMakeFiles/lldb-argdumper.dir/build.make:179: recipe for target 'bin/lldb-argdumper' failed make[2]: *** [bin/lldb-argdumper] Error 1 CMakeFiles/Makefile2:27035: recipe for target 'tools/lldb/tools/argdumper/CMakeFiles/lldb-argdumper.dir/all' failed make[1]: *** [tools/lldb/tools/argdumper/CMakeFiles/lldb-argdumper.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs CMakeFiles/lldb-mi.dir/MIUtilParse.cpp.o: In function `MIUtilParse::CRegexParser::CRegexParser(char const*)': /home/vedranm/workspace/llvm/tools/lldb/tools/lldb-mi/MIUtilParse.cpp:24: undefined reference to `llvm_regcomp' CMakeFiles/lldb-mi.dir/MIUtilParse.cpp.o: In function `MIUtilParse::CRegexParser::~CRegexParser()': /home/vedranm/workspace/llvm/tools/lldb/tools/lldb-mi/MIUtilParse.cpp:39: undefined reference to `llvm_regfree' CMakeFiles/lldb-mi.dir/MIUtilParse.cpp.o: In function `MIUtilParse::CRegexParser::Execute(char const*, MIUtilParse::CRegexParser::Match&, unsigned long)': /home/vedranm/workspace/llvm/tools/lldb/tools/lldb-mi/MIUtilParse.cpp:65: undefined reference to `llvm_regexec' collect2: error: ld returned 1 exit status tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/build.make:2004: recipe for target 'bin/lldb-mi-3.9.0' failed make[2]: *** [bin/lldb-mi-3.9.0] Error 1 CMakeFiles/Makefile2:27323: recipe for target 'tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/all' failed make[1]: *** [tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/all] Error 2 Makefile:137: recipe for target 'all' failed make: *** [all] Error 2 -- 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 27936] New: Object invariant violation: FunctionType set
https://llvm.org/bugs/show_bug.cgi?id=27936
Bug ID: 27936
Summary: Object invariant violation: FunctionType set
Product: clang
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: eugvelesev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16434
--> https://llvm.org/bugs/attachment.cgi?id=16434&action=edit
test
I added this assert code to FoldingSetImpl::InsertNode function
(lib/Support/FoldingSet.cpp):
void FoldingSetImpl::InsertNode(Node *N, void *InsertPos) {
+#ifndef NDEBUG
+ FoldingSetNodeID ID;
+ GetNodeProfile(N, ID);
+ void *InsertPos2 = 0;
+ Node *N2 = FindNodeOrInsertPos(ID, InsertPos2);
+ assert(!N2 && "Node has already been in the set");
+ assert(InsertPos == InsertPos2 && "Incorrect InsertPos");
+#endif
The first assert fails (if compile with -std=c++11) on the attached test with
stacktrace:
llvm/lib/Support/FoldingSet.cpp:336: void
llvm::FoldingSetImpl::InsertNode(llvm::FoldingSetImpl::Node*, void*): Assertion
`!N2 && "Node has already been in the set"' failed.
...
#9 0x02f94b5e
llvm::FoldingSetImpl::InsertNode(llvm::FoldingSetImpl::Node*, void*)
llvm/lib/Support/FoldingSet.cpp:337:0
#10 0x02f94943 llvm::FoldingSetImpl::GrowHashTable()
llvm/lib/Support/FoldingSet.cpp:294:0
#11 0x02f94bf0
llvm::FoldingSetImpl::InsertNode(llvm::FoldingSetImpl::Node*, void*)
llvm/lib/Support/FoldingSet.cpp:343:0
#12 0x05275306 clang::ASTContext::getFunctionType(clang::QualType,
llvm::ArrayRef, clang::FunctionProtoType::ExtProtoInfo const&)
const clang/lib/AST/ASTContext.cpp:3115:0
#13 0x052750c5 clang::ASTContext::getFunctionType(clang::QualType,
llvm::ArrayRef, clang::FunctionProtoType::ExtProtoInfo const&)
const clang/lib/AST/ASTContext.cpp:3071:0
...
Thats means there are two same FunctionProtoType objects in the set. So it
follows that we modify an object (and change hash) placed in the set.
I researched the issue placing a couple of breakpoints and found this:
A hash of FunctionProtoType depends on CanonicalDecl of ExceptionSpec
SourceDecl stored in ExtProtoInfo.
FunctionProtoType::Profile:
..
ID.AddPointer(epi.ExceptionSpec.SourceDecl->getCanonicalDecl())
..
But when clang create destructor(dtor) via clang::Sema::ActOnFunctionDeclarator
at lib/Sema/SemaDecl.cpp:7341 we use the created dtor as SourceDecl in
ExceptionSpec(in function Sema::AdjustDestructorExceptionSpec called
immediately after dtor creation) that results in creation new FunctionProtoType
because there cannot be a type in the set with just created dtor(without
previous decl) as set key. Later we call FunctionDecl::setPreviousDeclaration
for the dtor setting new canonical decl and changing the hash.
--
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 27932] build mesa error in backend: symbol 'x86_64_entry_start'
https://llvm.org/bugs/show_bug.cgi?id=27932 Dimitry Andric changed: What|Removed |Added Status|NEW |RESOLVED CC||dimi...@andric.com Resolution|--- |DUPLICATE --- Comment #1 from Dimitry Andric --- This is a known problem. See bug 19778 for the workaround, which has been required since 2014. :-/ *** This bug has been marked as a duplicate of bug 19778 *** -- 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 27937] New: codecvt::do_out does not set from_next and to_next correctly on error
https://llvm.org/bugs/show_bug.cgi?id=27937 Bug ID: 27937 Summary: codecvt::do_out does not set from_next and to_next correctly on error Product: libc++ Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: r...@abittechnical.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified Created attachment 16436 --> https://llvm.org/bugs/attachment.cgi?id=16436&action=edit Program that reproduces the issue I've noticed that our software when building on Mac OS X or FreeBSD with libc++ has a failing test due to std::codecvt::do_out not properly assigning from_next and to_next when it returns std::codecvt::error. I don't have a copy of the final standard, but the draft specification of C++14 I found (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf) says that "It always leaves the from_next and to_next pointers pointing one beyond the last element successfully converted" in ยง22.4.1.4.2. If my interpretation of that specification is correct, then I think it's supposed to convert as many characters as it can and set from_next and to_next to one position past the last correctly converted character. This is also the behavior of libstdc++ and MSVC. However, with libc++, from_next and to_next are placed back in their original position. I attached a test program that reproduces the issue. The expected output is: Error! pwc is now at position: 7 pc is now at position: 7 The actual output is: Error! pwc is now at position: 0 pc is now at position: 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 27938] New: The scalarizer pass remove debugloc from call instruction
https://llvm.org/bugs/show_bug.cgi?id=27938 Bug ID: 27938 Summary: The scalarizer pass remove debugloc from call instruction Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: karl-johan.karls...@ericsson.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16437 --> https://llvm.org/bugs/attachment.cgi?id=16437&action=edit Reproducer: opt -S -scalarizer -o - foo.ll The scalarizer pass (-scalarizer) remove the debugloc from a call instruction. The verifier pass later give the error message: inlinable function call in a function with debug info must have a !dbg location %_tmp7 = tail call i16 @f1() LLVM ERROR: Broken function found, compilation aborted! The problem seems to be in the method Scalarizer::transferMetadata() that always transfer the debugloc regardless of if the debugloc that is being transfered is set or not. I'm also a bit unsure if it is a good idea to overwrite the debugloc of an instruction that already got a perfectly fine debugloc, why is it guaranteed that the new one is better? Reproducer: opt -S -scalarizer -o - foo.ll -- 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 27939] New: R_X86_64_GOTPCRELX reocations are not produced properly
https://llvm.org/bugs/show_bug.cgi?id=27939
Bug ID: 27939
Summary: R_X86_64_GOTPCRELX reocations are not produced
properly
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: MC
Assignee: unassignedb...@nondot.org
Reporter: gri...@accesssoftek.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16438
--> https://llvm.org/bugs/attachment.cgi?id=16438&action=edit
testcase
Using attached testcase and following commandline, there is no
R_X86_64_GOTPCRELX relocations produced my llvm-mc:
llvm-mc -relax-relocations -filetype=obj -triple=x86_64-pc-linux test.s -o
test.o
llvm-readobj -r test.o
LoadName:
Relocations [
Section (3) .rela.text {
0x2 R_X86_64_GOTPCREL bar 0xFFFC
0x8 R_X86_64_GOTPCREL bar 0xFFFC
0xE R_X86_64_GOTPCREL bar 0xFFFC
0x14 R_X86_64_GOTPCREL bar 0xFFFC
0x1A R_X86_64_GOTPCREL bar 0xFFFC
0x20 R_X86_64_GOTPCREL bar 0xFFFC
0x26 R_X86_64_GOTPCREL bar 0xFFFC
0x2D R_X86_64_GOTPCREL bar 0xFFFC
0x34 R_X86_64_GOTPCREL bar 0xFFFC
0x3B R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x42 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x49 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x50 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x57 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x5E R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x65 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x6C R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x73 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x79 R_X86_64_GOTPCREL foo 0xFFFC
0x7F R_X86_64_GOTPCREL foo 0xFFFC
0x85 R_X86_64_GOTPCREL foo 0xFFFC
0x8B R_X86_64_GOTPCREL foo 0xFFFC
0x91 R_X86_64_GOTPCREL foo 0xFFFC
0x97 R_X86_64_GOTPCREL foo 0xFFFC
0x9D R_X86_64_GOTPCREL foo 0xFFFC
0xA4 R_X86_64_GOTPCREL foo 0xFFFC
0xAB R_X86_64_GOTPCREL foo 0xFFFC
0xB2 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xB9 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xC0 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xC7 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xCE R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xD5 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xDC R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xE3 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xEA R_X86_64_REX_GOTPCRELX foo 0xFFFC
}
]
While gas produces them:
as --64 -mrelax-relocations=yes test.s -o test.o
LoadName:
Relocations [
Section (2) .rela.text {
0x2 R_X86_64_GOTPCRELX bar 0xFFFC
0x8 R_X86_64_GOTPCRELX bar 0xFFFC
0xE R_X86_64_GOTPCRELX bar 0xFFFC
0x14 R_X86_64_GOTPCRELX bar 0xFFFC
0x1A R_X86_64_GOTPCRELX bar 0xFFFC
0x20 R_X86_64_GOTPCRELX bar 0xFFFC
0x26 R_X86_64_GOTPCRELX bar 0xFFFC
0x2D R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x34 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x3B R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x42 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x49 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x50 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x57 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x5E R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x65 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x6C R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x73 R_X86_64_REX_GOTPCRELX bar 0xFFFC
0x79 R_X86_64_GOTPCRELX foo 0xFFFC
0x7F R_X86_64_GOTPCRELX foo 0xFFFC
0x85 R_X86_64_GOTPCRELX foo 0xFFFC
0x8B R_X86_64_GOTPCRELX foo 0xFFFC
0x91 R_X86_64_GOTPCRELX foo 0xFFFC
0x97 R_X86_64_GOTPCRELX foo 0xFFFC
0x9D R_X86_64_GOTPCRELX foo 0xFFFC
0xA4 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xAB R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xB2 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xB9 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xC0 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xC7 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xCE R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xD5 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xDC R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xE3 R_X86_64_REX_GOTPCRELX foo 0xFFFC
0xEA R_X86_64_REX_GOTPCRELX foo 0xFFFC
}
]
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mail
[llvm-bugs] [Bug 27940] New: DSE Produce different result with/-out debug intrinsic
https://llvm.org/bugs/show_bug.cgi?id=27940 Bug ID: 27940 Summary: DSE Produce different result with/-out debug intrinsic Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: henric.karls...@ericsson.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- 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 27941] New: Clang segfaults when considering non-special defaulted assignment operator.
https://llvm.org/bugs/show_bug.cgi?id=27941 Bug ID: 27941 Summary: Clang segfaults when considering non-special defaulted assignment operator. Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16440 --> https://llvm.org/bugs/attachment.cgi?id=16440&action=edit reprod -- 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 27942] New: Matrix std::inner_product optimization issues
https://llvm.org/bugs/show_bug.cgi?id=27942 Bug ID: 27942 Summary: Matrix std::inner_product optimization issues Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: peet@yandex.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Clang/LLVM generates inefficient code for the inner product of two matrices. Reproduction code: https://gist.github.com/cynecx/e1b44a67e74bac257ed9e632c982fc7f The code clang generates: === Matrix<(unsigned short)3, (unsigned short)3, float> Matrix<(unsigned short)3, (unsigned short)3, float>::operator*<(unsigned short)3>(Matrix<(unsigned short)3, (unsigned short)3, float> const&): # @Matrix<(unsigned short)3, (unsigned short)3, float> Matrix<(unsigned short)3, (unsigned short)3, float>::operator*<(unsigned short)3>(Matrix<(unsigned short)3, (unsigned short)3, float> const&) pushr15 pushr14 pushr13 pushr12 pushrbx sub rsp, 160 mov r14, rdx mov r13, rsi mov r15, rdi xorps xmm0, xmm0 movups xmmword ptr [r15 + 16], xmm0 movups xmmword ptr [r15], xmm0 mov dword ptr [r15 + 32], 0 lea r12, [rsp + 98] xor ebx, ebx .LBB1_1:# %_ZN6MatrixILt3ELt3EfE14GetRowAccessorEt.exit1 mov qword ptr [rsp + 136], r13 mov qword ptr [rsp + 144], rbx mov word ptr [rsp + 152], 0 mov qword ptr [rsp + 112], r13 mov qword ptr [rsp + 120], rbx mov word ptr [rsp + 128], 3 mov qword ptr [rsp + 88], r14 mov word ptr [rsp + 96], 0 mov ax, word ptr [rsp + 86] mov word ptr [r12 + 4], ax mov eax, dword ptr [rsp + 82] mov dword ptr [r12], eax mov word ptr [rsp + 104], 0 mov rax, qword ptr [rsp + 104] mov qword ptr [rsp + 64], rax movups xmm0, xmmword ptr [rsp + 88] movups xmmword ptr [rsp + 48], xmm0 mov rax, qword ptr [rsp + 128] mov qword ptr [rsp + 40], rax movups xmm0, xmmword ptr [rsp + 112] movups xmmword ptr [rsp + 24], xmm0 mov rax, qword ptr [rsp + 152] mov qword ptr [rsp + 16], rax movups xmm0, xmmword ptr [rsp + 136] movups xmmword ptr [rsp], xmm0 xorps xmm0, xmm0 callfloat std::inner_product::MatrixAccessorIterator::MatrixRowAccessor >, (unsigned short)3>, Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterator::MatrixColumnAccessor const>, (unsigned short)3>, float>(Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterator::MatrixRowAccessor >, (unsigned short)3>, Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterator::MatrixRowAccessor >, (unsigned short)3>, Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterator::MatrixColumnAccessor const>, (unsigned short)3>, float) movss dword ptr [r15 + 4*rbx], xmm0 mov qword ptr [rsp + 136], r13 mov qword ptr [rsp + 144], rbx mov word ptr [rsp + 152], 0 mov qword ptr [rsp + 112], r13 mov qword ptr [rsp + 120], rbx mov word ptr [rsp + 128], 3 mov qword ptr [rsp + 88], r14 mov word ptr [rsp + 96], 1 mov ax, word ptr [rsp + 86] mov word ptr [r12 + 4], ax mov eax, dword ptr [rsp + 82] mov dword ptr [r12], eax mov word ptr [rsp + 104], 0 mov rax, qword ptr [rsp + 104] mov qword ptr [rsp + 64], rax movups xmm0, xmmword ptr [rsp + 88] movups xmmword ptr [rsp + 48], xmm0 mov rax, qword ptr [rsp + 128] mov qword ptr [rsp + 40], rax movups xmm0, xmmword ptr [rsp + 112] movups xmmword ptr [rsp + 24], xmm0 mov rax, qword ptr [rsp + 152] mov qword ptr [rsp + 16], rax movups xmm0, xmmword ptr [rsp + 136] movups xmmword ptr [rsp], xmm0 xorps xmm0, xmm0 callfloat std::inner_product::MatrixAccessorIterator::MatrixRowAccessor >, (unsigned short)3>, Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterator::MatrixColumnAccessor const>, (unsigned short)3>, float>(Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterator::MatrixRowAccessor >, (unsigned short)3>, Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterator::MatrixRowAccessor >, (unsigned short)3>, Matrix<(unsigned short)3, (unsigned short)3, float>::MatrixAccessorIterato
[llvm-bugs] [Bug 27943] New: powerpc: "Bad machine code: Using an undefined physical register"
https://llvm.org/bugs/show_bug.cgi?id=27943 Bug ID: 27943 Summary: powerpc: "Bad machine code: Using an undefined physical register" Product: new-bugs Version: 3.8 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: vtjn...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16441 --> https://llvm.org/bugs/attachment.cgi?id=16441&action=edit bugpoint-reduced powerpc64le peephole optimization bug The attached code asserts when compiling with llc (no extra arguments needed), in what appears to be a failure to update the imp-def register list during instruction replacement by Peephole Optimizations. The observed error message is: ``` *** Bad machine code: Using an undefined physical register *** - function:julia_gcd_50079 - basic block: BB#4 L14 (0x7fae4202aa98) - instruction: %vreg121 = COPY - operand 1: %CR0 LLVM ERROR: Found 1 machine code errors. ``` Before peephole optimizations, the SUBFC8 is used: ``` # *** IR Dump After Machine code sinking ***: %vreg24 = SUBFC8 %vreg18, %vreg12, %CARRY; G8RC_and_G8RC_NOX0:%vreg24 G8RC:%vreg18,%vreg12 ``` Afterwards, the `SUBFC8o` alias is used instead (this replacement is correct): ``` # *** IR Dump After Peephole Optimizations ***: %vreg24 = SUBFC8o %vreg18, %vreg12, %CARRY; G8RC_and_G8RC_NOX0:%vreg24 G8RC:%vreg18,%vreg12 %vreg35 = COPY %CR0; CRRC:%vreg35 ``` However, this replacement should have added `%CR0`, but didn't. (the PPCInstrInfo.td entry for `multiclass XOForm_1rc` of which this instruction is an alias of an instance reflects this 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 27944] New: Miscompile after Sanjoy's SCEV changes
https://llvm.org/bugs/show_bug.cgi?id=27944 Bug ID: 27944 Summary: Miscompile after Sanjoy's SCEV changes Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified It seems that after Sanjoys SCEV changes that happend between 115336 and 115351 a miscompile was introduced in FAIL: lencod.execution_time http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable/builds/3034 To the the build-breakage that happened before it is not easily possible to track down the precise version. -- 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 27945] New: Compiler crash in "Induction Variable Simplification" for "-fno-exceptions"
https://llvm.org/bugs/show_bug.cgi?id=27945 Bug ID: 27945 Summary: Compiler crash in "Induction Variable Simplification" for "-fno-exceptions" Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mich...@sloede.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16442 --> https://llvm.org/bugs/attachment.cgi?id=16442&action=edit Stack trace, run script, preprocessed source Given certain optimization flags, clang crashes in "Induction Variable Simplification" during compilation. This behavior was observed both with r270962 and r271230, but not with r253770. The bug can be triggered/prevented reproducibly by adding/omitting the "-fno-exceptions" flag. Here is the full stacktrace: AILED: /pds/opt/llvm-20160530-r271230/bin/clang++-O3 -DNDEBUG -mtune=native -fvectorize -fslp-vectorize -DUSE_RESTRICT -DCOMPILER_ATTRIBUTES -DDISABLE_FV_MG -fstrict-aliasing -fslp-vectorize-aggressive -fno-rtti -fno-exceptions -fomit-frame-pointer -march=native -mtune=native -std=c++14 -stdlib=libc++ -Wall -Wextra -pedantic -Wshadow -Wfloat-equal -Wcast-align -Wfloat-equal -Wdisabled-optimization -Wformat=2 -Winvalid-pch -Winit-self -Wmissing-include-dirs -Wredundant-decls -Wpacked -Wpointer-arith -Wstack-protector -Wswitch-default -Wwrite-strings -Wno-type-safety -Werror -Wunused -Wno-infinite-recursion -Wno-undefined-var-template -Isrc -isystem /pds/opt/fftw/include -isystem /pds/opt/parallel-netcdf-1.7.0/include -isystem /pds/opt/openmpi/include -MMD -MT src/CMakeFiles/zfs.dir/zfsfvmbblock3d.cpp.o -MF src/CMakeFiles/zfs.dir/zfsfvmbblock3d.cpp.o.d -o src/CMakeFiles/zfs.dir/zfsfvmbblock3d.cpp.o -c src/zfsfvmbblock3d.cpp clang-3.9: /pds/opt/install/llvm/llvm-20160530-r271230-src/lib/Transforms/Scalar/IndVarSimplify.cpp:2105: bool (anonymous namespace)::IndVarSimplify::run(llvm::Loop *): Assertion `L->isRecursivelyLCSSAForm(*DT) && "LCSSA required to run indvars!"' failed. #0 0x000001a48248 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x1a48248) #1 0x01a48977 SignalHandler(int) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x1a48977) #2 0x7f3ea3c6f870 __restore_rt (/lib64/libpthread.so.0+0xf870) #3 0x7f3ea2eb00a7 __GI_raise (/lib64/libc.so.6+0x350a7) #4 0x7f3ea2eb1458 __GI_abort (/lib64/libc.so.6+0x36458) #5 0x7f3ea2ea9126 __assert_fail_base (/lib64/libc.so.6+0x2e126) #6 0x7f3ea2ea91d2 (/lib64/libc.so.6+0x2e1d2) #7 0x018d65f8 (anonymous namespace)::IndVarSimplify::run(llvm::Loop*) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x18d65f8) #8 0x018cf698 (anonymous namespace)::IndVarSimplifyLegacyPass::runOnLoop(llvm::Loop*, llvm::LPPassManager&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x18cf698) #9 0x00000242383e llvm::LPPassManager::runOnFunction(llvm::Function&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x242383e) #10 0x0000016474e4 llvm::FPPassManager::runOnFunction(llvm::Function&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x16474e4) #11 0x02402588 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x2402588) #12 0x01647bf5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x1647bf5) #13 0x01ba9353 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x1ba9353) #14 0x022d5a8d clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x22d5a8d) #15 0x026ab6a6 clang::ParseAST(clang::Sema&, bool, bool) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x26ab6a6) #16 0x01f777c5 clang::FrontendAction::Execute() (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x1f777c5) #17 0x01f3ece1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x1f3ece1) #18 0x0200d645 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x200d645) #19 0x007839d7 cc1_main(llvm::ArrayRef, char const*, void*) (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x7839d7) #20 0x0078247d main (/aia/opt/llvm-20160530-r271230/bin/clang-3.9+0x78247d) #21 0x7f3ea2e9cb05 __libc_start_main (/lib64/libc.so.6+0x21b05) #22 0x0077f282 _start /home/abuild/rpmb
