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

["kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.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.