http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-valid-code |ice-on-invalid-code
CC| |abensonca at gmail dot com
--- Comment #3 from janus at gcc dot gnu.org 2012-09-22 09:04:22 UTC ---
(In reply to comment #2)
> While it would be nontrivial to fully enforce these constraints by a runtime
> check, I think they might effectively mean that FPTR must not be polymorphic:
> In the second case this constraint is spelled out explicitly, and the first
> case demands that FPTR shall be interoperable. But polymorphic objects are by
> definition not interoperable.
Note that there are similar constraints on the argument of C_LOC, where we
completely reject any polymorphic entities (cf. PR 44925):
cSelf = c_loc (self)
1
Error: Parameter 'self' to 'c_loc' at (1) must not be polymorphic
I would conclude that this PR should actually be classified as ICE-on-invalid,
and we should reject the polymorphic argument to C_F_POINTER.
Andrew, have you tried your test case with any other compilers?
