[llvm-bugs] [Bug 36689] Failure to zextload due to unused bits
https://bugs.llvm.org/show_bug.cgi?id=36689 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||327530 Status|NEW |RESOLVED --- Comment #4 from Simon Pilgrim --- This was fixed by rL327530 - thanks Craig! -- 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 37586] New: update_test_checks does not generate checks for functions with period in the name
https://bugs.llvm.org/show_bug.cgi?id=37586
Bug ID: 37586
Summary: update_test_checks does not generate checks for
functions with period in the name
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: matthew.arsena...@amd.com
CC: llvm-bugs@lists.llvm.org
update_test_checks seems to ignore functions with periods in the name. Consider
this test:
; RUN: opt -S -instcombine %s | FileCheck %s
define void @foo.bar() {
ret void
}
define void @foo_bar() {
ret void
}
After running update_test_checks, the result is:
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt -S -instcombine %s | FileCheck %s
define void @foo.bar() {
ret void
}
define void @foo_bar() {
; CHECK-LABEL: @foo_bar(
; CHECK-NEXT:ret void
;
ret void
}
Note foo_bar has the expected check lines, but foo.bar does not
--
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 37587] New: No component for update_test_checks and other scripts
https://bugs.llvm.org/show_bug.cgi?id=37587 Bug ID: 37587 Summary: No component for update_test_checks and other scripts Product: Bugzilla Admin Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Products Assignee: unassignedb...@nondot.org Reporter: matthew.arsena...@amd.com CC: llvm-bugs@lists.llvm.org I couldn't find a relevant section to file bug 37586. I would expect there to be a product for it, (or maybe just for misc. scripts) under tools. Also applies to update_llc_test_checks, update_mir_test_checks etc. -- 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 37588] New: DSE slow with many allocas and calls
https://bugs.llvm.org/show_bug.cgi?id=37588 Bug ID: 37588 Summary: DSE slow with many allocas and calls Product: libraries Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org Original report for rustc at https://github.com/rust-lang/rust/issues/50994. DSE for an a function with many allocas and end BB with many calls is very slow, showing approximately quadratic scaling. Two test cases extracted from the above issue: https://gist.githubusercontent.com/nikic/46d6a41e968efabb45d76b3dc5e51589/raw/aadf233e6c145f5179751fa8ef9bfdf4fe466774/main1000.ll https://gist.githubusercontent.com/nikic/46d6a41e968efabb45d76b3dc5e51589/raw/aadf233e6c145f5179751fa8ef9bfdf4fe466774/main2000.ll Calling opt -S -dse main.ll takes 1.5s for 1000 rust println calls, 6.7s for 2000 calls and 33s for 4000 calls. The main issue is this loop: https://github.com/llvm-mirror/llvm/blob/10826be2a677d7babbc0c0640e94bf75fc808893/lib/Transforms/Scalar/DeadStoreElimination.cpp#L840-L845 It checks each potentially dead stack object (i.e. each alloca in this case) against each call being made in the end BB, which is quadratic. This is made worse by getModRefInfo() for an ImmutableCallSite being a quite expensive operation (due to reliance on PointerMayBeCaptured). -- 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 37286] [X86] Different scheduler information for vex/non-vex vector moves on Sandybridge
https://bugs.llvm.org/show_bug.cgi?id=37286 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||333271 Status|NEW |RESOLVED --- Comment #4 from Simon Pilgrim --- Thanks, fixed in rL333271 -- 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 32325] [META][X86] Improve implementation and use of X86 scheduler models
https://bugs.llvm.org/show_bug.cgi?id=32325 Bug 32325 depends on bug 37286, which changed state. Bug 37286 Summary: [X86] Different scheduler information for vex/non-vex vector moves on Sandybridge https://bugs.llvm.org/show_bug.cgi?id=37286 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] Issue 6697 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor
Updates: Labels: Deadline-Approaching Comment #3 on issue 6697 by sheriff...@chromium.org: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::StringMapImpl::LookupBucketFor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6697#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32860] Modifying data member when passing temporary to function accepting T const & not considered constexpr
https://bugs.llvm.org/show_bug.cgi?id=32860 David Stone changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #2 from David Stone --- This works as of clang 6.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] Issue 8541 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ExprEvaluatorBase::VisitCallExpr
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-05-25 Type: Bug New issue 8541 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in ExprEvaluatorBase::VisitCallExpr https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8541 Detailed report: https://oss-fuzz.com/testcase?key=5718091139907584 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcffa40580 Crash State: ExprEvaluatorBase::VisitCallExpr clang::StmtVisitorBasebool>::Visit ExprEvaluatorBase::VisitCastExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712090607:201712100011 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5718091139907584 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 36798] [PPC64] V2 ABI: relocation R_PPC64_ADDR16_DS out of range when linking against c-runtime
https://bugs.llvm.org/show_bug.cgi?id=36798 sfert...@ca.ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from sfert...@ca.ibm.com --- Fixed with Zaaras patch to emit the .toc sections directly after the .got section: https://reviews.llvm.org/rLLD333199 -- 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 35389] Support ppc64le
https://bugs.llvm.org/show_bug.cgi?id=35389 Bug 35389 depends on bug 36798, which changed state. Bug 36798 Summary: [PPC64] V2 ABI: relocation R_PPC64_ADDR16_DS out of range when linking against c-runtime https://bugs.llvm.org/show_bug.cgi?id=36798 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 37590] New: [PPC64] Support the 4 TLS models.
https://bugs.llvm.org/show_bug.cgi?id=37590 Bug ID: 37590 Summary: [PPC64] Support the 4 TLS models. Product: lld Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: sfert...@ca.ibm.com CC: llvm-bugs@lists.llvm.org There is no support for any of the 4 tls models in the PPC64 target yet. -- 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 37591] New: Dynamic linking: undefined references when linking libLTO.so
https://bugs.llvm.org/show_bug.cgi?id=37591 Bug ID: 37591 Summary: Dynamic linking: undefined references when linking libLTO.so Product: tools Version: 6.0 Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: lto Assignee: unassignedb...@nondot.org Reporter: phant...@gmail.com CC: llvm-bugs@lists.llvm.org I'm building on Solaris 10 / sparcv9, though I suspect this isn't solaris or sparc specific. I built with the following: cmake ../src/llvm \ -DCMAKE_C_COMPILER=gcc-7.2.0 \ -DCMAKE_CXX_COMPILER=g++-7.2.0 \ -DGCC_INSTALL_PREFIX=$(dirname $(dirname $(which gcc-7.2.0))) \ -DBUILD_SHARED_LIBS=ON \ -DLINK_LLVM_DYLIB=ON \ -DCMAKE_BUILD_TYPE=RelWithDebInfo make -j32 I'll explain why I built using those options in a separate comment. When linking libLTO.so it fails with undefined references to the following: LLVMDisasmDispose LLVMCreateDisasmCPU LLVMCreateDisasm LLVMDisasmInstruction LLVMSetDisasmOptions If I remove those entries from tools/lto/lto.exports then it links fine. -- 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 37592] New: LLD "foo.lib -wholearchive:foo.lib" doesn't work
https://bugs.llvm.org/show_bug.cgi?id=37592
Bug ID: 37592
Summary: LLD "foo.lib -wholearchive:foo.lib" doesn't work
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Consider:
$ cat a.c
int foo() { return 1; }
$ cat b.c
int bar() { return 2; }
$ cat t.c
int foo();
int main() {
return foo();
}
$ cl -c t.c a.c b.c && lld-link /LIB a.obj b.obj -out:foo.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.13.26131.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
t.c
a.c
b.c
Generating Code...
$ lld-link t.obj foo.lib -wholearchive:foo.lib -out:t.exe -verbose
-nodefaultlib -entry:main
C:\src\llvm-project\build\bin\lld-link.exe: Reading t.obj
C:\src\llvm-project\build\bin\lld-link.exe: Directives: t.obj:
/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES"
C:\src\llvm-project\build\bin\lld-link.exe: Reading foo.lib
C:\src\llvm-project\build\bin\lld-link.exe: Reading foo.lib(a.obj)
C:\src\llvm-project\build\bin\lld-link.exe: Directives: foo.lib(a.obj):
/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES"
C:\src\llvm-project\build\bin\lld-link.exe: Loaded foo.lib(a.obj) for foo
C:\src\llvm-project\build\bin\lld-link.exe: ICF needed 2 iterations
As you can see from the verbose output, b.obj is not loaded, but it is if I
swap in link.exe:
$ link t.obj foo.lib -wholearchive:foo.lib -out:t.exe -verbose -nodefaultlib
-entry:main
Microsoft (R) Incremental Linker Version 14.13.26131.1
Copyright (C) Microsoft Corporation. All rights reserved.
Processed /NODEFAULTLIB (suppressing all default libs)
Starting pass 1
Loaded foo.lib(a.obj)
Loaded foo.lib(b.obj)
Searching libraries
Searching foo.lib:
Finished searching libraries
Finished pass 1
Starting pass 2
t.obj
foo.lib(b.obj)
foo.lib(a.obj)
Finished pass 2
This is causing Chromium's base_unittests tests to fail with asan, which uses
wholearchive.
--
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 37593] New: clang: diagnostics about constexpr misuse are nonexistant
https://bugs.llvm.org/show_bug.cgi?id=37593
Bug ID: 37593
Summary: clang: diagnostics about constexpr misuse are
nonexistant
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
https://godbolt.org/g/8jgtJU
struct A {
struct B;
static const B c;
template
static void theWork();
};
struct A::B {
int e;
explicit constexpr B(int e_) : e(e_) {}
};
constexpr auto A::c = A::B(0);
template
void A::theWork() {
static_assert(d.e == 0, "can't stop the work!");
}
int main(int argc, char* argv[]) {
A::theWork();
return 0;
}
clang happily accepts that code.
gcc chokes on it:
:14:19: error: conflicting declaration 'constexpr const auto A::c'
constexpr auto A::c = A::B(0);
^
:3:20: note: previous declaration as 'const A::B A::c'
static const B c;
^
: In instantiation of 'static void A::theWork() [with const A::B& d =
A::c]':
:22:22: required from here
:18:23: error: non-constant condition for static assertion
static_assert(d.e == 0, "can't stop the work!");
^~~~
:18:23: error: the value of 'A::c' is not usable in a constant
expression
:3:20: note: 'A::c' was not declared 'constexpr'
static const B c;
^
Compiler returned: 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 37594] New: Crash during global initialization
https://bugs.llvm.org/show_bug.cgi?id=37594 Bug ID: 37594 Summary: Crash during global initialization Product: new-bugs Version: 6.0 Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: phant...@gmail.com CC: llvm-bugs@lists.llvm.org I'm building on Solaris 10 / sparcv9 hardware. I built with the following: cmake ../src/llvm \ -DCMAKE_C_COMPILER=gcc-4.9.2 \ -DCMAKE_CXX_COMPILER=g++-4.9.2 \ -DGCC_INSTALL_PREFIX=$(dirname $(dirname $(which gcc-4.9.2))) \ -DCMAKE_BUILD_TYPE=RelWithDebInfo make -j32 I also tried building with gcc 7.2.0. In both cases when clang-tblgen and llvm-tblgen execute they crash while executing constructors for what I assume is code related to parsing command-line arguments. The machine I'm building on isn't connected to a network and I don't have the means to copy build logs off to attach, so I've hand-typed some info I hope will be useful (attachment forthcoming). -- 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 37593] clang: diagnostics about constexpr misuse are nonexistant
https://bugs.llvm.org/show_bug.cgi?id=37593 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- GCC bug. The code is valid. Apparently GCC is confused by the 'auto', and rejects the mismatch of types 'const A::B' vs 'const auto', rather than checking the types match after deduction. MSVC appears to have the same bug as GCC. ICC also appears to have the same bug. It also has a bug where it doesn't allow 'constexpr' to be added in the definition. Simpler testcase: extern int a; auto a = 0; This is incorrectly rejected by MSVC and GCC. But ICC accepts this one. *shrug* -- 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 37223] Patch required to support ppc64le calling convention etc.
https://bugs.llvm.org/show_bug.cgi?id=37223 Bob Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Bob Wilson --- Patch committed in Clang r16 -- 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 37595] New: -fvisibility-inlines-hidden marks static local variables as hidden when it shouldn't
https://bugs.llvm.org/show_bug.cgi?id=37595
Bug ID: 37595
Summary: -fvisibility-inlines-hidden marks static local
variables as hidden when it shouldn't
Product: clang
Version: 3.2
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: redbeard0...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
At the very least this is a scary undocumented difference from that flag's
meaning under gcc. Quoting the gcc man page for that flag (emphasis mine): The
behavior of this switch is not quite the same as marking the methods as hidden
directly, because ***it does not affect static variables local to the
function*** or cause the compiler to deduce that the function is defined in
only one shared object.
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fvisibility-inlines-hidden
only says "Give inline C++ member functions default visibility by default"
which doesn't seem to accurately describe the behavior.
Here is a simple example that shows the issue: https://godbolt.org/g/63FiwD
inline int* test() {
static int staticVar;
return &staticVar;
}
auto force = test();
The problematic line is in the generated ASM is ".hidden test()::staticVar".
That is only generated with clang with -fvisibility-inlines-hidden. gcc does
not add that line to the output. I walked back the versions on godbolt and it
looks like this was introduced between 3.1 and 3.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 37596] New: xlocale.h not found
https://bugs.llvm.org/show_bug.cgi?id=37596 Bug ID: 37596 Summary: xlocale.h not found Product: libc++ Version: 6.0 Hardware: Sun OS: Solaris Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: phant...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Building on Solaris 10 / sparcv9 hardware: cmake ../src/llvm \ -DCMAKE_C_COMPILER=gcc-7.2.0 \ -DCMAKE_CXX_COMPILER=g++-7.2.0 \ -DGCC_INSTALL_PREFIX=$(dirname $(dirname $(which gcc-7.2.0))) \ -DCMAKE_BUILD_TYPE=RelWithDebInfo make -j32 ... with libcxx/libcxxabi un-tarred & appropriately renamed in ../src/llvm/projects. I get the following compile error: In file included from (...)/projects/libcxx/include/ios:216:0, from (...)/projects/libcxx/include/ostream:138, from (...)/projects/libcxx/include/istream:163, from (...)/projects/libcxx/include/rnadom:1646, from (...)/projects/libcxx/src/algorithm.cpp:11: (...)/projects/libcxx/include/__locale:33:11: fatal error: xlocale.h: No such file or directory -- 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 37597] New: math.h conflicting noexcept declaration
https://bugs.llvm.org/show_bug.cgi?id=37597
Bug ID: 37597
Summary: math.h conflicting noexcept declaration
Product: libc++
Version: 6.0
Hardware: Sun
OS: Solaris
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: phant...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Building on Solaris 10 / sparcv9 hardware:
cmake ../src/llvm \
-DCMAKE_C_COMPILER=gcc-7.2.0 \
-DCMAKE_CXX_COMPILER=g++-7.2.0 \
-DGCC_INSTALL_PREFIX=$(dirname $(dirname $(which gcc-7.2.0))) \
-DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j32
I get the following compile error:
In file included from (...)/projects/libcxx/src/debug.cpp:10:0:
(...)/projects/libcxx/include/math.h: In function 'float acosh(float)':
(...)/projects/libcxx/include/__config:776:21: error: 'float acosh(float)'
conflicts with a previous declaration
# define _NOEXCEPT noexcept
^
(...)/projects/libcxx/include/math.h:1038:68: note: in expansion of macro
'_NOEXCEPT'
inline _LIBCPP_INLINE_VISIBILITY float acosh(float __lcpp_x)
_NOEXCEPT {return ::acoshf(__lcpp_x);}
^
... for 34 functions declared in math.h:
acosh, asinh, atanh, cbrt, copysign, erf, erfc, exp2, expm1, fdim, fma, fmax,
fmin, hypot, ilogb, lgamma, llrint, llround, log1p, log2, logb, lrint, lround,
nearbyint, nextafter, nexttoward, remainder, remquo, rint, round, scalbln,
scalbn, tgamma, trunc
--
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 37598] New: clang emitting RIP-relative relocation for weak external on Windows x86-64
https://bugs.llvm.org/show_bug.cgi?id=37598
Bug ID: 37598
Summary: clang emitting RIP-relative relocation for weak
external on Windows x86-64
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: smee...@fb.com
CC: compn...@compnerd.org, llvm-bugs@lists.llvm.org,
r...@google.com
% cat reduced.ll
@Weak = extern_weak global i32
define i32* @getWeak() {
ret i32* @Weak
}
% clang -target x86_64-windows-msvc -S -o - reduced.ll
.text
.def getWeak;
.scl2;
.type 32;
.endef
.globl getWeak # -- Begin function getWeak
.p2align4, 0x90
getWeak:# @getWeak
# %bb.0:
leaqWeak(%rip), %rax
retq
# -- End function
.weak Weak
The issue is that LLVM implements weak symbols for COFF through the weak
external mechanism, and it emits an absolute symbol with the value of 0 to
serve as the fallback symbol. We'll therefore end up with a RIP-relative
relocation against an absolute symbol in the case where Weak isn't defined.
link errors out for this:
error LNK2016: absolute symbol 'Weak' used as target of REL32 relocation in
section 1
LLD accepts it silently; I'll file a separate bug for that.
--
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 37599] New: lld-link silently accepts AMD64_REL32 against absolute symbol
https://bugs.llvm.org/show_bug.cgi?id=37599 Bug ID: 37599 Summary: lld-link silently accepts AMD64_REL32 against absolute symbol Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: smee...@fb.com CC: compn...@compnerd.org, llvm-bugs@lists.llvm.org, r...@google.com, r...@google.com % cat reduced.s .weak weak .globl main main: leaqweak(%rip), %rax retq % llvm-mc -triple x86_64-windows-msvc -filetype=obj -o reduced.o reduced.s % lld-link -entry:main reduced.o Weak symbols are implemented for COFF on LLVM by using COFF weak externals and creating an absolute symbol with the value 0 as the fallback symbol. Since we don't define weak in this case, we'll end up falling back to the absolute symbol. lld will then silently accept the AMD64_ADDR32 relocation against the absolute symbol, which will produce the wrong result at runtime, whereas link produces an error: error LNK2016: absolute symbol 'foo' used as target of REL32 relocation in section 1 (I used the weak external mechanism to demonstrate the issue because if I just create an absolute symbol directly and try to create RIP-relative relocation against that, clang won't actually emit the relocation in the object file.) -- 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 37406] Merge r330264 and other related fixes for PR37100 into the 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=37406 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 36649] [meta] 6.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=36649 Bug 36649 depends on bug 37406, which changed state. Bug 37406 Summary: Merge r330264 and other related fixes for PR37100 into the 6.0 branch https://bugs.llvm.org/show_bug.cgi?id=37406 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
