[llvm] r228557 - [Orc] Add a JITSymbol class to the Orc APIs, refactor APIs, update clients.
lhames at gmail.com
Sun Feb 8 23:21:09 PST 2015
Thanks. I'm digging through GCC bug reports at the moment. Best guess is
that it's the 'this' pointer in the capture - I should have a fix soon.
On Sun, Feb 8, 2015 at 11:01 PM, Tobias Grosser <tobias at grosser.es> wrote:
> On 09.02.2015 02:20, Lang Hames wrote:
>> Author: lhames
>> Date: Sun Feb 8 19:20:51 2015
>> New Revision: 228557
>> URL: http://llvm.org/viewvc/llvm-project?rev=228557&view=rev
>> [Orc] Add a JITSymbol class to the Orc APIs, refactor APIs, update
>> This patch refactors a key piece of the Orc APIs: It removes the
>> *::getSymbolAddress and *::lookupSymbolAddressIn methods, which returned
>> addresses (uint64_ts), and replaces them with *::findSymbol and
>> respectively, which return instances of the new JITSymbol type. Unlike
>> the old
>> methods, calling findSymbol or findSymbolIn does not cause the symbol to
>> immediately materialized when found. Instead, the symbol will be
>> if/when the getAddress method is called on the returned JITSymbol. This
>> us to query for the existence of symbols without actually materializing
>> them. In
>> the future I expect more information to be attached to the JITSymbol
>> class, for
>> example whether the returned symbol is a weak or strong definition. This
>> allow us to properly handle weak symbols and multiple definitions.
> This patch triggered a gcc (4.7.2) compiler bug for me:
> lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp: In lambda function:
> lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:125:1: internal compiler
> error: in get_expr_operands, at tree-ssa-operands.c:1035
> Please submit a full bug report,
> with preprocessed source if appropriate.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits