This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Improve LTO type checking during symtab merging


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]