"internal error: bad pointer" from ICC in rpc with auto argument and C++14

[Dan Bonachea]

Test program, from the TaskTorrent group:

#include <upcxx/upcxx.hpp>
#include <functional>
#include <tuple>

template<typename T, typename ... Ps>
struct AM {
    upcxx::dist_object<std::function<T*(Ps&...)>> fun_ptr;
    void send(int dest, Ps &... ps) {
        auto payload = std::make_tuple(ps...);
        // Changing auto to std::tuple<Ps...> or decltype(payload) makes the "bug" (?) disapear
        upcxx::rpc_ff(dest, [](upcxx::dist_object<std::function<T*(Ps&...)>> &lfun_ptr, const auto &lps)
        {
            // Nothing
        }, this->fun_ptr, payload);
    }
};
int main() {
    upcxx::init();
    int i = 0;
    char c = 's';
    std::function<char*(int&)> fun = [&](int& i){
        return &c;
    };

    AM<char,int> am {fun};
    am.send(1, i);

    while(true) {
        upcxx::progress();
    }
    upcxx::finalize();
}

Compiles fine using -std=c++14 (required by the auto lambda param) with gcc 10.2 or clang 11.0, but fails with ICC 2020.2.254:

/usr/local/pkg/upcxx-dirac/intel-2020.2.254/stable-2020.10.0/upcxx.debug.gasnet_seq.smp/include/upcxx/rpc.hpp(23): internal error: bad pointer
            std::declval<typename binding<Fn>::off_wire_type>()(

Smells like an Intel bug, possibly one we can workaround?

[Paul Hargrove]

With the 2021.1.2 release of the Intel compilers, this issue appears to be resolved (I have tested both develop and the 2020.10.0 release).

I am not closing the bug, pending an investigation into the possibility that a simple work-around can be formulated for older compilers as suggested at the very end of the original report.

[Amir Kamil]

I’ve spent several hours hacking at this unsuccessfully. I’ve tried 4-5 different alternatives (none of which have been all that simple), and all I’ve been able to accomplish is to move the bad-pointer error elsewhere. I’m ready to declare defeat.

[Paul Hargrove]

Thanks, @Amir Kamil, for the efforts to find a work around for older Intel compilers.

Since the newer compilers from Intel lack this bug, and are free, I see no motivation for us to spend additional effort on this issue.

[Paul Hargrove]

As noted previously, this does not impact the vendor's latest compilers and a reasonable effort to work-around the problem on older ones was unsuccessful.