Improve LTO type checking during symtab merging

[Tobias Burnus]

Hi all,

Jan Hubicka wrote:
> actually I bootstrapped/regtested without fortran (as I frogot the setting from
> LTO bootstrap).  There are several new warnings in the fortran's testsuite.
> As far as I can tell, they represent real mismatches.  I wonder, do we want
> to fix the testcases (some fortran-fu would be needed), disable warnings on those
> or explicitely allow excess warnings (bcause we still have no way to match
> link-time warnings)?

See comments/solutions below. I wrote them bottom up. I think one can 
fix all of them as stated, but I am not 100% sure whether some of the 
cases explicitly should handle some mismatch - especially not regarding 
the last one. But at least the rest should be fixable as stated.

> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/20091028-1_0.f90:7:0: warning: type of 'int_gen_ti_header_c' does not match original declaration
> lto1: note: return value type mismatch
> lto1: note: type 'int' should match type 'void'
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/20091028-1_1.c:3:5: note: previously declared here

Here, one seemingly tries to ignore the return value of a function as it 
is commonly done under C – except that Fortran strictly divides between 
void-returning "subroutine"s and non-void-returning "function"s. Thus, 
one has to declare the function in that case as "subroutine" and cause a 
mismatch.
Assuming the test case doesn't test whether this is gracefully handled, 
the simplest would be to change the C function to return void - in 
particular as that this actually happens as there is no "return".

> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr40724_1.f:2:0: warning: type of 'f' does not match original declaration
> lto1: note: types have different parameter counts
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr40724_0.f:1:0: note: previously declared here

See next items.

> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr41069_1.f90:4:0: warning: type of 'mltfftsg' does not match original declaration
> lto1: note: types have different parameter counts
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr41069_1.f90:4:0: warning: type of 'mltfftsg' does not match original declaration
> lto1: note: types have different parameter counts
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr41069_0.f90:2:0: note: previously declared here

I would add an interface (cf. next items); however, I wonder whether any 
of those test cases relies on having no interface.

> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr41521_0.f90:7:0: warning: type of 'atom' does not match original declaration
> lto1: note: types have different parameter counts
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr41521_1.f90:1:0: note: previously declared here
Reason: see next item. Solution: Add to pr41521_0.f90:

interface
   subroutine atom(sol,k,eval)
     real, intent(in) :: sol
     integer, intent(in) :: k(2)
     real, intent(out) :: eval(2)
   end subroutine
end interface
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr41576_1.f90:4:0: error: type of 'foo' does not match original declaration [-Werror]
> lto1: note: types have different parameter counts
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr41576_0.f90:4:0: note: previously declared here
Here the problem is that gfortran doesn't know the interface of "foo" - 
and declares it as "foo(...)". What the FE should do is to generate the 
interface by the usage. [There is some PR for this.] For the test case, 
one can simply add in pr41576_1.f90 the following:

interface
   subroutine foo()
   end subroutine
end interface

> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr60635_0.f90:13:0: warning: type of 'bigendc16' does not match original declaration
> /usr/include/stdint.h:50:28: note: type 'uint16_t' should match type 'short int'
> /aux/hubicka/trunk-8/gcc/testsuite/gfortran.dg/lto/pr60635_1.c:6:10: note: previously declared here

The problem here is that the C side uses uint16_t; but Fortran doesn't 
have unsigned integers. If only the return value is the problem, I think 
one can simply cast it to "(int16_t)". But I don't know whether it then 
still tests the original issue (it probably does).

Tobias