[Bug c/98945] New: gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)

[Bug c/98945] New: gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)

[rogi at skylittlesystem dot org]

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

            Bug ID: 98945
           Summary: gcc does not warn when assigning value of type int
                    (*)() to variable of type int (*)(double)
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rogi at skylittlesystem dot org
  Target Milestone: ---

gcc complains about assigning a value of type `int (*)()` to a variable of type
`int (*)(float)`, but not for a variable of type `int (*)(double)`, which I
thought to be a minor bug.

First observed on version 9.3.0, and also after updating 10.2.1, both give the
same result.

Here's a small test case:

```
$ gcc -O0 -Wall -o a.out -xc - <<EOF
int f()
{
        return 0;
}

int main()
{
        int (*p_float)(float f) = f;
        int (*p_double)(double d) = f;
        return 0;
}
EOF
<stdin>: In function 'main':
<stdin>:8:35: warning: initialization of 'int (*)(float)' from incompatible
pointer type 'int (*)()' [-Wincompatible-pointer-types]
<stdin>:9:15: warning: unused variable 'p_double' [-Wunused-variable]
<stdin>:8:15: warning: unused variable 'p_float' [-Wunused-variable]
```

thanks <3

[Bug c/98945] gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=97882
     Ever confirmed|0                           |1
           Keywords|                            |diagnostic
                 CC|                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-02-03

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed.  It's somewhat related to pr97882 in that the warning depends on the
result of comp_target_types() which considers int (*)(double) compatible with
int(*)() but int (*)(float) incompatible.  The warning is issued in
convert_for_assignment().

Interestingly, on Godbolt, both Clang and ICC behave just like GCC.  Only MSVC
warns for both assignments.

[Bug c/98945] gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Guess it's from unprototyped function times where float would be promoted to
double.

[Bug c/98945] gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The relevant rule in ISO C is 6.7.6.3#15 (in C17): "For two function types 
to be compatible ... If one type has a parameter type list and the other 
type is specified by a function declarator that is not part of a function 
definition and that contains an empty identifier list, ... the type of 
each parameter shall be compatible with the type that results from the 
application of the default argument promotions".  Thus, a declaration with 
a float argument is incompatible with an unprototyped declaration.

*However* I see that when I implemented N2432 (removal of old-style 
function definitions) for C2x mode, I missed that that paper also removed 
that rule (keeping only the rule that an unprototyped declaration is 
incompatible with a variadic prototype).  It's not obvious to me that such 
a change was intentional and it doesn't appear to have been discussed (it 
wasn't the main point of that paper), and it's still the case that you 
can't actually call a function with (float) prototype if only an 
unprototyped declaration is in scope, without undefined behavior; I'll 
raise that question on the WG14 reflector.