http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18
10:07:33 UTC ---
(In reply to comment #3)
> + if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
> + && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> + && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
> + || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
> + return NULL;
> +
Won't this cause problems with user-defined types with the same name?
Additionally, I would rather bring C_PTR/C_FUNPTR closer a normal derived type
(which is only in the last step treated specially) than to introduce hacks like
that.
The reason for the crash is that in gfc_interpret_derived the pointer component
of "c_ptr" ("__c_ptr_c_address") has no backend declaration (cmp->backend_decl
== NULL) - and thus "ptr = TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET
(cmp->backend_decl))" crashes. Maybe it is sufficient to set it via
gfc_typenode_for_spec in that function.
I think the advantage of fixing this part of the code is that one can simplify
the code at compile time - which is usually preferred to run-time evaluation.
