[llvm-bugs] [Bug 31405] New: Itanium ABI: debug assertion in template mangling with declype return
https://llvm.org/bugs/show_bug.cgi?id=31405 Bug ID: 31405 Summary: Itanium ABI: debug assertion in template mangling with declype return Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangb...@nondot.org Reporter: spr...@yandex-team.ru CC: llvm-bugs@lists.llvm.org Classification: Unclassified I develop in-house source code indexer and met the following issue. The simple declaration cannot be mangled - Itanium mangler fails with assert if clang is built in debug mode: >> cat test.cpp template auto foo(T x) -> const decltype(x); >> indexer -std=c++14 test.cpp indexer: /home/spreis/LLVM/llvm/tools/clang/lib/AST/ItaniumMangle.cpp:3976: void (anonymous namespace)::CXXNameMangler::mangleFunctionParam(const clang::ParmVarDecl *): Assertion `parmDepth < FunctionTypeDepth.getDepth()' failed. Aborted (core dumped) The problem is that both parts of comparison are '0'. This is due to the fact that in this case CXXNameMangler::mangleFunctionParam() is called transitively from CXXNameMangler::makeFunctionReturnTypeTags() (see stack trace below) and for TrackReturnTypeTags mangler the FunctionTypeDepth is never increased in this case. I believe this is incorrect: makeFunctionReturnTypeTags is called in context of return value, so its FunctionTypeDepth should be 1 at minimum (though I am not 100% sure: I am still new to clang). The patch below fixes the issue for me: ~/LLVM/llvm/tools/clang/lib/AST$ svn diff Index: ItaniumMangle.cpp === --- ItaniumMangle.cpp (revision 289930) +++ ItaniumMangle.cpp (working copy) @@ -4418,9 +4418,12 @@ const FunctionProtoType *Proto = cast(FD->getType()->getAs()); + FunctionTypeDepthState saved = TrackReturnTypeTags.FunctionTypeDepth.push(); TrackReturnTypeTags.FunctionTypeDepth.enterResultType(); TrackReturnTypeTags.mangleType(Proto->getReturnType()); TrackReturnTypeTags.FunctionTypeDepth.leaveResultType(); + TrackReturnTypeTags.FunctionTypeDepth.pop(saved); return TrackReturnTypeTags.AbiTagsRoot.getSortedUniqueUsedAbiTags(); } Unfortunately I cannot provide full reproducer. I may try to create skeleton visitor as reduced test case at later days. But maybe some C++ mangler capable of handling this case already exists (c-index-test tool's mangling doesn't work for function templates) - it should crash on debug CLANG with the declaration above. The stack trace: --- >> gdb --args indexer -std=c++14 test.cpp [...] (gdb) run indexer: /home/spreis/LLVM/llvm/tools/clang/lib/AST/ItaniumMangle.cpp:3976: void (anonymous namespace)::CXXNameMangler::mangleFunctionParam(const clang::ParmVarDecl *): Assertion `parmDepth < FunctionTypeDepth.getDepth()' failed. (gdb) bt Program received signal SIGABRT, Aborted. 0x769b8c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x769b8c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x769bc028 in __GI_abort () at abort.c:89 #2 0x769b1bf6 in __assert_fail_base () at assert.c:92 #3 0x769b1ca2 in __GI___assert_fail () at assert.c:101 #4 0x00e3600d in (anonymous namespace)::CXXNameMangler::mangleFunctionParam () at /home/spreis/LLVM/llvm/tools/clang/lib/AST/ItaniumMangle.cpp:3976 #5 0x00e2c9a2 in mangleType () at /home/spreis/LLVM/llvm/tools/clang/lib/AST/ItaniumMangle.cpp:3028 #6 (anonymous namespace)::CXXNameMangler::mangleType () at /home/spreis/LLVM/llvm/tools/clang/include/clang/AST/TypeNodes.def:88 #7 0x00e2bf95 in (anonymous namespace)::CXXNameMangler::mangleType () at /home/spreis/LLVM/llvm/tools/clang/lib/AST/ItaniumMangle.cpp:2252 #8 0x00e2aa0f in makeFunctionReturnTypeTags () <) at /home/spreis/LLVM/build/include/clang/AST/RecursiveASTVisitor.h:1883 #16 clang::RecursiveASTVisitor::TraverseDecl () at /place/home/spreis/LLVM/build/include/clang/AST/DeclNodes.inc:371 #17 0x005736e2 in BrowserASTVisitor::TraverseDecl () at at /home/spreis/work/indexer/browserastvisitor.h:324 #18 0x00574d5b in clang::RecursiveASTVisitor::TraverseFunctionTemplateDecl () at /home/spreis/LLVM/build/include/clang/AST/RecursiveASTVisitor.h:1637 -- 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 31406] New: CRTP with inhered template member function is not included in overload resolution
https://llvm.org/bugs/show_bug.cgi?id=31406
Bug ID: 31406
Summary: CRTP with inhered template member function is not
included in overload resolution
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: pedro.ferre...@imgtec.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following C++ source file compiles fine:
===
#include
#include
template
class EnumAlias
{
public:
template::value>::type*
= nullptr>
void operator()(E& e)
{
Base& base = *static_cast(this);
A& a = (A&)(e);
base(a);
}
};
class Base;
typedef EnumAlias EnumAliasU32;
class Base : public EnumAliasU32
{
public:
using EnumAliasU32::operator();
template::value>::type* = nullptr>
void operator()(const T& e)
{
//something, whatever
}
};
enum SomeEnumTy {};
void Use()
{
SomeEnumTy e;
Base b;
b(e);
}
However, if one is to remove "const" from Base::operator(), clang fails with
===
CRTP.cpp:39:2: error: no matching function for call to object of type 'Base'
b(e);
^
CRTP.cpp:25:47: note: candidate template ignored: disabled by 'enable_if' [with
T = SomeEnumTy]
template::value>::type* = nullptr>
^
1 error generated.
===
G++ accepts the code. Is the input source incorrect?
It seems on the second, the inherited function does not participate in overload
resolution (even though it does when "const" is specified).
--
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 31407] New: Likely regression r289925: Various chromium tools have trouble symbolizing
https://llvm.org/bugs/show_bug.cgi?id=31407 Bug ID: 31407 Summary: Likely regression r289925: Various chromium tools have trouble symbolizing Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Some of our tools have trouble symbolizing now (https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/357983); likely r289925. I'll try reverting, and I'll try to get you a repro. Normally I'd get a repro first, but the llvm trunk state has been extremely unstable this week and I'd like to make sure it's stabilized now. It's possible we can just reland your patch without changes. -- 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 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://llvm.org/bugs/show_bug.cgi?id=26299 Bug 26299 depends on bug 27885, which changed state. Bug 27885 Summary: shuffle lowering does never use shufps for int vectors https://llvm.org/bugs/show_bug.cgi?id=27885 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 27885] shuffle lowering does never use shufps for int vectors
https://llvm.org/bugs/show_bug.cgi?id=27885 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Simon Pilgrim --- Fixed the v16i32 support in rL289946 and converted over to using lowerVectorShuffleWithSHUFPS in rL289950 -- 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 31408] New: /dev/null is not accepted as output
https://llvm.org/bugs/show_bug.cgi?id=31408
Bug ID: 31408
Summary: /dev/null is not accepted as output
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: d...@golovin.in
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When detecting compiler features it is common to use '-o /dev/null' option. It
fails with LLD.
Typical test would look like this:
$ echo 'typedef int x;' | clang -x c - -nostdlib -shared -o /dev/null
ld.lld: error: rename failed: Permission denied
So LLD is trying to rename /dev/null. What it is actually trying to do is the
following:
access("/dev/nulltmp4e940395", F_OK)= -1 ENOENT (No such file or
directory)
rename("/dev/null", "/dev/nulltmp4e940395") = -1 EACCES (Permission denied)
I don't know what is the right behavior to implement if /dev/null is an output,
but I think that is not it.
This should also affect NUL on Windows.
--
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 31013] [IR] DIGlobalVariable should not hold a DIExpression
https://llvm.org/bugs/show_bug.cgi?id=31013 Adrian Prantl changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Adrian Prantl --- This landed in r289920. -- 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 31404] Regression(289703): Assertion failed: (memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!") when building chrome/ios.
https://llvm.org/bugs/show_bug.cgi?id=31404 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Eli Friedman --- r289972. (I'm glad the assertion caught this; it would have been a painful miscompile to track down.) -- 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 31409] New: Fail to link instantiation of basic_regex with a custom character type
https://llvm.org/bugs/show_bug.cgi?id=31409 Bug ID: 31409 Summary: Fail to link instantiation of basic_regex with a custom character type Product: libc++ Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: ka...@codesynthesis.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified Trying to instantiate std::basic_regex template with a custom character type results in a linker error like this: driver.o:(.rodata._ZTVNSt3__123__match_any_but_newlineIN6build24test6script5regex9line_charEEE[_ZTVNSt3__123__match_any_but_newlineIN6build24test6script5regex9line_charEEE]+0x20): undefined reference to `std::__1::__match_any_but_newline::__exec(std::__1::__state&) const' That happens as libc++ only provides specialization of __match_any_but_newline::__exec() for char and wchar_t types, and lacks implementation which would be available for any other instantiation of the __match_any_but_newline template. Probably it would be right to assume that a custom character type can have no notion of a newline character at all. As a real life example, in build2 toolchain we develop, such a character represents a line of a program output, or an inner level regex matching such a line, or a syntax regex character. -- 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 31410] New: No strict aliasing for uint8_t
https://llvm.org/bugs/show_bug.cgi?id=31410
Bug ID: 31410
Summary: No strict aliasing for uint8_t
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: rsilv...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Currently uint8_t is treated identically to an unsigned char for purposes
of strict aliasing. This is unnecessary and results in missed optimization,
since unsigned chars must alias all other types (but uint8_ts are not required
to).
There is a related discussion at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
Here is a trivial demonstration:
#include
int strict(uint32_t *p, uint8_t *q) {
*p = 1;
*q = 0;
return *p;
}
With clang -O on x86-64, we get:
mov dword ptr [rdi], 1
mov byte ptr [rsi], 0
mov eax, dword ptr [rdi]
ret
Replacing uint8_t with uint16_t (note the load immediate into eax):
mov dword ptr [rdi], 1
mov word ptr [rsi], 0
mov eax, 1
ret
--
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 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://llvm.org/bugs/show_bug.cgi?id=26299 Bug 26299 depends on bug 31367, which changed state. Bug 31367 Summary: X86: Generate smaller code for atomic refcount decrement https://llvm.org/bugs/show_bug.cgi?id=31367 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 31367] X86: Generate smaller code for atomic refcount decrement
https://llvm.org/bugs/show_bug.cgi?id=31367 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Hans Wennborg --- r289955 -- 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 31411] New: [regalloc] A problem caused by the interaction between split and evict
https://llvm.org/bugs/show_bug.cgi?id=31411 Bug ID: 31411 Summary: [regalloc] A problem caused by the interaction between split and evict Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: w...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified For the testcase 1.cc: ~/workarea/llvm-r287002/dbuild/bin/clang -std=c++11 -fno-omit-frame-pointer -fno-exceptions -O2 -S 1.cc -o 1.s In BB#41 we found some fishy code. The movq instructions pairs below indicates some problem in reg split. # BB#41:# %if.then.i201 # in Loop: Header=BB0_35 Depth=2 xorl%eax, %eax cmpl%r10d, %r12d setl%al movq-56(%rbp), %rcx # 8-byte Reload ===> movq%r13, %rdi movq%r15, %r13 movq%r10, %r15 movq%r8, %r10 ===> movq%rcx, %r8 addq%rax, %r8 movq-136(%rbp), %rax# 8-byte Reload movslq 56(%rax), %rax shlq$3, %rax negq%rax movq(%rdi,%rax), %rax movq%r8, %rcx movq%rcx, -56(%rbp) # 8-byte Spill addq%r8, %rax ===> movq%r10, %r8 movq%r15, %r10 movq%r13, %r15 movq%rdi, %r13 ===> movq%rax, (%r13) We do some digging here and find the problem is about the interaction of split and evict: Suppose physical register %R1 is used in BB#41 but available elsewhere. virtual registers: VR1,VR2,VR3,VR4 lives through BB#41. Register pressure is high in the function so VR1 is split into VR1_a and VR1_b with %R1 available for VR1_a. VR10 holds %R2. BB#41 VR1_b = VR1_a; ... def R1; ... use R1; ... VR1_a = VR1_b; VR1_b is the remainder interval the stage of which is marked as SPILL after the split, and it is local to BB#41. Because VR1_a is longer than VR1_b, VR1_a will be allocated before VR1_b in the queue after split. VR1_a will easily get %R1. VR1_b is marked as SPILL but it is shorter than VR1, so it can now evict VR10 for %R2, and VR1_b will get %R2. Note VR1_a and VR1_b get different physical registers so the copies pair "VR1_b = VR1_a" and "VR1_a = VR1_b" cannot be coalesced. Since %R2 is only used in BB#41 but available elsewhere, it looks the same as %R1 above. Then VR2 will be split in the same way as VR1 and generate another pair of copies. So on for VR3, VR4... I think a cause of the problem is: VR1 cannot evict VR10 for %R2 before it is split, but after split, VR1_b can evict VR10 because it is shorter now and has higher weight than VR1. Since VR10 will be evicted anyway by VR1_b, why not do that before split, so that VR1 can be allocated to %R2 without splitting, and no copies will be inserted into BB#41. However, it is not cheap to know that one of new vregs generated from splitting VR1 can evict VR10 beforehand. We can have an alternative solution here. Raising the priority of remainder interval (VR1_b) after split so that VR1_b will be allocated before VR1_a. VR1_b will still evict VR10 and get %R2. When allocating VR1_a, it can choose between %R2 and %R1 and will more likely to choose %R2 because of hint, and the copies will be coalesced. -- 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 31412] New: SCEV unable to infer loop max bound for remainder loops
https://llvm.org/bugs/show_bug.cgi?id=31412
Bug ID: 31412
Summary: SCEV unable to infer loop max bound for remainder
loops
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: mku...@google.com
CC: llvm-bugs@lists.llvm.org,
san...@playingwithpointers.com
Classification: Unclassified
Consider:
void foo0(int* in, int* out, unsigned k) {
k %= 4;
for (int i = 0; i < k; ++i) {
in[i] += out[i];
}
}
$ bin/clang -m32 -c -S -o - -O2 ~/llvm/temp/smallmax.cpp -emit-llvm | bin/opt
-analyze -scalar-evolution
[...]
Loop %for.body: backedge-taken count is (-1 + (zext i2 (trunc i32 %k to i2) to
i32))
Loop %for.body: max backedge-taken count is -1
After talking to Sanjoy, it seems that the main issue is that
max-backedge-taken computation does not take the fact that "if the backedge is
taken, necessarily k > 0" into account.
Indeed:
void foo2(int* in, int* out, unsigned k) {
k %= 4;
k += 2;
for (int i = 0; i < k; ++i) {
in[i] += out[i];
}
}
$ bin/clang -m32 -c -S -o - -O2 ~/llvm/temp/smallmax.cpp -emit-llvm | bin/opt
-analyze -scalar-evolution
[...]
Loop %for.body: backedge-taken count is (1 + (zext i2 (trunc i32 %k to i2) to
i32))
Loop %for.body: max backedge-taken count is 4
But I think this is not the only problem.
If it were, adding 1 to k should have been sufficient, but:
void foo1(int* in, int* out, unsigned k) {
k %= 4;
k += 1;
for (int i = 0; i < k; ++i) {
in[i] += out[i];
}
}
$ bin/clang -m32 -c -S -o - -O2 ~/llvm/temp/smallmax.cpp -emit-llvm | bin/opt
-analyze -scalar-evolution
[...]
Loop %for.body: backedge-taken count is (zext i2 (trunc i32 %k to i2) to i32)
Loop %for.body: max backedge-taken count is -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 31413] New: libcompiler_rt.so and libcompiler_rt.a are not being built
https://llvm.org/bugs/show_bug.cgi?id=31413 Bug ID: 31413 Summary: libcompiler_rt.so and libcompiler_rt.a are not being built Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: d...@golovin.in CC: llvm-bugs@lists.llvm.org Classification: Unclassified I'm trying to build compiler-rt in tree, latest svn version. I configure it with cmake and build with ninja. It configures fine, but targets for libcompiler_rt.so and libcompiler_rt.a are never generated and I think they should be. You can find my build.ninja attached. -- 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 28331] Static analyzer false positive of Unix API violation: Improper use of 'open', when 'open' is in an alternative namespace
https://llvm.org/bugs/show_bug.cgi?id=28331 Devin Coughlin changed: What|Removed |Added Status|NEW |RESOLVED CC||dcough...@apple.com Resolution|--- |FIXED --- Comment #2 from Devin Coughlin --- This should be fixed in r290023. -- 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 31335] We fail to detect that '.' moved backwards
https://llvm.org/bugs/show_bug.cgi?id=31335 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from George Rimar --- r289782 -- 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 31354] [ELF] - duplicate symbol error when linking some FreeBSD ports.
https://llvm.org/bugs/show_bug.cgi?id=31354 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from George Rimar --- Not an issue of LLD, but issue of port(s). -- 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
