This patch removes lot of static Instances arrays from different input file
classes and introduces global arrays for access instead. Similar to arrays we
have for InputSections/OutputSectionCommands.
It allows to iterate over input files in a non-templated code.
Differential revision: https://reviews.llvm.org/D35987
llvm-svn: 313619
This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and
--dynamic-list controls which of those are preemptible.
Unlike previous versions, undefined symbols are still considered
preemptible, which was the issue breaking the cfi tests.
This fixes pr34053.
llvm-svn: 312806
If --dynamic-list is given, only those symbols are preemptible.
This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and --dynamic-list
controls which of those are preemptible.
This fixes pr34053.
llvm-svn: 312757
Patch by Rafael Espíndola.
This is PR34053.
The implementation is a bit of a hack, given the precise location where
IsPreemtible is set, it cannot be used from
SymbolTable::handleAnonymousVersion.
I could add another method to SymbolTable if you think that would be
better.
Differential Revision: https://reviews.llvm.org/D36499
llvm-svn: 311468
With this Symbol has the same size as before, but DefinedRegular goes
from 72 to 64 bytes.
I also find this a bit easier to read. There are fewer places
initializing File for example.
This has a small but measurable speed improvement on all tests (1%
max).
llvm-svn: 310142
In addition this includes a change to prefer symbols with a default
version @@ over unversioned symbols.
Original commit message:
[ELF] - Handle symbols with default version early.
This fixes last testcase provided in PR28414.
In short issue is next: when we had X@@Version symbol in object A,
we did not resolve it to X early. Then when in another object B
we had reference to undefined X, symbol X from archive was fetched.
Since both archive and object A contains another symbol Z, duplicate
symbol definition was triggered as a result.
Correct behavior is to use X@@Version from object A instead and do not fetch
any symbols from archive.
Differential revision: https://reviews.llvm.org/D35059
llvm-svn: 308492
This fixes PR33712.
Imagine following script and code:
VER1 { global: foo; local: *; };
VER2 { global: foo; };
.global bar
bar:
.symver bar, foo@VER1
.global zed
zed:
.symver zed, foo@@VER2
We add foo@@VER2 as foo to symbol table, because have to resolve references to
foo for default symbols.
Later we are trying to assign symbol versions from script. For that we are searching for 'foo'
again. Here it is placed under VER1 and VER2 at the same time, we find it twice and trying to
set version again both times, hence LLD shows a warning.
Though sample code is correct: we have 2 different versions of foo.
Patch gives a symbol version extracted from name a priority over version set by script.
Differential revision: https://reviews.llvm.org/D35207
llvm-svn: 307792
When version script was used, binding opf undefined weak symbols sometimes
was calculated as STB_LOCAL, making them non-preemtible what
broke correct relocations handling logic for them.
Fixes PR33738.
Differential revision: https://reviews.llvm.org/D35263
llvm-svn: 307767
This fixes last testcase provided in PR28414.
In short issue is next: when we had X@@Version symbol in object A,
we did not resolve it to X early. Then when in another object B
we had reference to undefined X, symbol X from archive was fetched.
Since both archive and object A contains another symbol Z, duplicate
symbol definition was triggered as a result.
Correct behavior is to use X@@Version from object A instead and do not fetch
any symbols from archive.
Differential revision: https://reviews.llvm.org/D35059
llvm-svn: 307364
This is PR28414.
Previously LLD was unable to link following:
(failed with undefined symbol bar)
Version script:
SOME_VERSION { global: *; };
.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
jmp bar
Manual has next description:
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename.
The difference is name2@@nodename will also be used to resolve references to name2 by the linker
https://sourceware.org/binutils/docs/as/Symver.html
Patch implements that. If we have name@@ver symbol and name is undefined, name@@ver is used to resolve references to name.
If name is defined then multiple definition error is emited, that is consistent with what bfd do.
Differential revision: https://reviews.llvm.org/D33680
llvm-svn: 307077
This is PR28414.
Previously LLD was unable to link following:
(failed with undefined symbol bar)
```
Version script:
SOME_VERSION { global: *; };
.global _start
.global bar
.symver _start, bar@@SOME_VERSION
_start:
jmp bar
```
Manual has next description:
//
.symver name, name2@@nodename
In this case, the symbol name must exist and be defined within the file being assembled. It is similar to name2@nodename.
**The difference is name2@@nodename will also be used to resolve references to name2 by the linker**
https://sourceware.org/binutils/docs/as/Symver.html
//
Patch implements that. If we have name@@ver symbol and name is undefined,
name@@ver is used to resolve references to name.
Differential revision: https://reviews.llvm.org/D33680
llvm-svn: 306813
We could have add this function either Symbol or SymbolBody. I added it
to Symbol at first. But I noticed that if I've added it to SymbolBody,
we could've removed SymbolBody::setName(). So I'll do that in this patch.
llvm-svn: 306590
Previously, when symbol A is renamed B, both A and B end up having
the same name. This is because name is a symbol's attribute, and
we memcpy symbols for symbol renaming.
This pathc saves the original symbol name and restore it after memcpy
to keep the original name.
This patch shouldn't change program's meaning, but names in symbol
tables make more sense than before.
llvm-svn: 306036
The --exclude-libs option is not a popular option, but at least some
programs in Android depend on it, so it's worth to support it.
Differential Revision: https://reviews.llvm.org/D34422
llvm-svn: 305920
procedural optimizations to prevent dropping symbols and allow the linker
to process re-directs.
PR33145: --wrap doesn't work with lto.
Differential Revision: https://reviews.llvm.org/D33621
llvm-svn: 304719
A variable `ComdatGroup` is not supposed to contain a large number of
items. Even when linking clang, it ends up having only 300K strings.
It doesn't make sense to use CachedHashStringRef for this hash table.
This patch has neutral or slightly positive impact on performance while
reducing code complexity.
llvm-svn: 303787
This patch is to reduce amount of template uses. The new code is less
exciting and boring than before, but I think it is easier to read.
Differential Revision: https://reviews.llvm.org/D32467
llvm-svn: 301488
gnu ld description of option is:
--defsym=symbol=expression
Create a global symbol in the output file, containing the absolute address given
by expression. You may use this option as many times as necessary to define multiple
symbols in the command line. A limited form of arithmetic is supported for the
expression in this context: you may give a hexadecimal constant or the name of an
existing symbol, or use "+" and "-" to add or subtract hexadecimal constants or
symbols. If you need more elaborate expressions, consider using the linker command
language from a script. Note: there should be no white space between symbol,
the equals sign ("="), and expression.
In compare with D32082, this patch does not support math expressions and absolute
symbols. It implemented via code similar to --wrap. That covers 1 of 3 possible
--defsym cases.
Differential revision: https://reviews.llvm.org/D32171
llvm-svn: 301391
BSD's __progname symbol is defined in crt1.o and linked against main
executables. The libc expects that main executables export __progname
symbol via .dynsym sections. In order to handle this case, we scan
undefined symbols in DSOs and exported them by setting Sym->ExportDynamic
to true.
But it turned out that setting that variable is not enough to make sure
that symbols are exported in all use cases. If a -dynamic-list option is
given, all symbols not explicitly mentioned in a version script are
hidden by default. That hides __progname symbol. This patch fixes the issue.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32703
llvm-svn: 301282
We can just use the existing SoName member variable. It now initially
contains what was in DefaultSoName and is modified if the .so has an
actual soname.
llvm-svn: 301259
The ELF spec says:
all of the non-default visibility attributes, when applied to a symbol
reference, imply that a definition to satisfy that reference must be
provided within the current executable or shared object.
But we were trying to resolve those undef references to shared
symbols. That causes odd results like creating a got entry with
a relocation pointing to 0.
llvm-svn: 299464
This patch is intended to improve readability of "duplicate symbol"
error messages.
Without this patch:
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Relocations.cpp:1054: duplicate symbol 'lld:🧝:demangle(llvm::StringRef)'
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Strings.cpp:93: previous definition was here
With this patch:
/ssd/clang/bin/ld.lld: error: duplicate symbol: lld:🧝:demangle(llvm::StringRef)
>>> defined at Strings.cpp:93 (/ssd/llvm-project/lld/ELF/Strings.cpp:93)
>>> Strings.cpp.o:(lld:🧝:demangle(llvm::StringRef)) in archive lib/liblldELF.a
>>> defined at Relocations.cpp:1054 (/ssd/llvm-project/lld/ELF/Relocations.cpp:1054)
>>> Relocations.cpp.o:(.text+0x4C30) in archive lib/liblldELF.a
Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html
Differential Revision: https://reviews.llvm.org/D31507
llvm-svn: 299280
With this we have a single section hierarchy. It is a bit less code,
but the main advantage will be in a future patch being able to handle
foo = symbol_in_obj;
in a linker script. Currently that fails since we try to find the
output section of symbol_in_obj. With this we should be able to just
return an InputSection from the expression.
llvm-svn: 297313
LLD is a multi-threaded program. errs() or outs() are not guaranteed
to be thread-safe (they are actually not).
LLD's message(), log() or error() are thread-safe. We should use them.
llvm-svn: 295787
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.
Differential revision: https://reviews.llvm.org/D29327
llvm-svn: 293757
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
Differential Revision: https://reviews.llvm.org/D29129
llvm-svn: 293283
The freebsd sbrk implementation uses _end to find the initial value of
brk, so it has to be defined in the main binary.
This should fix the emacs build.
llvm-svn: 292512
LLD exports symbols that are also present in used shared libraries to
make sure they are preempted at runtime. That is a reasonable default,
but we must allow for it to be overwritten with linker script. If we
don't, libraries that expect to be able to hide a c++ delete operator
will fail.
This should fix the firebird build.
llvm-svn: 292146
The freebsd dynamic linker doesn't check if the value is null (and it
is reasonable for it to do that). That means that producing a .so with
a null DT_INIT/DT_FINI causes the base address to be called.
This should fix the libreoffice build.
llvm-svn: 291944
This actually simplifies the code a bit as now all local symbols are
handled uniformly.
This should fix the build of www/webkit2-gtk3.
llvm-svn: 291569
In a shared library an undefined symbol is implicitly imported. If the
symbol is called as a function a PLT entry is generated for it. When the
caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT
entries are in ARM state.
This change allows undefined symbols to have thunks in the same way that
shared symbols may have thunks.
llvm-svn: 290951
Vectors returned form that function contained nullptrs or Undefined symbols.
This patch filter them out. This makes use of the function a bit easier.
llvm-svn: 290334
Previously, you had to call initDemangledSyms() before accessing DemangledSyms.
Now getDemangledSyms() initializes it and then returns it. So it is now less easy
to use it in a wrong way.
llvm-svn: 290323
DefinedSynthetic is not created for a real ELF object, so it doesn't
have to be a template function. It has a virtual st_value, which is
either 32 bit or 64 bit, but we can simply use 64 bit.
llvm-svn: 290241
I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.
Differential Revision: https://reviews.llvm.org/D27819
llvm-svn: 290062
We first decide that the symbol is global, than that it should have
version foo. Since it was already not the default version, we were
producing a bogus warning.
llvm-svn: 289284
The feature is documented as
-----------------------------
The format of the dynamic list is the same as the version node
without scope and node name. See *note VERSION:: for more
information.
--------------------------------
And indeed qt uses a dynamic list with an 'extern "C++"' in it. With
this patch we support that
The change to gc-sections-shared makes us match bfd. Just because we
kept bar doesn't mean it has to be in the dynamic symbol table.
The changes to invalid-dynamic-list.test and reproduce.s are because
of the new parser.
The changes to version-script.s are the only case where we change
behavior with regards to bfd, but I would like to see a mix of
--version-script and --dynamic-list used in the wild before
complicating the code.
llvm-svn: 289082
These MIPS specific symbols should be global because in general they can
have an arbitrary value. By default this value is a fixed offset from .got
section.
This patch adds more checks to the mips-gp-local.s test case but marks
it as XFAIL because LLD does not allow redefinition of absolute symbols
value by a linker script. This should be fixed by D27276.
Differential revision: https://reviews.llvm.org/D27524
llvm-svn: 289025
This is a fairly reasonable bfd extension since there is one obvious value.
dtrace depends on this feature as it creates multiple absolute
symbols with the same value.
llvm-svn: 288461
StringRefZ is a class to represent a null-terminated string. String
length is computed lazily, so it's more efficient than StringRef to
represent strings in string table.
The motivation of defining this new class is to merge functions
that only differ in string types; we have many constructors that takes
`const char *` or `StringRef`. With StringRefZ, we can merge them.
Differential Revision: https://reviews.llvm.org/D27037
llvm-svn: 288172
The function was used only within Relocations.cpp, but now we are
using it in many places, so this patch moves it to a file that fits
to the functionality.
llvm-svn: 287943
We have different functions to stringize objects to construct
error messages. For InputFile, we have getFilename, and for
InputSection, we have getName. You had to memorize them.
I think this is the case where the function overloading comes in handy.
This patch defines toString() functions that are overloaded for all these
types, so that you just call it in error().
Differential Revision: https://reviews.llvm.org/D27030
llvm-svn: 287787
There are two ways to set symbol versions. One way is to use symbol
definition file, and the other is to embed version names to symbol
names. In the latter way, symbol name is in the form of `foo@version1`
where `foo` is a real name and `version1` is a version.
We were parsing symbol names in insert(). That seems unnecessarily
too early. We can do it later after we resolve all symbols. Doing it
lazily is a good thing because it makes code easier to read
(because now we have a separate pass to parse symbol names). Also
it could slightly improve performance because if two identical symbols
have versions, we now parse them only once.
llvm-svn: 287741
We used to create a vector contantaining all version definitions
with wildcards because doing that was efficient. All patterns were
compiled to a regexp and matched against symbol names. Because
a regexp can be converted to a DFA, matching against union of patterns
is as cheap as matching against one patter.
We are no longer converting them to regexp. Our own glob pattern
handler doesn't do such optimization. Therefore, creating a vector
no longer makes sense.
llvm-svn: 287196
This change separates all versioned locals to be a separate list in config,
that was suggested by Rafael and simplifies the logic a bit.
Differential revision: https://reviews.llvm.org/D26754
llvm-svn: 287132
The code to handle symbol versions is getting tricky and hard to
understand, so it is probably time to simplify it. This patch does
the following.
- Add `DemangledSyms` variable to SymbolTable so that we don't
need to pass it around to findDemangled.
- Define `initDemangledSyms` to initialize the variable lazily.
- hasExternCpp is removed because we no longer have to initialize
the map eagerly.
- scanScriptVersion is split.
- Comments are updated.
llvm-svn: 287002
Patch adds a filename to that error message.
I faced next error when debugged one of FreeBSD port:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol __tls_get_addr
error message was poor and this patch improves it to show the locations
of symbol declaration and using.
Differential revision: https://reviews.llvm.org/D26508
llvm-svn: 286940
Previously we did not support anything except "local: *", patch changes that.
Actually GNU rules of proccessing wildcards are more complex than that (http://www.airs.com/blog/archives/300):
There are 2 iteration for wildcards, at first iteration "*" wildcards are ignored and handled at second iteration.
Since we previously decided not to implement such complex rules,
I suggest solution that is implemented in this patch. So for "local: *" case nothing changes,
but if we have wildcarded locals,
they are processed before wildcarded globals.
This should fix several FreeBSD ports, one of them is jpeg-turbo-1.5.1 and
currently blocks about 5k of ports.
Differential revision: https://reviews.llvm.org/D26395
llvm-svn: 286713
The change in D26502 splits ReaderWriter.h, which contains the APIs
into both the BitReader and BitWriter libraries, into BitcodeReader.h
and BitcodeWriter.h.
Change lld uses to the appropriate split header, removing it
completely in one case where it wasn't needed.
llvm-svn: 286568
The disadvantage is that we use uint64_t instad of uint32_t for some
value in 32 bit files. The advantage is a substantially simpler code,
faster builds and less code duplication.
llvm-svn: 286414
In short the patch introduces support for linking object file conform
MIPS N32 ABI [1]. This ABI is similar to N64 ABI but uses 32-bit
pointer size.
The most non-trivial requirement of this ABI is one more relocation
packing format. N64 ABI puts multiple relocation type into the single
relocation record. The N32 ABI uses series of successive relocations
with the same offset for this purpose. In this patch, new function
`mergeMipsN32RelTypes` handle this case and "convert" N32 relocation to
the N64 relocation so the rest of the code keep unchanged.
For now, linker does not support series of relocations applied to sections
without SHF_ALLOC bit. Probably later I will add the support or insert
some sort of assert into the `relocateNonAlloc` routine to catch this
case.
[1] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/MIPS-N32-ABI-Handbook.pdf
Differential revision: https://reviews.llvm.org/D26298
llvm-svn: 286052
Previously, it didn't support the character class, so we couldn't
eliminate the use fo llvm::Regex. Now that it is supported, we
can remove compileGlobPattern, which converts a glob pattern to
a regex.
This patch contains optimization for exact/prefix/suffix matches.
Differential Revision: https://reviews.llvm.org/D26284
llvm-svn: 285949
When we have SHT_GNU_versym section, it is should be associated with symbol table
section. Usually (and in out implementation) it is .dynsym.
In case when .dynsym is absent (due to broken object for example),
lld crashes in parseVerdefs() when accesses null pointer:
Versym = reinterpret_cast<const Elf_Versym *>(this->ELFObj.base() +
VersymSec->sh_offset) +
this->Symtab->sh_info;
DIfferential revision: https://reviews.llvm.org/D25553
llvm-svn: 285796
Previously, we have a lot of BumpPtrAllocators, but all these
allocators virtually have the same lifetime because they are
not freed until the linker finishes its job. This patch aggregates
them into a single allocator.
Differential revision: https://reviews.llvm.org/D26042
llvm-svn: 285452
We used to have one allocator per file, which reduces the advantage of
using an allocator in the first place.
This is a small speed up is most cases. The largest speedup was in
1.014X in chromium no-gc. The largest slowdown was scylla at 1.003X.
llvm-svn: 285205
Summary:
This uses one less word on 64-bit platforms, so should be a strict
improvement. This change also lets us get rid of llvm::CachedHash.
Reviewers: rafael, timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25646
llvm-svn: 284502
Previouly bot was failing:
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/413/steps/test-stage1-compiler/logs/stdio
Fixed possible segfault, so commit should bix the buildbot.
Initial commit message:
This is PR30312. Info from bug page:
Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.
Patch fixes that.
It uses testcase created by Ed Maste (D24306).
Differential revision: https://reviews.llvm.org/D24336
llvm-svn: 281605
Previously, all input files were owned by the symbol table.
Files were created at various places, such as the Driver, the lazy
symbols, or the bitcode compiler, and the ownership of new files
was transferred to the symbol table using std::unique_ptr.
All input files were then free'd when the symbol table is freed
which is on program exit.
I think we don't have to transfer ownership just to free all
instance at once on exit.
In this patch, all instances are automatically collected to a
vector and freed on exit. In this way, we no longer have to
use std::unique_ptr.
Differential Revision: https://reviews.llvm.org/D24493
llvm-svn: 281425
Something broked BBots:
281318 failed on step 9:
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/413
r281317 built step 9 green:
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/415
Initial revision commits were:
This is PR30312. Info from bug page:
Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.
Patch fixes that.
It uses testcase created by Ed Maste (D24306).
Differential revision: https://reviews.llvm.org/D24336
llvm-svn: 281411
This is PR30312. Info from bug page:
Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.
Patch fixes that.
It uses testcase created by Ed Maste (D24306).
Differential revision: https://reviews.llvm.org/D24336
llvm-svn: 281318
Implemented by building an ELF file in memory.
elf, default, and binary match gold behavior.
Differential Revision: https://reviews.llvm.org/D24060
llvm-svn: 281108
Fixed code that was not checked before on windows for me, because of testcases that are
disabled on that platform atm.
Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281049
Fixed code that was not checked by testcases that are disabled on windows.
Inital commit message:
"[ELF] - Versionscript: do not treat non-wildcarded names as wildcards."
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281045
Previously we incorrectly handled cases when symbol name in extern c++ tag
was enclosed in quotes. Next case was treated as wildcard:
GLIBCXX_3.4 {
extern "C++" {
"aaa*"
}
But it should have not. Quotes around aaa here means that we should have do exact
name matching.
That is PR30268 which has name with pointer is interpreted as wildcard by lld:
extern "C++" {
"operator delete[](void*)";
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D24229
llvm-svn: 281038
George Rimar