[flang] Add check for conflict of BIND(C) and Parameter attributes

[peixin]

Summary

The entity with BIND(C) attribute cannot be a named constant, so the
BIND(C) and parameter attributes are conflicted. Add check for it.

[klausler]

Are you checking constraint C818? That constraint lists four things that a BIND(C) item can be. It might be more effective to verify that a BIND(C) entity is one of those four things rather than trying to check that it is not any of the many other possibilities.

[peixin]

In D126654#3545969, @klausler wrote:

Are you checking constraint C818? That constraint lists four things that a BIND(C) item can be. It might be more effective to verify that a BIND(C) entity is one of those four things rather than trying to check that it is not any of the many other possibilities.

OK. Let me dig more to try to add checking for C818.

[peixin]

In D126654#3545969, @klausler wrote:

Are you checking constraint C818? That constraint lists four things that a BIND(C) item can be. It might be more effective to verify that a BIND(C) entity is one of those four things rather than trying to check that it is not any of the many other possibilities.

The BIND(C) can only be in type-declaration-stmt, bind-stmt, or proc-language-binding-spec. I think there is no need to check C818 since those does not satisfy C818 will fail in parser with the exception of named constant. Also the pointer and allocatable variables cannot have BIND(C) attribute.

The other semantic checks for bind-stmt and proc-language-binding-spec will be later work. The semantic checks for Section 8.5.5 should be done after this patch.

[peixin]

BTW, I checked the conflict of all the attributes in type-declaration-stmt for BIND(C). The parameter and allocatable attributes can be deduced to be conflicted with BIND(C). For pointer attribute, I don't find the restriction in the standard. gfortran and ifort report the errors.

[klausler]

In D126654#3547530, @peixin wrote:

BTW, I checked the conflict of all the attributes in type-declaration-stmt for BIND(C). The parameter and allocatable attributes can be deduced to be conflicted with BIND(C). For pointer attribute, I don't find the restriction in the standard. gfortran and ifort report the errors.

Pointers and allocatables are not allowed as components in derived types with BIND(C), but there's no such restriction on variables in the standard, and the interoperable descriptor has features to support both pointers and allocatables.

[peixin]

Pointers and allocatables are not allowed as components in derived types with BIND(C), but there's no such restriction on variables in the standard

BIND(C) is not allowed as components in derived types. This will fail in parser.

the interoperable descriptor has features to support both pointers and allocatables.

Thanks for letting me know this. I will go forward with that after going through the semantic analysis of interoperability.

[klausler]

In D126654#3547586, @peixin wrote:

Pointers and allocatables are not allowed as components in derived types with BIND(C), but there's no such restriction on variables in the standard

BIND(C) is not allowed as components in derived types. This will fail in parser.

I know, but that's not what I was addressing. BIND(C) is allowed on the derived type itself, and this has consequences of the semantics of the components.

[peixin]

Add more regression tests.

[peixin]

I know, but that's not what I was addressing. BIND(C) is allowed on the derived type itself, and this has consequences of the semantics of the components.

Oh. Sorry, I misunderstood. Got what you mean.

I checked all the cases for C818. The entity does not satify C818 fails in parser or the semantic checks have been supported before. It seems the named constant is the only exception. Maybe I miss something? The named constant is kind of like special case, such as its usage in common block, function result, or with the bind(c) attribute. The standard usually does not decribe it on purpose. Instead, the standard usually states "a variable" to exclude the named constant. I think these checks are missed since the named constant and variable both have ObjectEntity detail, but they are different. Maybe there are still somewhere missing this check.

flang/lib/Semantics/resolve-names.cpp

 // C759, C1543
 bool AttrsVisitor::IsConflictingAttr(Attr attrName) {
   return HaveAttrConflict(attrName, Attr::INTENT_IN, Attr::INTENT_INOUT) ||
       HaveAttrConflict(attrName, Attr::INTENT_IN, Attr::INTENT_OUT) ||
       HaveAttrConflict(attrName, Attr::INTENT_INOUT, Attr::INTENT_OUT) ||
       HaveAttrConflict(attrName, Attr::PASS, Attr::NOPASS) || // C781
       HaveAttrConflict(attrName, Attr::PURE, Attr::IMPURE) ||
       HaveAttrConflict(attrName, Attr::PUBLIC, Attr::PRIVATE) ||
-      HaveAttrConflict(attrName, Attr::RECURSIVE, Attr::NON_RECURSIVE);
+      HaveAttrConflict(attrName, Attr::RECURSIVE, Attr::NON_RECURSIVE) ||
+      HaveAttrConflict(attrName, Attr::PARAMETER, Attr::BIND_C);
 }
 bool AttrsVisitor::CheckAndSet(Attr attrName) {
   CHECK(attrs_);
   if (IsConflictingAttr(attrName) || IsDuplicateAttr(attrName)) {
     return false;
   }
   attrs_->set(attrName);
   return true;

flang/test/Semantics/resolve114.f90

+! RUN: %python %S/test_errors.py %s %flang_fc1
+
+! Check the conflict attributes
+
+module m
+
+  !ERROR: Attributes 'PARAMETER' and 'BIND(C)' conflict with each other
+  integer, parameter, bind(c, name="a") :: x1 = 1
+  !ERROR: Attributes 'PARAMETER' and 'BIND(C)' conflict with each other
+  integer, bind(c), parameter :: x2 = 1
+
+end module m