Derived type cannot be declared with both PRIVATE and BIND(C) with gfortran

[clementval]

The following code is compilable with gfortran but not anymore once passed through the front-end and back-end.

MODULE mod1
  IMPLICIT NONE
  PRIVATE

  TYPE, BIND(c) :: t_rt
    INTEGER :: i
  END TYPE t_rt
END MODULE mod1

MODULE mod1
 TYPE , PRIVATE , BIND( C ) :: t_rt
 END TYPE t_rt
END MODULE mod1

  TYPE , PRIVATE , BIND( C ) :: t_rt
                                   1
Error: Derived type 't_rt' at (1) cannot be declared with both PRIVATE and BIND(C) attributes

This is specified in the Fortran standard at R427

[h-murai]

@clementval Do you mean that TYPE , PRIVATE , BIND( C ) :: t_rt should be accepted but gfortran doesn't due to its bug?

[clementval]

@h-murai
TYPE , PRIVATE , BIND( C ) :: t_rt is not accepted by gfortran so the only way to do it is like I did in the PR

PRIVATE :: t_rt
TYPE , BIND( C ) :: t_rt

If you look into the standard is not super clear but R427

R427 type-attr-spec is ABSTRACT
or access-spec
or BIND (C)
or EXTENDS ( parent-type-name )

[h-murai]

@clementval Hmm. According to R426:

R426 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name

a TYPE statement can have multiple type-attr-spec. So, I consider that TYPE , PRIVATE , BIND( C ) :: t_rt should be accepted.

[clementval]

Ok but then this is not compilable with gfortran

[clementval]

@h-murai should try with other compiler to check the behavior

[clementval]

@h-murai I tried with PGI and Cray and both are ok with this. Only gfortran does not like this construct.

[h-murai]

@clementval Ok. I understand the situation. Considering that gfortran is important, I agree the PR is a better solution to this issue.

[clementval]

@h-murai I’ll try to fill a bug report for gfortran and see what they reply. So like this it would be only a temporary fix

[clementval]

@h-murai I made the workaround in the backend at the moment so the XcodeML still reflect the correct standard.
The PR is #71

[clementval]

I filed a but report in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86587

[h-murai]

keep this issue as a reminder. The status of the gfortran's limitation should be checked in the future.