[llvm-bugs] [Bug 33833] New: SelectionDAG crashes on optnone function after r308025
https://bugs.llvm.org/show_bug.cgi?id=33833 Bug ID: 33833 Summary: SelectionDAG crashes on optnone function after r308025 Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: chandl...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18814 --> https://bugs.llvm.org/attachment.cgi?id=18814&action=edit reduced IR test case After r308025, SelectionDAG crashes while compiling the file: https://github.com/xiph/speex/blob/master/libspeex/testenc.c (Possibly some older version of it, I haven't checked...) I'm attaching a minimized test case that pretty clearly shows the bug. It seems specific to O0 (optnone attribute is applied). Because this is blocking even unoptimized builds I'm going to revert the patch while it gets investigated. -- 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 33817] Fails to build on gcc 5.4.0 and libstdc++ 6 because bind is missing in TaskPool.h
https://bugs.llvm.org/show_bug.cgi?id=33817 lab...@google.com changed: What|Removed |Added CC||lab...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from lab...@google.com --- It looks like this has already been fixed with r299676. -- 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 32282] Assertion `loBit <= BitWidth && "loBit out of range"' failed with -O0 -march=skx.
https://bugs.llvm.org/show_bug.cgi?id=32282 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Simon Pilgrim --- Added a test case at rL308286 but this is unlikely to come back again without us trying to store/load from i1 types -- 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 33798] POLLY_BUNDLED_JSONCPP=OFF is failing on Ubuntu Trusty
https://bugs.llvm.org/show_bug.cgi?id=33798 Michael Kruse 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 33834] New: [ms_abi] Big structures arguments are not passed correctly (x64)
https://bugs.llvm.org/show_bug.cgi?id=33834
Bug ID: 33834
Summary: [ms_abi] Big structures arguments are not passed
correctly (x64)
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: pi...@codeweavers.com
CC: llvm-bugs@lists.llvm.org
An example of function that will be called incorrectly:
typedef struct {
int big[8];
} big;
extern void __attribute__((ms_abi)) call_func_with_struct_args(big a, big b,
big c, big d, big e);
...
big args[5];
memset(args, 0, sizeof(args));
call_func_with_struct_args(args[0], args[1], args[2], args[3], args[4]);
MSVC passes all structures indirectly (even for arguments passed on stack).
Clang passes first four arguments as pointers. Fifth argument is passed
incorrectly (this breaks some functionality in wine project).
--
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 33828] Crash in X86DAGToDAGISel::RunSDNodeXForm: "getConstant with a uint64_t value that doesn't fit in the type!"
https://bugs.llvm.org/show_bug.cgi?id=33828 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Component|Backend: X86|Common Code Generator Code Status|NEW |RESOLVED --- Comment #3 from Simon Pilgrim --- rL308302 -- 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 33835] New: [clang-format] function arguments
https://bugs.llvm.org/show_bug.cgi?id=33835
Bug ID: 33835
Summary: [clang-format] function arguments
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: tob...@grosser.es
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
clang-format is breaking lines without need:
Using the option AlignAfterOpenBracket: DontAlign, I configured clang-format to
start the list of new parameters (almost) at the beginning of a new line:
It seems that without need, clang-format moves the first parameter on the
second line, while it perfectly would fit into the first line:
# Original (in our isl math library)
__isl_give isl_ast_expr *isl_ast_expr_get_op_arg(__isl_keep isl_ast_expr *expr,
int pos)
{
return 0;
}
# clang-format
__isl_give isl_ast_expr *isl_ast_expr_get_op_arg(
__isl_keep isl_ast_expr *expr, int pos)
{
return 0;
}
I would prefer the first version. Is there a way to teach clang-format to
prefer the first 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 33770] Inline Assembler Comments
https://bugs.llvm.org/show_bug.cgi?id=33770 James Y Knight changed: What|Removed |Added CC||jykni...@google.com Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from James Y Knight --- Clang does emit the comment, just on the next line: #APP xchgq %rsi, (%rdi) # atomic_swap_long #NO_APP Which seems to be the expected behavior for inline asm with semicolons. -- 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 33833] SelectionDAG crashes on optnone function after r308025
https://bugs.llvm.org/show_bug.cgi?id=33833 Nirav Dave changed: What|Removed |Added CC||nir...@google.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Nirav Dave --- *** This bug has been marked as a duplicate of bug 32515 *** -- 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 33837] New: SCEV AA assumes inbounds and non-negative offsets
https://bugs.llvm.org/show_bug.cgi?id=33837 Bug ID: 33837 Summary: SCEV AA assumes inbounds and non-negative offsets Product: libraries Version: trunk Hardware: All OS: All Status: NEW Keywords: miscompilation Severity: normal Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: nunoplo...@sapo.pt CC: dan433...@gmail.com, dav...@freebsd.org, dber...@dberlin.org, gil@sf.snu.ac.kr, hfin...@anl.gov, jeehoon.k...@sf.snu.ac.kr, juneyoung@sf.snu.ac.kr, llvm-bugs@lists.llvm.org, reg...@cs.utah.edu, san...@playingwithpointers.com The last rule of SCEV AA to prove no-alias is the following: if a = x + ... and no-alias(x, -1, b, s_b) then no-alias(a, s_a, b, s_b) where s_a = access size for a The code is the following: if ((AO && AO != LocA.Ptr) || (BO && BO != LocB.Ptr)) if (alias(MemoryLocation(AO ? AO : LocA.Ptr, AO ? +MemoryLocation::UnknownSize : LocA.Size, AO ? AAMDNodes() : LocA.AATags), MemoryLocation(BO ? BO : LocB.Ptr, BO ? +MemoryLocation::UnknownSize : LocB.Size, BO ? AAMDNodes() : LocB.AATags)) == NoAlias) return NoAlias; This is incorrect for the following case: 1) AO == null || BO == null (so, we only get an addition for one of the pointers) 2) the GEP has no inbounds attribute *OR* the offset (the ... in "a = x + ...") is negative. I don't have a reproducible test case, but I proved in Z3 that if one of the above conditions doesn't hold then the code is correct. And if both hold, then SCEV AA will prove no-alias incorrectly. So the fix is (for the case AO == null || BO == null): - check that the GEP originating the SCEV add expression has inbounds attribute - *and* check that the offset is non-negative -- 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 33818] segfault in opt
https://bugs.llvm.org/show_bug.cgi?id=33818 Davide Italiano changed: What|Removed |Added Status|RESOLVED|REOPENED 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 33838] New: Incorrect operand sizes for MMX instructions
https://bugs.llvm.org/show_bug.cgi?id=33838 Bug ID: 33838 Summary: Incorrect operand sizes for MMX instructions Product: tools Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llvm-as Assignee: unassignedb...@nondot.org Reporter: pe...@trailofbits.com CC: llvm-bugs@lists.llvm.org The x86 MMX variants of punpcklbw, punpcklwd, punpckldq that operate on memory operate on dwords, but the LLVM assembler only accepts qword ptr arguments. For example, LLVM rejects the following: punpcklwd mm0, dword ptr [rsp] and incorrectly accepts the following: punpcklwd mm0, qword ptr [rsp] -- 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 32515] Assertion "DELETED_NODE in CSEMap!" fires a lot with -march=skx
https://bugs.llvm.org/show_bug.cgi?id=32515 Nirav Dave changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Nirav Dave --- Fix landed at r308330. -- 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 33840] New: std::string::push_back is 3.4x slower than on libstdc++
https://bugs.llvm.org/show_bug.cgi?id=33840
Bug ID: 33840
Summary: std::string::push_back is 3.4x slower than on
libstdc++
Product: libc++
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: thomasander...@google.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Simple program that demonstrates the issue:
test.cpp
#include
int main(void) {
std::string s;
for(volatile int i = 0; i < 5; i++) {
s.push_back('a');
}
return 0;
}
test.cpp
$ clang++ main.cpp -stdlib=libstdc++ && time ./a.out
real0m2.451s
$ clang++ main.cpp -stdlib=libc++ && time ./a.out
real0m8.535s
I've verified that it is always a constant factor of 3.4x slower than libstdc++
regardless of the input size.
--
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 33841] New: [X86] Favor shlx/shrx over shl/srl x, cl for (shift x (and y, (BitWidth-1)))
https://bugs.llvm.org/show_bug.cgi?id=33841 Bug ID: 33841 Summary: [X86] Favor shlx/shrx over shl/srl x, cl for (shift x (and y, (BitWidth-1))) Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org It looks like we're missing patterns to favor shlx/shrx when the shift amount is being masked with an and. We should add shlx/shrx to this section of X86InstrCompiler.td defm : MaskedShiftAmountPats; defm : MaskedShiftAmountPats; defm : MaskedShiftAmountPats; defm : MaskedShiftAmountPats; defm : MaskedShiftAmountPats; -- 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 33821] After r307100, segfaults when linking FreeBSD aarch64 kernel
https://bugs.llvm.org/show_bug.cgi?id=33821 Rafael Ávila de Espíndola changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Rafael Ávila de Espíndola --- Fixed in r308382. -- 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 23214] [META] Using LLD as FreeBSD's system linker
https://bugs.llvm.org/show_bug.cgi?id=23214 Bug 23214 depends on bug 33821, which changed state. Bug 33821 Summary: After r307100, segfaults when linking FreeBSD aarch64 kernel https://bugs.llvm.org/show_bug.cgi?id=33821 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 32282] Assertion `loBit <= BitWidth && "loBit out of range"' failed with -O0 -march=skx.
https://bugs.llvm.org/show_bug.cgi?id=32282
Davide Italiano changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #8 from Davide Italiano ---
(In reply to Dmitry Babokin from comment #7)
> clang rev308350, the fail is still there.
>
> > cat f.cpp
> int a;
> long b;
> struct {
> char c : 29;
> } d;
> void e() {
> d.c = ~0 + 483647 & (a < 0) + 2147483647 >> (b << ~0 + 24) + 8388639;
> }
>
> > clang++ -std=c++11 -w -O3 -march=skx -o f.o -c f.cpp
> clang-5.0:
> /home/dybaboki/llvm/llvm-trunk-20170718/include/llvm/ADT/APInt.h:1399: void
> llvm::APInt::setBits(unsigned int, unsigned int): Assertion `loBit <=
> BitWidth && "loBit out of range"' failed.
> <...>
This is definitely a different testcase, reopening and reducing now :)
--
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 33844] New: Assertion `loBit <= BitWidth && "loBit out of range"' failed with -O1
https://bugs.llvm.org/show_bug.cgi?id=33844
Bug ID: 33844
Summary: Assertion `loBit <= BitWidth && "loBit out of range"'
failed with -O1
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: babo...@gmail.com
CC: llvm-bugs@lists.llvm.org
clang trunk, rev308350, x86_64
> cat f.cpp
int a;
long b;
struct {
char c : 29;
} d;
void e() {
d.c = ~0 + 483647 & (a < 0) + 2147483647 >> (b << ~0 + 24) + 8388639;
}
> clang++ -O1 -o f.o -c f.cpp -w
clang-5.0:
/home/dybaboki/llvm/llvm-trunk-20170718/include/llvm/ADT/APInt.h:1399: void
llvm::APInt::setBits(unsigned int, unsigned int): Assertion `loBit <= BitWidth
&& "loBit out of range"' failed.
#0 0x013170df llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x13170df)
#1 0x013173e6 SignalHandler(int)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x13173e6)
#2 0x7f27d8cbb370 __restore_rt (/lib64/libpthread.so.0+0xf370)
#3 0x7f27d78b31d7 __GI_raise (/lib64/libc.so.6+0x351d7)
#4 0x7f27d78b48c8 __GI_abort (/lib64/libc.so.6+0x368c8)
#5 0x7f27d78ac146 __assert_fail_base (/lib64/libc.so.6+0x2e146)
#6 0x7f27d78ac1f2 (/lib64/libc.so.6+0x2e1f2)
#7 0x007e0478 llvm::APInt::setBits(unsigned int, unsigned int)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x7e0478)
#8 0x008291e7 foldMaskAndShiftToScale(llvm::SelectionDAG&,
llvm::SDValue, unsigned long, llvm::SDValue, llvm::SDValue, (anonymous
namespace)::X86ISelAddressMode&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x8291e7)
#9 0x008284ef (anonymous
namespace)::X86DAGToDAGISel::matchAddressRecursively(llvm::SDValue, (anonymous
namespace)::X86ISelAddressMode&, unsigned int)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x8284ef)
#10 0x008299f9 (anonymous
namespace)::X86DAGToDAGISel::matchAdd(llvm::SDValue, (anonymous
namespace)::X86ISelAddressMode&, unsigned int)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x8299f9)
#11 0x008278cd (anonymous
namespace)::X86DAGToDAGISel::matchAddressRecursively(llvm::SDValue, (anonymous
namespace)::X86ISelAddressMode&, unsigned int)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x8278cd)
#12 0x00825c13 (anonymous
namespace)::X86DAGToDAGISel::matchAddress(llvm::SDValue, (anonymous
namespace)::X86ISelAddressMode&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x825c13)
#13 0x0082a59f (anonymous
namespace)::X86DAGToDAGISel::selectLEAAddr(llvm::SDValue, llvm::SDValue&,
llvm::SDValue&, llvm::SDValue&, llvm::SDValue&, llvm::SDValue&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x82a59f)
#14 0x008242c8 (anonymous
namespace)::X86DAGToDAGISel::CheckComplexPattern(llvm::SDNode*, llvm::SDNode*,
llvm::SDValue, unsigned int, llvm::SmallVectorImpl >&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x8242c8)
#15 0x01a5023f llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*,
unsigned char const*, unsigned int)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x1a5023f)
#16 0x0081f196 (anonymous
namespace)::X86DAGToDAGISel::Select(llvm::SDNode*)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x81f196)
#17 0x01a497da llvm::SelectionDAGISel::DoInstructionSelection()
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x1a497da)
#18 0x01a487f2 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x1a487f2)
#19 0x01a45fa3
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x1a45fa3)
#20 0x01a42b56
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x1a42b56)
#21 0x0081af81 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0x81af81)
#22 0x00bd4f64
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0xbd4f64)
#23 0x00ecfb1f llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0xecfb1f)
#24 0x00ecfd73 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0xecfd73)
#25 0x00ed0266 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/dybaboki/llvm/bin-trunk-20170718/bin/clang-5.0+0xed0266)
#26 0x01487c2f clan
[llvm-bugs] [Bug 33845] New: clang calls __gnu_mcount_nc with the wrong calling convention
https://bugs.llvm.org/show_bug.cgi?id=33845
Bug ID: 33845
Summary: clang calls __gnu_mcount_nc with the wrong calling
convention
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: efrie...@codeaurora.org
CC: compn...@compnerd.org, llvm-bugs@lists.llvm.org,
renato.go...@linaro.org
__gnu_mcount_nc works differently from _mcount. The caller is supposed to pass
its return address on the stack ("push {lr}"), and the stack pointer is
callee-pop. This means that passing "-pg -meabi gnu" to clang will generate
code which corrupts the stack pointer.
Apparently nobody tested r265899.
--
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 33822] DW_AT_decl_file for DW_TAG_imported_declaration is bogus
https://bugs.llvm.org/show_bug.cgi?id=33822 Adrian Prantl changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Adrian Prantl --- Should be fixed by r308398/r308399. -- 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 33846] New: extern thread_local and lto
https://bugs.llvm.org/show_bug.cgi?id=33846
Bug ID: 33846
Summary: extern thread_local and lto
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: anth...@ajrh.net
CC: llvm-bugs@lists.llvm.org
compiling the following into a shared library:
__attribute__ ((visibility("default"))) extern thread_local int foo;
int x() { return foo; }
generates TLS support functions:
% clang++ -std=c++11 -fPIC -shared -o x.so z.cpp && nm x.so | c++filt | grep
TLS
w TLS init function for foo
06c0 t TLS wrapper function for foo
which vanish if -flto is used:
% clang++ -flto -std=c++11 -fPIC -shared -o x.so z.cpp && nm x.so | c++filt |
grep TLS
U TLS init function for foo
=
this is with current Debian testing distribution, per below
% clang++ -v -flto -std=c++11 -fPIC -shared -o x.so z.cpp
clang version 4.0.1-1 (tags/RELEASE_401/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.2
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.2.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.3
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.3.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.5.3
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7.4
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.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.1.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.2.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.3.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.5.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
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.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.1.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.1.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/usr/lib/llvm-4.0/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-llvm-bc
-flto -disable-free -disable-llvm-verifier -discard-value-names -main-file-name
z.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-m
[llvm-bugs] [Bug 26322] Core load hangs
https://bugs.llvm.org/show_bug.cgi?id=26322 Ankit Kothana changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Ankit Kothana --- Any update on this?? -- 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
