Hi, >> Sorry, I don't understand the last sentence. Why should it call some >> "__free..." instead of "doit"? And why is that test case even affected >> by your patch (you said it would only work with explicit DEALLOCATE, >> which does not appear in that test case)? > > Yes, it is as I said... In > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986#c4 the doit() call > produces a segfault because r26 is 0 instead of the address of > __s_bar_mod_MOD_doit. With my patched version, the doit call is in > reality a _free __free_s_bar_mod_S_bar call.
huh, this is strange, indeed. I guess it means that something is messed up in the vtable (some sort of offset?). We try to call one virtual function, but we get another. Since this problem was already seen in PR43986, it is probably a case of your patch uncovering an existing bug. I'll try to look into this problem soon ... Cheers, Janus