[Bug fortran/114438] New: Missed constraint F2023:c7108

[Bug fortran/114438] New: Missed constraint F2023:c7108

[kargl at gcc dot gnu.org]

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

            Bug ID: 114438
           Summary: Missed constraint F2023:c7108
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57785&action=edit
Fortran 2023:C7108 violation

Gfortran does not diagnosis F2023:C7108.

  C7108 (R756) If derived-type-spec is a type name that is the same as a
generic
  name, the component-spec-list shall not be a valid actual-arg-spec-list for a
  function reference that is resolvable as a generic reference to that name
(15.5.5.2).

The attached program compiles and execute where the generic function is 
resolved to a function.

[Bug fortran/114438] Missed constraint F2023:c7108

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/114438] Missed constraint F2023:c7108

[anlauf at gcc dot gnu.org]

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Can you be a little more explicit?

If I extend the program as follows:

    type(params) :: p
    p = params( 0.1, 2.0 )
    write(*,*) p
    p = params( 0.1, 2 )
    write(*,*) p

I get with all compilers I have access to (Intel, NAG, Nvidia, flang, gfortran)

 Not the structure constructor
  0.100000001       4.00000000    
  0.100000001       2.00000000    

This is what I would have naively expected in accordance with "Note 1":

  The form ’name(...)’ is interpreted as a generic function-reference if
  possible; it is interpreted as a structure-constructor only if it cannot
  be interpreted as a generic function-reference.

which gives a precedence to function-reference over structure-constructor,
making it possible to override the default constructor.

Are you saying that one cannot override the default constructor?

[Bug fortran/114438] Missed constraint F2023:c7108

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Can you be a little more explicit?
> 
> If I extend the program as follows:
> 
>     type(params) :: p
>     p = params( 0.1, 2.0 )
>     write(*,*) p
>     p = params( 0.1, 2 )
>     write(*,*) p
> 
> I get with all compilers I have access to (Intel, NAG, Nvidia, flang,
> gfortran)
> 
>  Not the structure constructor
>   0.100000001       4.00000000    
>   0.100000001       2.00000000    
> 
> This is what I would have naively expected in accordance with "Note 1":
> 
>   The form ’name(...)’ is interpreted as a generic function-reference if
>   possible; it is interpreted as a structure-constructor only if it cannot
>   be interpreted as a generic function-reference.
> 
> which gives a precedence to function-reference over structure-constructor,
> making it possible to override the default constructor.
> 
> Are you saying that one cannot override the default constructor?


I thought C7108 was clear.

  C7108 (R756) If derived-type-spec is a type name that is the same as a
generic
  name, the component-spec-list shall not be a valid actual-arg-spec-list for a
  function reference that is resolvable as a generic reference to that name
(15.5.5.2).

The derived-type-spec is 'params'.

The generic name is 'params'.

The component-spec-list for the derived type in 'p = params(3.0,2.0)'
has types of 'real' and 'real'.

The generic reference is 'p = params(3.0,2.0)', which resolves to
'default_params'.

'default_params' has an actual-arg-spec-list with types of 'real' and 'real'.

Thus, 'params(real,real)' is ambiguous.  Is it the structure constructor
or a generic function reference?

Note, you cannot use keywords as the components of the derive
type 'params' are 'x' and 'y', and the dummy arguments for 
'default_params' are also 'x' and 'y'.

Finally, 'p = params(3,2.0)' is a structure constructor, because the
generic interface does not include a function with types of 'integer'
and 'real'.  Thus, here, this is not a function reference.  It must
be a structure constructor.  The rules of intrinsic assignment are
now in play, and 'params(3,2.0)' is treated as 'params(3.0,2.0)' 
after type conversion.

Of course, I could be wrong.

[Bug fortran/114438] Missed constraint F2023:c7108

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
The same text existed in F2018, so it is not new: F2018:C7103 and Note 1.

Either every compiler developer team misunderstood that clause, or we
need an interp, based on the example, to be able to convince all of them.

(I know of developers who do overwrite default constructors, and it currently
works "everywhere", so clarification is important.)

What do you think?

[Bug fortran/114438] Missed constraint F2023:c7108

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> The same text existed in F2018, so it is not new: F2018:C7103 and Note 1.
> 
> Either every compiler developer team misunderstood that clause, or we
> need an interp, based on the example, to be able to convince all of them.
> 
> (I know of developers who do overwrite default constructors, and it currently
> works "everywhere", so clarification is important.)
> 
> What do you think?

I don't have other compilers to check, but I think my
interpretation of F2023:C7108 was intended to prevent
ambiguity.

Note, F2003:C489 is nearly verbatim with F2023:c7108.
So, this goes back years as a constraint.

I forgot to mention that I found this at 

https://fortran-lang.discourse.group/t/type-mismatch-in-literal-constant-constructor-for-derived-type-allowed/7669

[Bug fortran/114438] Missed constraint F2023:c7108

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> The same text existed in F2018, so it is not new: F2018:C7103 and Note 1.
> 
> Either every compiler developer team misunderstood that clause, or we
> need an interp, based on the example, to be able to convince all of them.
> 
> (I know of developers who do overwrite default constructors, and it currently
> works "everywhere", so clarification is important.)
> 
> What do you think?

I sent an email to the J3 mailing list

https://mailman.j3-fortran.org/pipermail/j3/2024-March/014649.html

I included a question whether keywords can be used.

[Bug fortran/114438] Missed constraint F2023:c7108

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> (In reply to anlauf from comment #3)
> > The same text existed in F2018, so it is not new: F2018:C7103 and Note 1.
> > 
> > Either every compiler developer team misunderstood that clause, or we
> > need an interp, based on the example, to be able to convince all of them.
> > 
> > (I know of developers who do overwrite default constructors, and it currently
> > works "everywhere", so clarification is important.)
> > 
> > What do you think?
> 
> I sent an email to the J3 mailing list
> 
> https://mailman.j3-fortran.org/pipermail/j3/2024-March/014649.html
> 
> I included a question whether keywords can be used.

See mailing list for response.  gfortran's current behavior
appears corrects with the possible exception that gfortran
does not detect and report the violation of a numbered
constraint.  Perhaps, a warning should be emitted under
-Wall or -Wsurprising.