[Bug fortran/114188] New: Overloading assignment does not invalidate intrinsic assignment

[Bug fortran/114188] New: Overloading assignment does not invalidate intrinsic assignment

[Bader at lrz dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188

            Bug ID: 114188
           Summary: Overloading assignment does not invalidate intrinsic
                    assignment
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 57583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57583&action=edit
test case for invalid use of assignment overloading

The attached reproducer overloads the assignment operator with a version that
requires the left hand side to be a pointer.

The overload conforms to the requirements for defining the assignment according
to 10.2.1.4 of the Fortran standard. Therefore, the intrinsic assignment should
become unavailable (last sentence of 10.2.1.1).

However, gfortran accepts invocations that use nonpointer arguments.

(NAG Fortran, Intel Fortran and NVidia Fortran issue appropriate error
messages).

[Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Bader@lrz.de from comment #0)
> Created attachment 57583 [details]
> test case for invalid use of assignment overloading
> 
> The attached reproducer overloads the assignment operator with a version
> that requires the left hand side to be a pointer.
> 
> The overload conforms to the requirements for defining the assignment
> according to 10.2.1.4 of the Fortran standard. Therefore, the intrinsic
> assignment should become unavailable (last sentence of 10.2.1.1).
> 
> However, gfortran accepts invocations that use nonpointer arguments.
> 
> (NAG Fortran, Intel Fortran and NVidia Fortran issue appropriate error
> messages).

Can you provide a bit more detail in your interpretation of F2023?

The last sentence in 10.2.1.1 is 

   1 An assignment-stmt shall meet the requirements of either a defined
     assignment statement or an intrinsic assignment statement.

If I comment out your 'interface assignment(=)' block, then 'b = a'
is an intrinsic assignment.  If I replace 'b = a' with the direct
call to 'ass', I see

a.f90:26:12:

   26 |    call ass(b, a)
      |            1
Error: Actual argument for ‘to’ at (1) must be a pointer or a valid
target for the dummy pointer in a pointer assignment statement

which seems to be the error that you want.  The question is then
if the source of this error can be interpreted such that 'b = a' in
your original code is in fact not a defined assignment, and therefore,
it is an intrinsic assignment (last sentence in 10.2.1.1).

10.2.1.5 has

  1 The interpretation of a defined assignment is provided by the subroutine
    that defines it.

and the NOTE in this section contains 

   The rules of defined assignment (15.4.3.4.3), ...

15.4.3.4.3 goes into some detail about argument association.  These rules
seem to be the source of the above error when 'ass' is called directed.
Unfortunately, the five requirements in 10.2.1.4 for defined assignment
do not say anything about argument association.

[Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment

[Bader at lrz dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188

--- Comment #2 from Bader at lrz dot de <Bader at lrz dot de> ---
You note that

> Unfortunately, the five requirements in 10.2.1.4 for defined assignment
> do not say anything about argument association.

Hmm, one could see this as "intentionally" instead of "unfortunately": If
the requirements in 10.2.1.4 are fulfilled, then a defined assignment exists.

The consequences are:

(1) the intrinsic assignment becomes unavailable (because the last sentence in 
    10.2.1.1 establishes a mutual exclusion).

(2) Any further details on how the subroutine is set up must be appropriately
    handled by the programmer (e.g., supplying POINTER objects in my example's
    LHS) - this is what is meant by "The interpretation of a defined assignment
is
    provided by the subroutine that defines it". The NOTE appearing later
    to me does not seem germane to the question at hand.

While my starting assumption may be wrong, the other compilers' behaviour is 
consistent with it.

Cheers
Reinhold

[Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4
   Last reconfirmed|                            |2024-03-01
           Keywords|                            |accepts-invalid, wrong-code
     Ever confirmed|0                           |1

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Bader@lrz.de from comment #2)
> You note that
> 
> > Unfortunately, the five requirements in 10.2.1.4 for defined assignment
> > do not say anything about argument association.
> 
> Hmm, one could see this as "intentionally" instead of "unfortunately": If
> the requirements in 10.2.1.4 are fulfilled, then a defined assignment exists.
>>   
> The consequences are:
> 
> (1) the intrinsic assignment becomes unavailable (because the last sentence
> in 
>     10.2.1.1 establishes a mutual exclusion).
> 
> (2) Any further details on how the subroutine is set up must be appropriately
>     handled by the programmer (e.g., supplying POINTER objects in my
> example's
>     LHS) - this is what is meant by "The interpretation of a defined
> assignment is
>     provided by the subroutine that defines it". The NOTE appearing later
   to me does not seem germane to the question at hand.
> 
> While my starting assumption may be wrong, the other compilers' behaviour is 
> consistent with it.
> 

I wasn't assuming that you were wrong and I've read enough of
your posts in J3 mailing list to trust your interpretation.
You've confirmed a few of my suspicions on how you were reading
the standard.  Hopefully, the clarity will help whomever jumps
down the rabbit hole to fix the bug.

[Bug fortran/114188] Overloading assignment does not invalidate intrinsic assignment

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114188

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Bader@lrz.de from comment #0)
> (NAG Fortran, Intel Fortran and NVidia Fortran issue appropriate error
> messages).

NVidia has a different issue: if one imports only the type declaration via

  use mod_supp, only : supp

all compilers should more or less compile the code, but that brand gives:

NVFORTRAN-S-0188-Argument number 1 (non-POINTER) to ass: type mismatch
(pr114188.f90: 22)
NVFORTRAN-S-0188-Argument number 1 (non-POINTER) to ass: type mismatch
(pr114188.f90: 23)

i.e. it uses the (unavailable) defined assignment although it shouldn't...