u99127 edited a comment on pull request #6416: URL: https://github.com/apache/incubator-tvm/pull/6416#issuecomment-689179968
> > > @tom-gall @cbalint13 would be great if we can try the compiler-rt route :) > > > > Is it possible to use the compiler RT function instead? > > https://github.com/apache/incubator-tvm/blob/master/3rdparty/compiler-rt/builtin_fp16.h#L165 > > It would be useful to use this function so that the code itself is platform agnostic. > > Or even better, can use internal instead of `reinterpret_cast<__fp16*>` ? > > * Functions: https://github.com/apache/incubator-tvm/blob/master/src/runtime/builtin_fp16.cc > > * Example: https://github.com/apache/incubator-tvm/blob/master/src/relay/transforms/pattern_util.h#L252 > > > @tom-gall , > Cc @junrushao1994 , @tqchen > > If want i can make a separate PR with the proposed `reinterpret_cast<__fp16*>` replacement. > However `reinterpret_cast<__fp16*>` is more elegant indeed (if toolchains would agree with us too). I've spent some time analysing this bug today. The language feature works with static linking but not without it - so that smells of an issue in the toolchain in my book since I wouldn't expect something like reinterpret_cast to depend on linkage methods. I think I have a reproducer to discuss further with the relevant GCC folks in the morning. However, I've gone back and re-read the man page for --static-libgcc as this isn't something that I've used before and that has the following note which raised my eyebrows and probably needs some more querying. https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Link-Options.html#Link-Options "However, if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ driver, or using the option -shared-libgcc, such that it is linked with the shared libgcc." I'm also not convinced we can assert this is safe for all the API consumers of libtvm.so that exceptions wouldn't be received or thrown across the libtvm.so boundary ? On an offline conversation @junrushao1994 indicated that we may throw an exception across if someone were using a C++ API from libtvm.so in a C++ wrapper. I'm not sure about other usecases. Even if we did, I think it's risky to continue down the path of using --static-libgcc on one platform because you've got different behaviours on different hosts and we should look to avoid that for longer term maintenance. Thus I think we should look for a workaround till this is discussed with the GCC community more. I've not yet studied the compiler-rt one to say more - More later this week. regards Ramana ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
