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
