<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 1:32 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Aug 3, 2015 at 4:28 PM, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
> Aaron - I think the API design could be improved, but that's something that<br>
> we will need discussion before we change it.<br>
<br>
</span>Oh, most definitely agreed that discussion is required. :-D<br>
<span class=""><br>
><br>
> Dave - Yeah, this is gross, but I'm pretty sure you're right on both counts:<br>
> Technically UB, but expected to behave as intended. I'm very open to<br>
> changing this if we can come up with something saner.<br>
<br>
</span>uintptr_t ptr_val = reinterpret_cast<uintptr_t>(&localTestFunc);<br>
LLVMAddGlobalMapping(Engine, MappedFn, reinterpret_cast<void *>(ptr_val));<br>
<br>
I *think* this skirts around the UB, and should still optimize reasonably.<br></blockquote><div><br>Yep, this, to the best of my knowledge, is fine (& you don't need the intermediate variable if you don't want to, just to be clear - you can just reinterpret_cast<void*>(reinterpret_cast<uintptr_t>(&localTestFunc)))<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Cheers,<br>
> Lang.<br>
><br>
><br>
> On Mon, Aug 3, 2015 at 11:36 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, Aug 3, 2015 at 2:25 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Mon, Aug 3, 2015 at 11:03 AM, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Author: lhames<br>
>> >> Date: Mon Aug  3 13:03:40 2015<br>
>> >> New Revision: 243891<br>
>> >><br>
>> >> URL: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D243891-26view-3Drev&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=k9xpLHrEQBOmrhTp-sqZiTPTHrXOF_uWmy9WLR39yj0&s=cjF_fuxogMuIoK_O1Ksy2LE8EWISp7K6N56lFWdpbXE&e=" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=243891&view=rev</a><br>
>> >> Log:<br>
>> >> [MCJIT] Fix a cast warning in the unit-test introduced in r243589.<br>
>> >><br>
>> >> Thanks to Aaron Ballman for spotting this.<br>
>> >><br>
>> >> Modified:<br>
>> >>     llvm/trunk/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp<br>
>> >><br>
>> >> Modified: llvm/trunk/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp<br>
>> >> URL:<br>
>> >><br>
>> >> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_llvm_trunk_unittests_ExecutionEngine_MCJIT_MCJITCAPITest.cpp-3Frev-3D243891-26r1-3D243890-26r2-3D243891-26view-3Ddiff&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=k9xpLHrEQBOmrhTp-sqZiTPTHrXOF_uWmy9WLR39yj0&s=_XJuL9Gdcf5d3N6nyEgrZiCrTfprY9W1ljtLHbIHQZA&e=" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp?rev=243891&r1=243890&r2=243891&view=diff</a><br>
>> >><br>
>> >><br>
>> >> ==============================================================================<br>
>> >> --- llvm/trunk/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp<br>
>> >> (original)<br>
>> >> +++ llvm/trunk/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp Mon<br>
>> >> Aug<br>
>> >> 3 13:03:40 2015<br>
>> >> @@ -514,7 +514,13 @@ TEST_F(MCJITCAPITest, addGlobalMapping)<br>
>> >>    buildMCJITOptions();<br>
>> >>    buildMCJITEngine();<br>
>> >><br>
>> >> -  LLVMAddGlobalMapping(Engine, MappedFn,<br>
>> >> reinterpret_cast<void*>(&localTestFunc));<br>
>> >> +  union {<br>
>> >> +    int (*raw)();<br>
>> >> +    void *usable;<br>
>> >> +  } functionPointer;<br>
>> >> +  functionPointer.raw = &localTestFunc;<br>
>> ><br>
>> ><br>
>> > This is actually UB, but I think it's somewhere in the UB subset that<br>
>> > LLVM<br>
>> > intentionally preserves the expected behavior of (& I'm not sure if we<br>
>> > rely<br>
>> > on this in other parts of LLVM/assume that all compilers used to build<br>
>> > LLVM<br>
>> > support this behavior).<br>
>><br>
>> I don't think we should rely on it when alternatives exist that aren't<br>
>> UB, such as use of intptr_t and static_assert. I think the API for<br>
>> LLVMAddGlobalMapping() is broken if it's requiring a function pointer<br>
>> to be convertible to void * (note, I know nothing of<br>
>> LLVMAddGlobalMappings, so I may also be off-base)...<br>
>><br>
>> ~Aaron<br>
>><br>
>> ><br>
>> >><br>
>> >> +<br>
>> >> +  LLVMAddGlobalMapping(Engine, MappedFn, functionPointer.usable);<br>
>> >><br>
>> >>    buildAndRunPasses();<br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> llvm-commits mailing list<br>
>> >> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > llvm-commits mailing list<br>
>> > <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>