[llvm-bugs] [Bug 43207] IR dump prints win64cc but llc does not recognize it
https://bugs.llvm.org/show_bug.cgi?id=43207 Lonnie Chrisman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Lonnie Chrisman --- I'm so sorry. I had an older version of llc on my PATH and didn't realize it. I concur that does not reproduce on the current build. I've marked 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43207] IR dump prints win64cc but llc does not recognize it
https://bugs.llvm.org/show_bug.cgi?id=43207 Lonnie Chrisman changed: What|Removed |Added Resolution|FIXED |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43214] New: relr and overlapping segments not generally converging in AArch64 in thunk creation loop
https://bugs.llvm.org/show_bug.cgi?id=43214 Bug ID: 43214 Summary: relr and overlapping segments not generally converging in AArch64 in thunk creation loop Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: jakehehrl...@google.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org We recently found a bug in lld that infrequently occurs in the Fuchsia AArch64 build. We've only seen it occur once in the wild but after debugging what was going on we figured out what the cause of the issue was. The issue involves relr, https://reviews.llvm.org/D64930, and the thunk creation loop for AArch64. The bug presents as an infinite loop in recent versions and as a lack of convergence in slightly older versions (which is behavior you need to know about to bisect to D64930). The behavior changed to an infinite loop in https://reviews.llvm.org/D66279 What's happening is that the size of relr is ping ponging between two different sizes here(https://github.com/llvm-mirror/lld/blob/master/ELF/Writer.cpp#L1564). This causes `changed` to always be true by the end of this loop and consequently we never exit the loop (the error never triggers because at the start changed is false). This ping ponging occurs because the size of the relro segment is *very* close to being paged aligned. When relr are is small the relro segment winds up ending at address 0x9ffe8. Because of the overlapping segments change above this causes the data segment to start at address 0xafff0. On the next iteration of the loop when relr is updated it has to include this address jump this causes relr to grow by 8 bytes which in turn causes the relro segment to end at 0xefff8. This causes the data segment to wind up at 0xa which is 0xfff0 bytes earilier. On the next iteration of the loop relr goes back to its original state because there is no address jump required because 0xa comes right after 0xefff0. Being back in the same state I haven't thought of a good solution to the general problem. Perhaps when overlapping segments are enabled we should always bump the virtual address? This is only suboptimal in 1 in 4000 cases which is quite rare. Another option would be to add logic to make relr always take up the maximum space that it occupies. This would ensure that relr is always within 8-bytes of its optimal size. I don't have a solution that doesn't require some sub-optimal behavior to occur so far. Another possible direction: It isn't clear to me that the thunks for doing long jumps on arm need to be added in a relaxation loop that updates structures outside of a code segment. If the read only segment becomes larger that will push all code together so relative jumps wouldn't change. This would let us insert thunks inside of a loop and then to assign addresses and update all the structures finally at the end. Given that this wasn't done however I assume I might be misunderstanding something. Using `-z seperate-code` fixes the issue but I haven't groked what that flag does exactly but it seems to bring us closer to the old non-overlapping behavior. I'm not sure if it just changes things in this case because the boundary in question gets pushed to a different spot or if it's fundamentally solving the problem here. In Fuchsia we want to use this flag anyway to ensure that we never have any garbage in our executable pages and the disk/memory trade off for us is such that we always prefer alignment bumps to wasted pages in memory. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43213] New: LLVM's Itanium demangler can't unmangle manglings produced by P0428R2
https://bugs.llvm.org/show_bug.cgi?id=43213
Bug ID: 43213
Summary: LLVM's Itanium demangler can't unmangle manglings
produced by P0428R2
Product: libc++abi
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
https://reviews.llvm.org/D36527 added Ty, Tn, Tt to mangleTemplateParamDecl()
for explicit lambda template parameters.
Consider this program:
$ cat test.cc
template void visit(F &, int v) { return f(v); }
template void visitMatrix(F &, int matrix) {
visit([](auto ) { return f(mat); }, matrix);
}
void myfun() {
visitMatrix([](auto& mat) {}, 15);
}
Before that patch, `clang -c test.cc -std=c++17 -S -emit-llvm -o test.ll`
produced the name `_ZZ11visitMatrixIZ5myfunvE3$_0EvOT_iENKUlRS1_E_clIiEEDaS3_`
for the lambda in the 2nd function.
After that patch, it produces
`_ZZ11visitMatrixIZ5myfunvE3$_0EvOT_iENKUlTyRS1_E_clIiEEDaS3_` which
llvm-c++filt can't unmangle.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43212] New: After r360593, badly aligned offsets when using -N (aka --omagic)
https://bugs.llvm.org/show_bug.cgi?id=43212
Bug ID: 43212
Summary: After r360593, badly aligned offsets when using -N
(aka --omagic)
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org
While attempting to build FreeBSD head with clang and lld 9.0.0, I ran into an
error message from our elftoolchain-based objcopy, when stripping a boot loader
related binary which was linked with lld:
objcopy: elf_update() failed: Layout constraint violation
The problem turns out to be the alignment of the .rodata section:
$ readelf -lSW
/usr/obj/share/dim/src/freebsd/clang900-import/amd64.amd64/stand/i386/gptboot/gptboot.out
There are 19 section headers, starting at offset 0x2e454:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf
Al
[ 0] NULL 00 00 00 0 0
0
[ 1] .text PROGBITS 94 00a504 00 AX 0 0
4
[ 2] .rodata PROGBITSa508 00a59c 0038fb 00 AMS 0 0
8
...
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x94 0x 0x 0x0df3c 0x0df3c RWE 0x8
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0
E.g., .rodata starts at offset 0xa59c, while its alignment is supposed to be 8
bytes. Similarly, the LOAD segment has an offset of 0x94, while its alignment
is 8 bytes.
This problem started occurring after https://reviews.llvm.org/rLLD360593
("[ELF] Full support for -n (--nmagic) and -N (--omagic) via common page").
Before this change, the -N option got largely ignored, which is why we never
saw this issue before.
Minimal test case:
$ cat align-test.s
.text
.globl _start
_start:
xor %eax,%eax
retl
.rodata
.align 8
.quad 42
$ cc -m32 -c align-test.s
$ readelf -S align-test.o
There are 5 section headers, starting at offset 0x88:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf
Al
[ 0] NULL 00 00 00 0 0
0
[ 1] .strtab STRTAB 60 26 00 0 0
1
[ 2] .text PROGBITS 34 03 00 AX 0 0
4
[ 3] .rodata PROGBITS 38 08 00 A 0 0
8
[ 4] .symtab SYMTAB 40 20 10 1 1
4
# with ld.lld r360592, everything is page-aligned, even while -N is used:
$ ~/llvm/trunk-r360592/bin/ld.lld -m elf_i386_fbsd -N -Ttext 0x0 -o
align-test-r360592.out align-test.o
$ readelf -lS align-test-r360592.out
Elf file type is EXEC (Executable file)
Entry point 0x0
There are 2 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x 0x 0x01000 0x01000 RWE 0x1000
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0
Section to Segment mapping:
Segment Sections...
00 .text .rodata
01
There are 7 section headers, starting at offset 0x20a4:
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf
Al
[ 0] NULL 00 00 00 0 0
0
[ 1] .text PROGBITS 001000 03 00 AX 0 0
4
[ 2] .rodata PROGBITS0008 001008 08 00 A 0 0
8
[ 3] .comment PROGBITS 002000 47 01 MS 0 0
1
[ 4] .symtab SYMTAB 002048 20 10 6 1
4
[ 5] .shstrtab STRTAB 002068 32 00 0 0
1
[ 6] .strtab STRTAB 00209a 08 00 0 0
1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
# with ld.lld r360593, -N does much more, but messes up the offsets:
$ ~/llvm/trunk-r360593/bin/ld.lld -m elf_i386_fbsd -N -Ttext 0x0 -o
align-test-r360593.out align-test.o
$ readelf -lS align-test-r360593.out
Elf file type is EXEC (Executable file)
Entry point 0x0
There are 2 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x94 0x 0x 0x00010 0x00010 RWE 0x8
[llvm-bugs] [Bug 42844] Clang crash when compiling with -Wdocumentation-unknown-command
https://bugs.llvm.org/show_bug.cgi?id=42844 Mark de Wever changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Mark de Wever --- During the review we concluded it was not wanted to have \return on a typedef'ed type. So the code will result in a warning. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 16944 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: idx < size()
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-09-03 Type: Bug New issue 16944 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--x86_64-O2: ASSERT: idx < size() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16944 Detailed Report: https://oss-fuzz.com/testcase?key=5079705933316096 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: idx < size() DAGCombiner::visit DAGCombiner::combine Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201908290314:201908310326 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5079705933316096 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43211] New: [wasm] __import_module__, __import_name__ attributes do not work with -flto
https://bugs.llvm.org/show_bug.cgi?id=43211
Bug ID: 43211
Summary: [wasm] __import_module__, __import_name__ attributes
do not work with -flto
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: alonza...@gmail.com
CC: llvm-bugs@lists.llvm.org
extern void foo() __attribute__((__import_module__("module"),
__import_name__("base")));
int main() {
foo();
}
Building with say
emcc a.cpp -s ERROR_ON_UNDEFINED_SYMBOLS=0 -g
the output contains
(import "module" "base" (func $foo\28\29))
However, adding -flto to that command breaks things - it now imports as
(import "env" "_Z3foov" (func $foo\28\29))
Perhaps the attributes information is supported in wasm object files but not in
LLVM bitcode files?
This affects wasi which uses those attributes.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43203] Crash when using .code32 in assembly with target x86_64-unknown-windows
https://bugs.llvm.org/show_bug.cgi?id=43203 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |FIXED --- Comment #2 from Reid Kleckner --- The COFF asm streamer shouldn't need to do anything to handle the .code32 directive, so I made it behave as the other object format streamers do in r370805. Thanks for the report! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43210] New: [SimplifyCFG] Failure to flatten and simplify checks
https://bugs.llvm.org/show_bug.cgi?id=43210
Bug ID: 43210
Summary: [SimplifyCFG] Failure to flatten and simplify checks
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
https://godbolt.org/z/rokl2m
#include // for intptr_t
bool is_ub(char *base, unsigned long offset) {
// Cast pointer to integer, perform usual arithmetic addition,
// and cast to pointer. This is legal.
char *computed = reinterpret_cast(reinterpret_cast(base) +
offset);
// If either the pointer becomes non-nullptr, or becomes nullptr, we must use
``computed`` result.
return (((base == nullptr) && (computed != nullptr)) ||
((base != nullptr) && (computed == nullptr)));
}
After -O3 produces:
define dso_local zeroext i1 @_Z5is_ubPcm(i8* %0, i64 %1) local_unnamed_addr #0
{
%3 = ptrtoint i8* %0 to i64
%4 = add i64 %3, %1
%5 = icmp eq i8* %0, null
%6 = icmp ne i64 %4, 0
%7 = and i1 %5, %6
br i1 %7, label %12, label %8
8:; preds = %2
%9 = icmp ne i8* %0, null
%10 = icmp eq i64 %4, 0
%11 = and i1 %9, %10
br label %12
12: ; preds = %8, %2
%13 = phi i1 [ true, %2 ], [ %11, %8 ]
ret i1 %13
}
But this should just be
define dso_local zeroext i1 @_Z5is_ubPcm(i8* %0, i64 %1) local_unnamed_addr #0
{
%3 = ptrtoint i8* %0 to i64
%4 = icmp ne i8* %0, null
%5 = sub i64 0, %1
%6 = icmp eq i64 %3, %5
%7 = xor i1 %4, %6
ret i1 %7
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43208] Struct return does not match Windows X64 stack convention.
https://bugs.llvm.org/show_bug.cgi?id=43208 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED CC||efrie...@quicinc.com Resolution|--- |WONTFIX --- Comment #2 from Eli Friedman --- Yes, this is handled in clang. In general, LLVM IR does not contain enough information about C structs to compute the C calling convention correctly; we can't even distinguish whether an LLVM IR struct type was originally a C struct. Therefore, LLVM IR's handling of struct type in the calling convention is intentionally simplified: LLVM IR structs are always passed and returned in registers, as long as enough registers are available. The only supported way to lower a C calling convention call involving a class/struct/union/complex type is to use clang's IR generation API, or implement equivalent code yourself. There's been some discussion in the past of providing an API for non-clang frontends that's more convenient, but nothing has been implemented. You should be able to find some discussion in the mailing list archive. (If you have trouble finding it, ask, and I'll try to dig it up.) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40794] [WebAssembly] LLVM atomic fence lowering is not supported
https://bugs.llvm.org/show_bug.cgi?id=40794 Derek Schuff changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Derek Schuff --- Fixed by aheejin in https://reviews.llvm.org/D66794 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43209] New: [AArch64][StrctFP] constrained.fptrunc.f32.f64 crashes on AArch64
https://bugs.llvm.org/show_bug.cgi?id=43209
Bug ID: 43209
Summary: [AArch64][StrctFP] constrained.fptrunc.f32.f64 crashes
on AArch64
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following test case crashes on AArch64. FP_ROUND is marked Custom rathern
than Legal this causes LegalizeDAG to try to expand STRICT_PF_ROUND to a
conversion using the stack. That conversion creates a truncating store from f64
to f32. But that truncating store isn't Legal on AArch64. So it tries to be
expanded, but there is no handling for expanding a truncating FP store. So it
asserts.
define float @f21() {
entry:
%result = call float @llvm.experimental.constrained.fptrunc.f32.f64(
double 42.1,
metadata !"round.dynamic",
metadata !"fpexcept.strict")
ret float %result
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43208] New: Struct return does not match Windows X64 stack convention.
https://bugs.llvm.org/show_bug.cgi?id=43208
Bug ID: 43208
Summary: Struct return does not match Windows X64 stack
convention.
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: release blocker
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: lchris...@lumina.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
As I understand it, the Microsoft Win x64 calling convention returns a struct
that exceeds 64 bits as if it were the 1st parameter of the function. I.e.,
caller sets RCX to point to memory for the return struct (usually on caller's
stack), then callee sets RAX to same.
This is not the convention that I see being used when running LLVM on windows.
This function:
%MyStruct = type { i16, i64 }
define common %MyStruct @ret_struct() {
begin:
ret %MyStruct { i16 13, i64 23 }
}
compiles to:
mov ax,0Dh
mov edx,17h
ret
Then a call to the function from VC++ crashes. I would expect to see something
more like:
mov word ptr [ecx],0Dh
mov dword ptr [rcx+8],17h
mov rax,rcx
ret
When I look at the code generated by VC++ for the function:
MyStruct G()
{
return MyStruct{13,23};
}
I see it doing basically this.
Because of the calling convention mismatch, my call to the LLVM-compiled
function crashes, i.e.:
auto F = (MyStruct(*)()) ExitOnErr(jit->lookup("ret_struct")).getAddress();
MyStruct s = F(); // crash
I notice that llc does the same thing for this example. E.g.: given a file "try
call conv.ll" containing:
%MyStruct = type { i16, i64 }
define %MyStruct @ret_struct() {
begin:
ret %MyStruct { i16 13, i64 23 }
}
Then the command:
> llc "try call conv.ll" -o -
.def ret_struct;
.scl2;
.type 32;
.endef
.text
.globl ret_struct
.align 16, 0x90
ret_struct: # @ret_struct
# BB#0: # %begin
movw$13, %ax
movl$23, %edx
ret
However, I also find an inconsistency between llc and the libraries. When I
change the example to
%MyStruct = type { i16, i8, i64 }
define %MyStruct @ret_struct() {
begin:
ret %MyStruct { i16 13, i8 0, i64 23 }
}
(The i8 is in the padding area, so this doesn't change the struct size) In this
case, llc uses the window x64 return convention (good):
.def ret_struct;
.scl2;
.type 32;
.endef
.text
.globl ret_struct
.align 16, 0x90
ret_struct: # @ret_struct
# BB#0: # %begin
movq$23, 8(%rcx)
movb$0, 2(%rcx)
movw$13, (%rcx)
ret
But, when I make this same change in the C++ code, it still returns the struct
in registers, not using the Microsoft x64 convention.
In C++, setting the calling convention for the function to Win64 does not
change the code generated in either example.
-
Here is the C++ code. Compiled on VC++ 2017. Same on both Win10 & Win7.
#include "llvm/Bitcode/BitcodeWriter.h"
#include "llvm/IR/BasicBlock.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/InstrTypes.h"
#include "llvm/IR/Instruction.h"
#include "llvm/IR/Instructions.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/Type.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/ExecutionEngine/Orc/LLJIT.h"
#include "llvm/Support//TargetSelect.h"
#include "llvm/IR/IRBuilder.h"
#include
using namespace llvm;
using namespace llvm::orc;
using std::cout;
using std::endl;
using std::unique_ptr;
using std::make_unique;
ExitOnError ExitOnErr;
struct MyStruct {
uint16_t n1_;
uint64_t n2_;
};
ThreadSafeModule MakeM()
{
auto pCtx = make_unique();
auto& ctx = *pCtx;
auto pM = make_unique("My_module",ctx);
auto& M = *pM;
auto myStruct = StructType::create(ctx,
{ Type::getInt16Ty(ctx),
Type::getInt64Ty(ctx)
},"MyStruct");
FunctionType* proto = FunctionType::get(myStruct,false);
Function* fn =
Function::Create(proto,GlobalValue::LinkageTypes::CommonLinkage,"ret_struct",M);
//fn->setCallingConv(CallingConv::Win64);
BasicBlock* BB = BasicBlock::Create(ctx,"begin",fn);
IRBuilder<> builder(BB);
//Value* ms = builder.CreateAlloca(myStruct,nullptr,"ms");
auto ms = ConstantStruct::get(myStruct,
{ ConstantInt::get(ctx,APInt(16,13,true)),
ConstantInt::get(ctx,APInt(64,23uLL))
} );
[llvm-bugs] Issue 10821 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in EvaluateValue
Updates: Labels: -Reproducible Unreproducible Comment #11 on issue 10821 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in EvaluateValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10821#c11 ClusterFuzz testcase 5651987115278336 appears to be flaky, updating reproducibility label. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12439 in oss-fuzz: llvm/llvm-itanium-demangle-fuzzer: Stack-overflow in llvm::itanium_demangle::AbstractManglingParser
Updates: Labels: -Reproducible Unreproducible Comment #10 on issue 12439 by ClusterFuzz-External: llvm/llvm-itanium-demangle-fuzzer: Stack-overflow in llvm::itanium_demangle::AbstractManglingParser https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12439#c10 ClusterFuzz testcase 511812432242 appears to be flaky, updating reproducibility label. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43207] New: IR dump prints win64cc but llc does not recognize it
https://bugs.llvm.org/show_bug.cgi?id=43207
Bug ID: 43207
Summary: IR dump prints win64cc but llc does not recognize it
Product: tools
Version: trunk
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedb...@nondot.org
Reporter: lchris...@lumina.com
CC: llvm-bugs@lists.llvm.org
You can produce an IR dump with a win64cc calling convention, like this one:
%MyStruct = type { i16, i64 }
define win64cc %MyStruct @ret_struct() {
begin:
ret %MyStruct { i16 13, i64 23 }
}
But when you compile it with llc, it gives an error that it doesn't recognize
it. If it can print it, it seems like it should parse it.
Steps:
1. Same the above to win64cctest.ll
2. On command line, run: llc win64cctest.ll -o -
{ Actual: error: expected type. Points to win64cc }
{ Expected: Would succeed }
---
Printing side:
ThreadSafeModule MakeM()
{
auto pCtx = make_unique();
auto& ctx = *pCtx;
auto pM = make_unique("My_module",ctx);
auto& M = *pM;
auto myStruct = StructType::create(ctx,
{ Type::getInt16Ty(ctx),
Type::getInt64Ty(ctx)
},"MyStruct");
FunctionType* proto = FunctionType::get(myStruct,false);
Function* fn =
Function::Create(proto,GlobalValue::LinkageTypes::CommonLinkage,"ret_struct",M);
fn->setCallingConv(CallingConv::Win64);
BasicBlock* BB = BasicBlock::Create(ctx,"begin",fn);
IRBuilder<> builder(BB);
//Value* ms = builder.CreateAlloca(myStruct,nullptr,"ms");
auto ms = ConstantStruct::get(myStruct,
{ ConstantInt::get(ctx,APInt(16,13,true)),
ConstantInt::get(ctx,APInt(64,23uLL))
} );
builder.CreateRet(ms);
cout << "The IR is:\n";
outs() << M;
cout << endl;
return ThreadSafeModule(std::move(pM),std::move(pCtx));
}
int main()
{
InitializeNativeTarget();
InitializeNativeTargetAsmPrinter();
auto M = MakeM();
...
}
--
Additional comments:
* Using most recent SVN branch, reproduced both on Win 7 and Win 10. (Your bug
base OS pulldown doesn't have anything after Windows XP)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 15908 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Updates: Labels: -Reproducible Unreproducible Comment #5 on issue 15908 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::StmtVisitorBaseSequenceChecker, void>::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15908#c5 ClusterFuzz testcase 5732154518011904 appears to be flaky, updating reproducibility label. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 12898 in oss-fuzz: llvm/clangd-fuzzer: Stack-overflow in llvm::json::Parser::parseValue
Updates: Labels: -Reproducible Unreproducible Comment #9 on issue 12898 by ClusterFuzz-External: llvm/clangd-fuzzer: Stack-overflow in llvm::json::Parser::parseValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12898#c9 ClusterFuzz testcase 5732132821925888 appears to be flaky, updating reproducibility label. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37022] Segfault when attempting to assign to recursive struct
https://bugs.llvm.org/show_bug.cgi?id=37022 Ryan Gonzalez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ryan Gonzalez --- This was fixed in Clang 8. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10821 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in EvaluateValue
Updates: Labels: -Reproducible Unreproducible Comment #9 on issue 10821 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in EvaluateValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10821#c9 ClusterFuzz testcase 5651987115278336 appears to be flaky, updating reproducibility label. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43206] New: Loop idiom recognizer miscompiles a memcmp loop
https://bugs.llvm.org/show_bug.cgi?id=43206 Bug ID: 43206 Summary: Loop idiom recognizer miscompiles a memcmp loop Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: malts...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 22466 --> https://bugs.llvm.org/attachment.cgi?id=22466=edit Source code After a recent commit commit 5c9f3cfec78f9e9ae013de9a0d092a68e3e79e00 Author: Roman Lebedev Date: Fri Aug 30 09:51:23 2019 + [LoopIdiomRecognize] BCmp loop idiom recognition ... some of our internal tests started failing on AArch64 and ARM targets. When the attached reproducer test.c is compiled with the following options: clang -c -O3 --target=aarch64-arm-none-eabi -march=armv8-a+simd+fp+nocrypto -std=c99 test.c -o test.o then linked and run on a model it outputs: "RESULT: FAILED". The same code compiled with the previous LLVM commit outputs the expected string "RESULT: PASSED" Bugpoint points to the loop-idiom pass. The attached bitcode demonstrates the problem (it produces the correct output, but when run through 'opt -loop-idiom', the output becomes incorrect). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43205] New: [SimplifyCFG] Performance regression in mergeConditionalStoreToAddress
https://bugs.llvm.org/show_bug.cgi?id=43205
Bug ID: 43205
Summary: [SimplifyCFG] Performance regression in
mergeConditionalStoreToAddress
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: kpde...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 22465
--> https://bugs.llvm.org/attachment.cgi?id=22465=edit
Test case for the regression
I encounter a performance regression on the trunk for aarch64
Test case is not very easy (unfortunately).
But in general this regression can be described as follows:
Clang tries to replace branches with select instructions but in this test case
it leads to greater number of instructions and it became x1.5 slower (on my
arm64 Mate10 device).
__attribute__((noinline)) int do_select(const int max_iters_count,
const unsigned long in,
const unsigned long out,
const unsigned long ex,
const unsigned long bit_init_val,
const unsigned long mask)
{
int retval = 0;
for(int k =0 ; k < max_iters_count; k++)
{
fd_set_bits *fds = gv_fds;
unsigned long *rinp = fds->res_in;
for(int i= 0; i < g_max_i; ++i, ++rinp)
{
unsigned long bit = bit_init_val;
unsigned long res_in = 0;
//= INNER LOOP, WHICH HAS A PROBLEM
for(int j = 0; j < BITS_PER_LONG; ++j, bit <<= 1)
{
if (in & bit) {
res_in |= bit;
retval++;
fds->proc = NULL;
}
if (mask & POLLOUT_SET) {
fds->proc = NULL;
}
}
*rinp = res_in;
}
}
return retval;
}
Source code with test case is attached to the message (select.c).
Asm for body of inner loop :
latest clang:
78c: 8a010043and x3, x2, x1
790: ea01005ftst x2, x1
794: aa030165orr x5, x11, x3
798: 1a800400cincw0, w0, ne
79c: 9a8203e3cselx3, xzr, x2, eq
7a0: b445cbz x5, 7a8
7a4: f9001dbfstr xzr, [x13,#56]
7a8: aa030210orr x16, x16, x3
latest clang with -mllvm -phi-node-folding-threshold=1:
78c: ea01025ftst x18, x1
790: 5480b.eq7a0
794: aa120210orr x16, x16, x18
798: 11000400add w0, w0, #0x1
79c: f9001dbfstr xzr, [x13,#56]
7a0: b44bcbz x11, 7a8
7a4: f9001dbfstr xzr, [x13,#56]
I have tested this regression with a plenty of input data, and there are no
cases when clang with default phi-node-folding-threshold=2
is better than clang with phi-node-folding-threshold=1.
Additional (unoptimal) instructions are generated in SimplifyCFG pass
1) Function mergeConditionalStoreToAddress transforms the blocks, moving store
instructions out of two blocks
===
IR before mergeConditionalStoreToAddress (attention to blocks if.end if.then
if.then15)
; Function Attrs: noinline norecurse nounwind
define dso_local i32 @do_select(i32 %max_iters_count, i64 %in, i64 %out, i64
%ex, i64 %bit_init_val, i64 %mask) local_unnamed_addr #
0 !dbg !59 {
entry:
call void @llvm.dbg.value(metadata i32 %max_iters_count, metadata !65,
metadata !DIExpression()), !dbg !86
call void @llvm.dbg.value(metadata i64 %in, metadata !66, metadata
!DIExpression()), !dbg !87
call void @llvm.dbg.value(metadata i64 %out, metadata !67, metadata
!DIExpression()), !dbg !88
call void @llvm.dbg.value(metadata i64 %ex, metadata !68, metadata
!DIExpression()), !dbg !89
call void @llvm.dbg.value(metadata i64 %bit_init_val, metadata !69, metadata
!DIExpression()), !dbg !90
call void @llvm.dbg.value(metadata i64 %mask, metadata !70, metadata
!DIExpression()), !dbg !91
call void @llvm.dbg.value(metadata i32 0, metadata !71, metadata
!DIExpression()), !dbg !92
call void @llvm.dbg.value(metadata i32 0, metadata !72, metadata
!DIExpression()), !dbg !93
%cmp52 = icmp sgt i32 %max_iters_count, 0, !dbg !94
br i1 %cmp52, label %for.body.lr.ph, label %for.cond.cleanup, !dbg !95
for.body.lr.ph: ; preds = %entry
%and13 = and i64 %mask, 780
%tobool14 = icmp eq i64 %and13, 0
br label %for.body, !dbg !95
for.cond.cleanup: ; preds = %for.cond.cleanup5,
%entry
%retval1.0.lcssa = phi i32 [ 0, %entry
[llvm-bugs] [Bug 43204] New: clang 9 "no such file" error on Windows mapped drive
https://bugs.llvm.org/show_bug.cgi?id=43204 Bug ID: 43204 Summary: clang 9 "no such file" error on Windows mapped drive Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, jeroen.dobbela...@synopsys.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Blocks: 43166 As reported by Jeroen here: http://lists.llvm.org/pipermail/cfe-dev/2019-September/063225.html clang 9 does not seem to be able to open files using relative paths on mapped drives. For example: mkdir \src\tmp\foo net use x: \\localhost\c$\src\tmp\foo gvim x:\a.c x: c:\src\llvm.monorepo\build.release\bin\clang-cl /c a.c clang-cl: error: no such file or directory: 'a.c' clang 8 did not have this problem. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=43166 [Bug 43166] LoopVectorizer miscompiles (when doing fold by tail masking?) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39418] Do not ICF two sections with different output sections when using linker scripts
https://bugs.llvm.org/show_bug.cgi?id=39418 Fangrui Song 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43203] New: Crash when using .code32 in assembly with target x86_64-unknown-windows
https://bugs.llvm.org/show_bug.cgi?id=43203 Bug ID: 43203 Summary: Crash when using .code32 in assembly with target x86_64-unknown-windows Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: j...@alien8.de CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22462 --> https://bugs.llvm.org/attachment.cgi?id=22462=edit Offending assembly file I am trying to compile a PE binary on Linux that contains some 32-bit code (it's an UEFI OS loader). The .S file containing this 32-bit code crashes clang. See below for reproduction steps and stack dump. This may be related to https://bugs.llvm.org/show_bug.cgi?id=34752 and https://bugs.llvm.org/show_bug.cgi?id=8595 Even if the feature is not implemented, I would not expect the compiler to crash. % clang-8 --version clang version 8.0.0 (Fedora 8.0.0-1.fc30) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin % cat pmjump.S .code32 % clang-8 -target x86_64-unknown-windows -m64 -c pmjump.S Stack dump: 0. Program arguments: /usr/bin/clang-8 -cc1as -triple x86_64-unknown-windows-msvc19.11.0 -filetype obj -main-file-name pmjump.S -target-cpu x86-64 -fdebug-compilation-dir /home/julian/tmp -dwarf-debug-producer clang version 8.0.0 (Fedora 8.0.0-1.fc30) -dwarf-version=4 -mrelocation-model pic -mincremental-linker-compatible -o pmjump.o /tmp/pmjump-07eb43.s #0 0x7fa2b6c0906e llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/lib64/libLLVM-8.so+0xabd06e) #1 0x7fa2b6c07014 llvm::sys::RunSignalHandlers() (/lib64/libLLVM-8.so+0xabb014) #2 0x7fa2b6c07195 (/lib64/libLLVM-8.so+0xabb195) #3 0x7fa2b4f88f00 __restore_rt (/lib64/libc.so.6+0x37f00) #4 0x7fa2b6a3c0aa (/lib64/libLLVM-8.so+0x8f00aa) #5 0x55f4f9421370 clang-8: error: unable to execute command: Segmentation fault (core dumped) clang-8: error: clang integrated assembler command failed due to signal (use -v to see invocation) clang version 8.0.0 (Fedora 8.0.0-1.fc30) Target: x86_64-unknown-windows-msvc Thread model: posix InstalledDir: /usr/bin clang-8: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script. clang-8: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-8: note: diagnostic msg: /tmp/pmjump-753307.S clang-8: note: diagnostic msg: /tmp/pmjump-753307.sh clang-8: note: diagnostic msg: -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 23370] [meta] Using Clang/LLVM as the FreeBSD/mips system compiler
https://bugs.llvm.org/show_bug.cgi?id=23370 Bug 23370 depends on bug 43119, which changed state. Bug 43119 Summary: [MIPS][FreeBSD] non-ABS relocation in .mdebug.abi32 https://bugs.llvm.org/show_bug.cgi?id=43119 What|Removed |Added Status|REOPENED|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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43119] [MIPS][FreeBSD] non-ABS relocation in .mdebug.abi32
https://bugs.llvm.org/show_bug.cgi?id=43119 Simon Atanasyan changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Simon Atanasyan --- Fixed at r370735. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43077] Function epilog optimization does not work
https://bugs.llvm.org/show_bug.cgi?id=43077 Rainer Herbertz changed: What|Removed |Added Fixed By Commit(s)||r370728 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Rainer Herbertz --- Fixed by patch: https://reviews.llvm.org/rL370728 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43166] LoopVectorizer miscompiles (when doing fold by tail masking?)
https://bugs.llvm.org/show_bug.cgi?id=43166 bjorn.a.petters...@ericsson.com changed: What|Removed |Added Status|CONFIRMED |RESOLVED CC||h...@chromium.org Fixed By Commit(s)||r370720 r370721 Severity|enhancement |release blocker Resolution|--- |FIXED --- Comment #8 from bjorn.a.petters...@ericsson.com --- Landed in r370721 (with precommit of test case in r370720). Should this be added to meta tickets for 8.0.1: https://bugs.llvm.org/show_bug.cgi?id=41221 9.0.0: https://bugs.llvm.org/show_bug.cgi?id=42474 (I could not see any meta for 9.0.1 yet, but maybe this is too late for 9.0.0) I changed "Importance" to "release blocker" since it was a miscompile. (Not sure exactly how that field usually is used.) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43202] New: ARM FastIsel is renaming the memcpy to memcpy. in getLibcallReg().
https://bugs.llvm.org/show_bug.cgi?id=43202 Bug ID: 43202 Summary: ARM FastIsel is renaming the memcpy to memcpy. in getLibcallReg(). Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: umesh.kalap...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22461 --> https://bugs.llvm.org/attachment.cgi?id=22461=edit testcase The attached file compiled like clang --target=arm-linux-eabi -mcpu=cortex-a9 -w -fno-builtin -mlong-calls testcase.cpp -c; nm testcase.o | grep memcpy U memcpy U memcpy.202 U memcpy.203 U memcpy.204 results with linker undefined symbols error . When we investigated why the codegen renames it ,the following code ARMFastISel.cpp @ getLibcallReg do so. >>GlobalValue *GV = new GlobalVariable(M, Type::getInt32Ty(*Context), false, GlobalValue::ExternalLinkage, nullptr, Name); where "Name=memcpy" in this case and GlobalVariable creates new instance with "Name" if doesn't exist in the module table ,else its renames with appending the random number to "Name". But its not the semantics we required here ,hence we modified the code like >>GlobalValue *GV = cast >>(M.getOrInsertGlobal(Name.getSingleStringRef(), >>Type::getInt32Ty(*Context))); where we used Module.getOrInsertGlobal () instead and getOrInsertGlobal() creates new instance with "Name" if doesn't exist ,else returns the exist one . -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
