Optimizations should not add any pointer cast problems, so we don't have a
set of flags to remove the problems. It is possible that it is a bug in
Emscripten compiler, in which case reducing it down to a small test case
can help. Alternatively the code has a bug that it e.g. smashes a vtable or
similar, and ends up calling a bogus pointer; or the code depends on the
relaxed native x86 ABI where certain types of function pointer casts are ok
even though the C standard considers them undefined behavior. Emscripten
follows the C standard more strictly in this aspect compared to native.

2015-09-02 10:54 GMT+03:00 Dmitry Grechka <[email protected]>:

> But why I get this problem even with EMULATE_FUNCTION_POINTER_CASTS=1 and
> ALIASING_FUNCTION_POINTERS=0?
>
> What optimization should I disable (or what set of options should I
> enable) to avoid all these pointer casts problems?
>
>
>
> On Monday, 31 August 2015 18:55:25 UTC+3, Alon Zakai wrote:
>>
>> This can mostly be detected only at runtime. As the error message
>> indicates, the two main causes are deferencing a null pointer and casting
>> the type of a function pointer to something wrong before calling it. For
>> the latter, while we could in theory note at compile time all casts of
>> function pointer types, LLVM inserts a lot of such casts that are actually
>> ok, but would seem as dangerous as a truly incorrect cast. But clang can
>> warn about some specifically dangerous types of casts, which as mentioned
>> in the message can be turned on with -Werror.
>>
>>
>> On Mon, Aug 31, 2015 at 8:47 AM, Dmitry Grechka <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> I run the emscripten compiled code (with -Werror -g3 -s
>>> EMULATE_FUNCTION_POINTER_CASTS=1 -s DEMANGLE_SUPPORT=1 -s ASSERTIONS=2) and
>>> get
>>>
>>> Invalid function pointer '0' called with signature 'vii'. Perhaps this
>>> is an invalid value (e.g. caused by calling a virtual method on a NULL
>>> pointer)? Or calling a function with an incorrect type, which will fail?
>>> (it is worth building your source files with -Werror (warnings are errors),
>>> as warnings can indicate undefined behavior which can cause this)
>>> Z3shell.js:160:7
>>> This pointer might make sense in another type signature: vi: 0  viid: 0
>>> viii: 0  v: 0  viiii: 0  viiiii: 0  viiiid: 0  viiiiii: 0  viiiiiii: 0
>>> viiiiiiii: 0  viiiiiiiii: 0  viiiiiiiiii: 0  viiiiiiiiiii: 0
>>> viiiiiiiiiiii: 0  viiiiiiiiiiiii: 0  viiiiiiiiiiiiiii: 0  ii: 0  iii: 0
>>> dii: 0  iid: 0  i: 0  id: 0  iiii: 0  diid: 0  diii: 0  diiid: 0  iiiid: 0
>>> iiiii: 0  iiiiii: 0  iiiiid: 0  iiiiiid: 0  iiiiiii: 0  iiiiiiii: 0
>>> iiiiiiiii: 0  iiiiiiiiii: 0  iiiiiiiiiiii: 0  iiiiiiiiiiiiii: 0
>>>
>>> uncaught exception: *abort(0)* at jsStackTrace@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:1187:13
>>> stackTrace@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:1204:22
>>> *abort*@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:8918328:44
>>> *nullFunc*_vii@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:6586:1993
>>> *b20809*@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:8599707:2
>>> __ZN3smt7context11relevant_ehEP4expr [smt::context::relevant_eh(expr*)]@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:2341531:2
>>> __ZN3smt24relevancy_propagator_imp16mark_as_relevantEP4expr
>>> [smt::relevancy_propagator_imp::mark_as_relevant(expr*)]@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:2324332:5
>>> __ZN3smt24relevancy_propagator_imp21propagate_relevant_orEP3app
>>> [smt::relevancy_propagator_imp::propagate_relevant_or(app*)]@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:2473876:4
>>> __ZN3smt15or_relevancy_ehclERNS_20relevancy_propagatorE
>>> [smt::or_relevancy_eh::operator()(smt::relevancy_propagator&)]@
>>> https://home.dgrechka.net/z3/static_srinked_g3o3alGrowthDemangle/Z3shell.js:3240091:2
>>>
>>>
>>> As I understand this looks like a function pointer issue.
>>>
>>> Is there any way to get these kind of messages at compile time?
>>>
>>> Regards,
>>> Dmitry.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to