http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-05 17:19:45 UTC --- Created attachment 22907 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22907 Draft patch - not fully working (In reply to comment #4) > Note: If both arguments are TYPE-valued, the result will be a compile-time > constant, otherwise it has to be evaluated at runtime, according to the _hash > values in the vtabs. Well, extends_type_of can also be (sometimes) be evaluated at compile time for CLASS. > In which situations would we actually gain something I assume that in practice it only matters for automatically generated code - but there it might reduce the code size and improve the performance. By the way: I think that's a 4.7 item. * * * I attached a draft patch. Note, however, that it does not work (cf. bottom of patch/test case). For if (extends_type_of(a11,b11) .neqv. .true.) call abort() one enters gfc_simplify_extends_type_of twice: Once the second argument (mold) is BT_CLASS (which give the correct result: NULL, i.e. not compile-time simplifiable). But then again with mold being BT_DERIVED - which is then compile-time simplified to .TRUE. as "a11" and "b11" are the same type. I have not dug into this, but it seems to occur in two steps - first a normal simplification happens, then a specific interface is used via gfc_intrinsic_func_interface, which is then again simplified - but with BT_DERIVED argument (base type). I think all gfc_simplify_* functions could be affected. TODO: - Fix the double-simplification problem - Add more test cases - I think the double-simplification also affects same_type, but it is currently not tested for.
