Le 06/04/2014 20:30, Tobias Burnus a écrit : > Mikael Morin wrote: >> Argh. great. What about the use_assoc thing? Why is that needed? > > Frankly, I don't know. In terms of the code, the problem is that > attr.use_assoc is zero and, hence, the compiler generates a call to some > external version which lacks the module name - that symbol is not found > and, unsurprisingly, there is a link-time failure (symbol reference not > found). > > However, I have a completely untested hypothesis: The derived type is > use associated (fact) when following sym->ts.u.derived to the vtab and > then further to vtab->_final one at some point does no longer access a > use associated variable but the one of the module. As it is used in the > module, it is not use associated and lacks that attribute. In that sense > it is wrong to set it in trans.c as my patch does. However, that section > of the code is only reached after the module generation has finished. > Hence, it is should be safe to modify the attribute. (If it had been > generated in the module, final_expr->...->sym->backend_decl would be set > and we could use it directly.) >
Unless I have messed up something on my side, the testcase seems to work here without the use_assoc change; could you double-check? The patch is ok if it works (without the trans.c part of course). Mikael