[Bug fortran/102079] New: Misleading -Wlto-type-mismatch warning on wrong float type to C function

[Bug fortran/102079] New: Misleading -Wlto-type-mismatch warning on wrong float type to C function

[rimvydas.jas at gmail dot com]

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

            Bug ID: 102079
           Summary: Misleading -Wlto-type-mismatch warning on wrong float
                    type to C function
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

$ cat bar.c
#include <stddef.h>
void bar_ (char *cdname, /*float*/ double *pkey, char *cdfile, size_t
cdname_len, size_t cdfile_len) { };

$ cat foo.f90
program test
call foo('start','loo',13.)
end program

subroutine foo(cdname,cdfile,pkey)
implicit none
character(len=*) :: cdname,cdfile
real :: pkey
call bar(cdname,pkey,cdfile)
end subroutine

$ gcc -flto -c bar.c
$ gfortran -Wall -Wextra -flto foo.f90 bar.o
foo.f90:9:28: warning: type of 'bar' does not match original declaration
[-Wlto-type-mismatch]
    9 | call bar(cdname,pkey,cdfile)
      |                            ^
bar.c:2:6: note: type mismatch in parameter 4
    2 | void bar_ (char *cdname, /*float*/ double *pkey, char *cdfile, size_t
cdname_len, size_t cdfile_len) { };
      |      ^
bar.c:2:6: note: type 'size_t' should match type 'long int'
bar.c:2:6: note: 'bar_' was previously declared here
bar.c:2:6: note: code may be misoptimized unless '-fno-strict-aliasing' is used

Actual hard error is typo in bar.c for "float *pkey" 2nd argument and not a
first hidden argument for first character array length.

[Bug fortran/102079] Misleading -Wlto-type-mismatch warning on wrong float type to C function

[rimvydas.jas at gmail dot com]

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

--- Comment #1 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
On side note the gfortran -fc-prototypes-external do suggest (as documentation
for gfortran v8 and newer) to use size_t type for hidden character array
lengths that are passed by value instead of usual by reference. Could gfortran
frontend emit to use 'size_t' or even __SIZE_TYPE__ internal type so to avoid
inclusion of <stddef.h> ?

[Bug fortran/102079] Misleading -Wlto-type-mismatch warning on wrong float type to C function

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
           Keywords|                            |diagnostic, lto

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think LTO complains that the fortran frontend uses ssize_t but the C code
size_t for the hidden length argument.

I think the TBAA warning is bogus here since signed and unsigned long
inter-operate.  If the fortran frontend is suggesting size_t then it should
better
also use size_type_node for argument passing.

Honza, shouldn't we suppress the TBAA warning here?

[Bug fortran/102079] Misleading -Wlto-type-mismatch warning on wrong float type to C function

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I think the problem here is that fortran uses "long int" while size_t
interoperate with "unsigned long int".
Does fortran standard promise that the value should inter-operate with size_t
as well?

[Bug fortran/102079] Misleading -Wlto-type-mismatch warning on wrong float type to C function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-09-26
     Ever confirmed|0                           |1

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #3)
> I think the problem here is that fortran uses "long int" while size_t
> interoperate with "unsigned long int".
> Does fortran standard promise that the value should inter-operate with
> size_t as well?

This is a matter for the compiler.

In this case, the documentation states

For arguments of @code{CHARACTER} type, the character length is passed
as a hidden argument at the end of the argument list.  For
deferred-length strings, the value is passed by reference, otherwise
by value.  The character length has the C type @code{size_t} (or
@code{INTEGER(kind=C_SIZE_T)} in Fortran).

so the documentation is actually inconsistent (but then, interoperbility
between Fortran integers and C unsigned types is sort of assumed).
The library uses gfc_charlen_type, which is a typedef to size_t.

So, we can fix this either way.  It would probably be best to have
size_t in the character lengths in the front end as well.

[Bug fortran/102079] Misleading -Wlto-type-mismatch warning on wrong float type to C function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #4)
> (In reply to Jan Hubicka from comment #3)
> > I think the problem here is that fortran uses "long int" while size_t
> > interoperate with "unsigned long int".
> > Does fortran standard promise that the value should inter-operate with
> > size_t as well?
> 
> This is a matter for the compiler.
> 
> In this case, the documentation states
> 
> For arguments of @code{CHARACTER} type, the character length is passed
> as a hidden argument at the end of the argument list.  For
> deferred-length strings, the value is passed by reference, otherwise
> by value.  The character length has the C type @code{size_t} (or
> @code{INTEGER(kind=C_SIZE_T)} in Fortran).
> 
> so the documentation is actually inconsistent (but then, interoperbility
> between Fortran integers and C unsigned types is sort of assumed).
> The library uses gfc_charlen_type, which is a typedef to size_t.
> 
> So, we can fix this either way.  It would probably be best to have
> size_t in the character lengths in the front end as well.

The Fortran 2018 standard in section 18 specific discusses unsigned
integers.  Table 18.2 shows that CHARACTER(KIND=C_SIGNED_CHAR)
interoperates with with C's signed char or unsigned char.  It further
shows that C_SIZE_T is interoperates with C's size_t. The Fortran
standard does not have a C_SSIZE_T kind type parameter.  There is,
however, a non-normative note. From 18-007r1.pdf (aka Fortran 2021),
page 475

   NOTE 1

   ISO/IEC 9899:2011 specifies that the representations for nonnegative
   signed integers are the same as the corresponding values of unsigned
   integers.  Because Fortran does not provide direct support for unsigned
   kinds of integers, the ISO_C_BINDING module does not make accessible
   named constants for their kind type parameter values. A user can use
   the signed kinds of integers to interoperate with the unsigned types
   and all their qualified versions as well. This has the potentially
   surprising side effect that the C type unsigned char is interoperable
   with the type integer with a kind type parameter of C_SIGNED_CHAR.

Now, for the problem at hand, the hidden argument could be passed as
a c_ssize_t.  A Fortan string can never have a negative length. The
only thing that might be of a concern is breaking the libgfortran ABI,
and causing mixed-language programmers who do not use the features of
Section 18 some heartburn.

[Bug fortran/102079] Misleading -Wlto-type-mismatch warning on wrong float type to C function

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 26 Sep 2021, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
> 
> --- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> I think the problem here is that fortran uses "long int" while size_t
> interoperate with "unsigned long int".
> Does fortran standard promise that the value should inter-operate with size_t
> as well?

Note my point was that the TBAA warning is unnecessary since at least
singed and unsigned variants of the same type inter-operate in that
respect.  Can we fix that independently of the issue of
value inter-operation here?