[Bug fortran/40011] Problems with -fwhole-file

[Bug fortran/40011] Problems with -fwhole-file

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
Bug 40011 depends on bug 33097, which changed state.

Bug 33097 Summary: Function decl trees without proper argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

[Bug fortran/40011] New: Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

Summary of the problems with -fwhole-file I have found so far.

>From http://gcc.gnu.org/ml/fortran/2009-03/msg00310.html:

--------------------------------------------------------------------------------

(1) From a first look the several "Segmentation fault" are coming from 
recursive functions, the simplest code being the following:

[ibook-dhum] f90/bug% cat recurs_test_1.f90

! { dg-do compile }
      RECURSIVE FUNCTION eval_args(q)  result (r)
      INTEGER NNODE 
      PARAMETER (NNODE  = 10) 

      TYPE NODE 
       SEQUENCE 
           INTEGER car 
           INTEGER cdr 
      END TYPE NODE 
      TYPE(NODE) heap(NNODE) 

      INTEGER r, q 
           r = eval_args(heap(q)%cdr) 
      END FUNCTION eval_args 

[ibook-dhum] f90/bug% gfc -c -fwhole-file recurs_test_1.f90
gfc: Internal error: Segmentation fault (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

--------------------------------------------------------------------------------

(2) I have also an ICE (already reported in PR26227 
http://gcc.gnu.org/ml/gcc-bugs/2009-03/msg02321.html) for 

[ibook-dhum] f90/bug% cat arr_fun.f90

function test(n)
real, dimension(2) :: test
integer            :: n
test = n
! print *, test
return
end function test
program arr
real, dimension(2) :: res
res = test(2)
print *, res
end program

[ibook-dhum] f90/bug% gfc -fwhole-file arr_fun.f90
arr_fun.f90: In function 'arr':
arr_fun.f90:8: internal compiler error: in fold_convert, at fold-const.c:2547
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

--------------------------------------------------------------------------------

(3) And I think the following are false positives:

[ibook-dhum] f90/bug% cat specifics_red_4.f90

subroutine test_d(fn, val, res)
  double precision fn
  double precision val, res

  print *, fn(val), res
end subroutine

subroutine test_c(fn, val, res)
  complex fn
  complex val, res

  print *, fn(val), res
end subroutine

program specifics

  intrinsic dcos
  intrinsic dcosh
  intrinsic dexp

  intrinsic conjg

  call test_d (dcos, 1d0, dcos(1d0))
  call test_d (dcosh, 1d0, dcosh(1d0))
  call test_d (dexp, 1d0, dexp(1d0))

  call test_c (conjg, (1.0,1.0) , conjg((1.0,1.0)))

end program

[ibook-dhum] f90/bug% gfc -fwhole-file specifics_red_4.f90
specifics_red_4.f90:25.15:

  call test_d (dcos, 1d0, dcos(1d0))
               1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:26.15:

  call test_d (dcosh, 1d0, dcosh(1d0))
               1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:27.15:

  call test_d (dexp, 1d0, dexp(1d0))
               1
Error: Type/rank mismatch in argument 'fn' at (1)
specifics_red_4.f90:29.15:

  call test_c (conjg, (1.0,1.0) , conjg((1.0,1.0)))
               1
Error: Type/rank mismatch in argument 'fn' at (1)

--------------------------------------------------------------------------------

>From http://gcc.gnu.org/ml/fortran/2009-03/msg00316.html

Your patch fixes some Segmentation faults (a couple), but not this one:

! { dg-do compile }
program test
interface
  function bad_stuff(n)
    integer :: bad_stuff (2)
    integer :: n(2)
  end function bad_stuff
   recursive function rec_stuff(n) result (tmp)
    integer :: n(2), tmp(2)
  end function rec_stuff
end interface
   integer :: res(2)
  res = bad_stuff((/-19,-30/))

end program test

  recursive function bad_stuff(n)
    integer :: bad_stuff (2)
    integer :: n(2), tmp(2), ent = 0, sent = 0
    save ent, sent
    ent = -1
   entry rec_stuff(n) result (tmp)
    if (ent == -1) then
      sent = ent
      ent = 0
    end if
    ent = ent + 1
    tmp = 1
    if(maxval (n) < 5) then
      tmp = tmp + rec_stuff (n+1)
      ent = ent - 1
    endif
    if (ent == 1) then
      if (sent == -1) then
        bad_stuff = tmp + bad_stuff (1)
      end if
      ent = 0
      sent = 0
    end if
  end function bad_stuff

--------------------------------------------------------------------------------

>From http://gcc.gnu.org/ml/fortran/2009-03/msg00317.html

A simpler test:

recursive function fac(i) result (res)
  integer :: i, j, k, res
  k = 1
  goto 100
entry bifac(i,j) result (res)
  k = j
100 continue
  if (i < k) then
    res = 1
  else
    res = i * bifac(i-k,k)
  end if
end function

program test
  external fac
  external bifac
  integer :: fac, bifac
  print *, fac(5)
  print *, bifac(5,2)
  print*, fac(6)
  print *, bifac(6,2)
  print*, fac(0)
  print *, bifac(1,2)
end program test

--------------------------------------------------------------------------------

>From http://gcc.gnu.org/ml/fortran/2009-04/msg00031.html
some ICEs on the polyhedron test suite (see also pr39896):

[ibook-dhum] lin/test% gfc -fwhole-file aermod.f90
f951: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -fwhole-file air.f90
f951: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -O0 -fwhole-file gas_dyn.f90
[ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'eos':
gas_dyn.f90:360: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -O2 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'readin':
gas_dyn.f90:1572: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -O3 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'nozzle':
gas_dyn.f90:896: internal compiler error: Bus error

Note that for gas_dyn.f90, there is no ICE at -O0 while
with nonzero optimization, the ICEs occur in different
places.


-- 
           Summary: Problems with -fwhole-file
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2009-05-04 09:10 -------
Dominique,

Thanks for setting this up.  I'll poll everybody involved for contributions and
have assigned myself the bug(s).

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-05-04 09:10:10
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #2 from pault at gcc dot gnu dot org  2009-05-04 09:29 -------
see PR40006: allow type cheating for procedures with an implicit interface""


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |40006


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #3 from pault at gcc dot gnu dot org  2009-05-04 09:31 -------
...and PR39896 : "ICE with -fwhole-file"


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |39896


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2009-05-04 17:54 -------
With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without
type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it
may give a clue on how to fix it without -fwhole-file).

For the test arr_fun.f90, I now get:

arr_fun.f90:10.6:

res = test(2)
      1
Error: The reference to function 'test' at (1) either needs an explicit
INTERFACE or the rank is incorrect

which seems right (without -fwhole-file I get a "bus error" at run time).

Test gcc/testsuite/gfortran.dg/hollerith.f90 and friends won't probably pass
regtesting:

call test (8h   hello)
           1
Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8)

I have to run the polyhedron tests and to regtest, so it is all for this time. 

Thanks for the patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #5 from dominiq at lps dot ens dot fr  2009-05-04 21:52 -------
With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html
gas_dyn.f90 fails as in commet #0, except for -O1:

[ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'chozdt':
gas_dyn.f90:216: internal compiler error: Bus error


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2009-05-04 22:20 -------
Regtest gives:

                === gfortran Summary ===

# of expected passes            117714
# of unexpected failures        576
# of expected failures          78
# of unsupported tests          906

for RUNTESTFLAGS="--target_board=unix'{,-m64,/-fwhole-file,-m64/-fwhole-file}'"
with no "unexpected failures" for {,-m64}. 444 failures come from

cc1: warning: command line option "-fwhole-file" is valid for Fortran but not
for C

I think I know how to filter them.

-------> generic_actual_arg.f90 fails with

/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/generic_actual_arg.f90:40.64:

CALL F(CALCULATION2) ! OK because there is a same name specific 
                                                                1
Error: More actual than formal arguments in procedure call at (1)

False positive?

-------> global_references_1.f90 fails with

SUBROUTINE j (x)    ! { dg-error "is already being used as a FUNCTION" }
                                                                        2
Error: Global name 'j' at (1) is already being used as a SUBROUTINE at (2)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:39.6:

  T = j () ! { dg-error "is already being used as a FUNCTION" }
      1
Error: Missing actual argument for argument 'x' at (1)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:68.64:

-------> hollerith.f90 fails with

call test (8h   hello)
           1
Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8)

-------> hollerith_legacy.f90 same failure

-------> import6.f90 fails with

opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:

  call func1(x)
             1
Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
TYPE(my_type)

Obviously some tests will require adjustments to pass with -fwhole-file.
More tomorrow.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #7 from dominiq at lps dot ens dot fr  2009-05-04 22:44 -------
Also gfortran.dg/contained_3.f90 is miscompiled with -fwhole-file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #8 from jv244 at cam dot ac dot uk  2009-05-05 04:18 -------
(In reply to comment #6)

> opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
> 
>   call func1(x)
>              1
> Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
> TYPE(my_type)

that's a proper error as well, TYPE(my_type) needs to have the SEQUENCE
attribute for this to be correct


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2009-05-05 07:04 -------
Created an attachment (id=17802)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17802&action=view)
Full summary for the tests with -fwhole-file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2009-05-05 07:05 -------
After filtering the useless warning with a line

>     regsub -all "(^|\n)cc1: warning: command line option .-fwhole-file. is valid for Fortran but not for C" $text "" text

gcc/testsuite/lib/prune.expI get:

                === gfortran Summary ===

# of expected passes            118146
# of unexpected failures        144
# of expected failures          78
# of unsupported tests          906

I attached a full summary.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #11 from dominiq at lps dot ens dot fr  2009-05-05 11:33 -------
The summary of the attached file in comment #9 is:

FAIL: gfortran.dg/bounds_check_strlen_1.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/bounds_temporaries_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/contained_3.f90  -O0  execution test
FAIL: gfortran.dg/entry_17.f90  -O   (test for warnings, line 27)
FAIL: gfortran.dg/func_decl_4.f90  -O   (test for errors, line 7)
FAIL: gfortran.dg/generic_actual_arg.f90  -O  (test for excess errors)
FAIL: gfortran.dg/global_references_1.f90  -O   (test for errors, line 39)
FAIL: gfortran.dg/hollerith.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/hollerith_legacy.f90  -O   (test for warnings, line 24)
FAIL: gfortran.dg/import6.f90  -O  (test for excess errors)
FAIL: gfortran.dg/integer_exponentiation_2.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/intrinsic_actual_1.f  -O  (test for excess errors)
FAIL: gfortran.dg/intrinsic_std_1.f90  -O  scan-tree-dump original " abort ":
dump file does not exist
FAIL: gfortran.dg/pr20865.f90  -O  (test for excess errors)
FAIL: gfortran.dg/pr37243.f  -O0  (test for excess errors)
FAIL: gfortran.dg/sizeof.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/used_before_typed_4.f90  -O  (test for excess errors)
FAIL: gfortran.dg/g77/970625-2.f  -O  (test for excess errors)

and with -m64

FAIL: gfortran.dg/loc_1.f90  -O1  (test for excess errors)

With the patch in comment #8 of pr40006, the following failures are changed:

FAIL: gfortran.dg/hollerith.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/hollerith_legacy.f90  -O  (test for excess errors)
FAIL: gfortran.dg/integer_exponentiation_2.f90  -O0  (test for excess errors)

without patch

=== gfortran Summary for unix//-fwhole-file ===

# of expected passes            28733
# of unexpected failures        68
# of expected failures          16
# of unsupported tests          397

with patch

=== gfortran Summary ===

# of expected passes            28751
# of unexpected failures        66
# of expected failures          16
# of unsupported tests          397


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #12 from dominiq at lps dot ens dot fr  2009-05-05 15:57 -------
Reduced test for gfortran.dg/contained_3.f90:

[ibook-dhum] f90/bug% cat contained_3_red.f90
MODULE ksbin1_aux_mod
 CONTAINS
  FUNCTION binden()
    INTEGER :: binden
    INTEGER :: setbd
    binden = 0
  ENTRY setbd()
    setbd = 99
  END FUNCTION binden
END MODULE ksbin1_aux_mod

PROGRAM test
  integer setbd ! setbd is external, since not use assoc.
  print *, setbd ()
  if (setbd () .ne. 42 ) call abort ()
  call foo
contains
  subroutine foo
    USE ksbin1_aux_mod ! module setbd is available
    print *, setbd ()
    if (setbd () .ne. 99 ) call abort ()
  end subroutine
END PROGRAM test

INTEGER FUNCTION setbd()
  setbd=42
END FUNCTION setbd
[ibook-dhum] f90/bug% gfc contained_3_red.f90
[ibook-dhum] f90/bug% a.out
          42
          99
[ibook-dhum] f90/bug% gfc -fwhole-file contained_3_red.f90
[ibook-dhum] f90/bug% a.out
          42
          42
Abort


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #13 from pault at gcc dot gnu dot org  2009-05-05 18:12 -------
(In reply to comment #12)
...snip...
> [ibook-dhum] f90/bug% a.out
>           42
>           42
> Abort
> 

This turns out to be the same bug as that which caused the segfault in
gas_dyn.f90.  Use associated procedures need to be excluded from the part of
the patch in trans-decl.c.  Once this is done, the whole polyhedron suite
compiles and runs at any level of optimization.

The updated patch is regtesting right now.  It still needs module procedures to
be incorporated but it is nearly there.

I have been thinking hard about type cheating - I am likely to allow it for
std-f77 and legacy, to warn with other standards and fail with -pedantic. 
However, I am open to better proposals.  I have not checked yet whether type
cheating references to a procedure need a double declaration or not (ie. to
avoid typing troubles in the back end).

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #14 from jv244 at cam dot ac dot uk  2009-05-05 19:28 -------
(In reply to comment #13)
> I have been thinking hard about type cheating - I am likely to allow it for
> std-f77 and legacy, to warn with other standards and fail with -pedantic. 

this sounds reasonable. Note the other testcases in PR40006 that cheat somewhat
beyond the 'type', I think they should be treated on the same footing. Note
that  type cheating and the like should only be allowed for calls that involve
procedures with an implicit interface, it should still be a hard error if there
is an explicit interface.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dfranke at gcc dot gnu dot org]

------- Comment #15 from dfranke at gcc dot gnu dot org  2009-05-07 18:00 -------
There's a new ICE with -fwhole-file that crept in since yesterday (20090505,
using the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html).

I'll try to get a reduced testcase.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dfranke at gcc dot gnu dot org]

------- Comment #16 from dfranke at gcc dot gnu dot org  2009-05-07 18:34 -------
$> cat ice.f90
MODULE module_foo
  TYPE :: foo_node
    TYPE(foo_node_private), POINTER :: p
  END TYPE

  TYPE :: foo_node_private
    TYPE(foo_node), DIMENSION(-1:1) :: link
  END TYPE

  TYPE :: foo
    TYPE(foo_node) :: root
  END TYPE
END MODULE

FUNCTION foo_insert()
  USE module_foo, ONLY: foo, foo_node

  INTEGER :: foo_insert
  TYPE(foo_node) :: parent, current
  INTEGER :: cmp

  parent  = current
  current = current%p%link(cmp)
END FUNCTION

FUNCTION foo_count()
  USE module_foo, ONLY: foo
  INTEGER :: foo_count
END FUNCTION

$> gfortran-svn -fwhole-file ice.f90
ice.f90: In function 'foo_insert':
ice.f90:22: internal compiler error: in fold_convert, at fold-const.c:2670

where fold-const.c:2670 is gcc_unreachable().

Adding Janus as CC as his patch has a high likelihood of being involved.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2009-05-08 14:09 -------
Thanks to the second program in 
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c6621b97f448b516#
I think I have found a false positive for -fwhole-file (unpatched):

          Implicit None 
          Interface 
             Subroutine sub( a, b, c ) 
                Implicit None 
                Integer, Intent( In )           :: a 
                Integer, Intent( In )           :: b 
                Integer, Intent( In ), Optional :: c 
             End Subroutine sub 
          End Interface 
          call sub(1,2) 
          call sub(1,2,3) 
          end 
          subroutine sub(i,j,k) 
          Implicit None 
          Integer, Intent( In )           :: i 
          Integer, Intent( In )           :: j 
          Integer, Intent( In ), Optional :: k 
          intrinsic present 
          write(*,*)' 3 presence flag ',present(k) 
          write(*,*)' 1st arg ',i 
          write(*,*)' 2nd arg ',j 
          if (present(k)) then 
            write(*,*)' 3rd arg ',k 
          else 
            write(*,*)' 3rd arg is absent' 
          endif 
          return 
          end 

[ibook-dhum] f90/bug% gfc -fwhole-file no_interface_1.f90
no_interface_1.f90:10.24:

          call sub(1,2) 
                        1
Error: Unexpected alternate return spec in subroutine call at (1)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #18 from jv244 at cam dot ac dot uk  2009-05-17 05:11 -------
the patch posted here:
http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html
allows cp2k in its single source file form, 640klines as made available in
PR40005, to compile with -fwhole-file (using the ulimit -s unlimited trick).
Even the 3Gb memory usage seems reasonable. What about turning this option on
by default now ? The warnings its generates are generally useful, and there is
the potential gain in performance. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #19 from pault at gcc dot gnu dot org  2009-05-22 13:40 -------
(In reply to comment #18)
> the patch posted here:
> http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html
> allows cp2k in its single source file form, 640klines as made available in
> PR40005, to compile with -fwhole-file (using the ulimit -s unlimited trick).
> Even the 3Gb memory usage seems reasonable. What about turning this option on
> by default now ? The warnings its generates are generally useful, and there is
> the potential gain in performance. 

I have just fixed the problem flagged up in comment #17, have cleaned up the
code somewhat and am just turning my attention to module procedures.  I expect
to get the whole lot sorted in another day or so.

As to the options for its use, I need to check out where we are with the
testsuite.  As you are aware, there are a number of problems there that I will
have to turn to next.  My inclination is to get the patch to full functionality
but to leave it as an experiment for just a little while longer.

It's good news that cp2k is now OK - did the performance improve?

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #20 from jv244 at cam dot ac dot uk  2009-05-25 06:13 -------
(In reply to comment #19)
> It's good news that cp2k is now OK - did the performance improve?
I didn't check that, I suspect that, since everything is module based, it needs
the stuff for module procedure inlining first. Right now, trunk seems broken
(PR40240) and I'm busy (PR00042) so there is no need to hurry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #21 from burnus at gcc dot gnu dot org  2009-05-27 13:02 -------
Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for
invalid program with -fwhole-file).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #22 from dominiq at lps dot ens dot fr  2009-05-27 14:05 -------
(In reply to comment #21)
> Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for
> invalid program with -fwhole-file).

My post in PR 40176 #5 was ambiguous: the infinite loop does not need the
-fwhole-file flag.
I only wanted to say that I was using a clean tree+ the patch from
http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #23 from jv244 at cam dot ac dot uk  2009-05-27 17:51 -------
I've added a 'related' PR40275 on -combine not working for Fortran. I think
that as soon as the -fwhole-file patch is added (default or not yet ;-) there
would be interest in -combine doing the right thing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #24 from pault at gcc dot gnu dot org  2009-05-29 15:33 -------
(In reply to comment #23)
> I've added a 'related' PR40275 on -combine not working for Fortran. I think
> that as soon as the -fwhole-file patch is added (default or not yet ;-) there
> would be interest in -combine doing the right thing.
> 

Just to let you all know the state of progress with the -fwhole-file work:

(i) I think that I have fixes for all the problems here up to and including
comment #17.
(ii) I have now added code to incorporate modules into the scheme.
(iii) If a patch that includes (i) and (ii) is made default, I see 168
regressions.  Many are correct failures or legacy issues (eg hollerith to
integer), and one or two ICEs have already been fixed. However, there are some
problems involving ICEs dues to different backend_decls being used for derived
types that are identical and one or two runtime failures that come in at )1 or
O2.

I cannot pick this up again until next week but I am going at it as fast as
possible.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #25 from jv244 at cam dot ac dot uk  2009-05-29 16:34 -------
(In reply to comment #24)
> However, there are some
> problems involving ICEs dues to different backend_decls being used for derived
> types that are identical

I'm not sure this is related, but note comment #8. Even identical types are not
identical, unless they are sequence type.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #26 from burnus at gcc dot gnu dot org  2009-05-29 18:42 -------
> Even identical types are not identical, unless they are sequence type.

... or BIND(C)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #27 from pault at gcc dot gnu dot org  2009-05-30 08:27 -------
(In reply to comment #25)

> > types that are identical
> I'm not sure this is related, but note comment #8. Even identical types are not
> identical, unless they are sequence type.

Joost,

No, this is not related.  The testing in the front end is more or less OK. 
However, the compiler receives more than one delaration of derived types,
either through explicit declaration, host association or use assocation.  The
middle-end has to ensure that the same backend_decl is used for each. 
Otherwise, when one is assigned to the other, via a defined assignement, it is
found that the TREE_TYPEs are not the same.  I have been trying to move the
backend_decls up to global scope so as to ensure that this happens but I am
missing some essential trick somewhere.  I'll be asking the experts next week
:-)

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #28 from pault at gcc dot gnu dot org  2009-06-01 18:00 -------
Created an attachment (id=17942)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942&action=view)
A progression of -fwhole-file

This patch is as far as I have got.  It incorporates module procedures and this
is where I have run into problems.  I have posted an appeal for help on the
list.

It should be noted that -fwhole-file is fixed to be on all the time in parse.c
so that the regtesting goes correctly.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #29 from jv244 at cam dot ac dot uk  2009-06-01 19:34 -------
(In reply to comment #28)
> Created an attachment (id=17942)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942&action=view) [edit]
> A progression of -fwhole-file
> This patch is as far as I have got.  

this seems to have some memory problem somewhere, compiling the normal version
of cp2k (i.e. one module per file), at least 10Gb of memory is needed in
several cases.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #30 from jv244 at cam dot ac dot uk  2009-06-01 19:43 -------
Created an attachment (id=17944)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17944&action=view)
testcase

attached is a testcase, this actually causes a segfault outside of the build
infrastructure, but consumes XGb within:

gfortran -v -ffree-form btree_i8_k_i4_v.F

(gdb) bt
#0  0x00007ffe74a0efb0 in strcmp () from /lib64/libc.so.6
#1  0x000000000051bcbd in gfc_find_symtree (st=0x13f4460, name=0x7ffe741dba90
"btree_node_p")
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2306
#2  0x000000000051bedb in gfc_find_sym_tree (name=0x7ffe741dba90
"btree_node_p", ns=0x132b490, parent_flag=0,
    result=0x7fff7d54e068) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2466
#3  0x000000000051bf82 in gfc_find_symbol (name=0x7ffe741dba90 "btree_node_p",
ns=0x7ffe741dbbd0, parent_flag=0,
    result=0x7fff7d54e098) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2502
#4  0x00000000005724dd in gfc_get_derived_type (derived=0x13309f0)
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1945
#5  0x0000000000572861 in copy_dt_decls_ifequal (from=<value optimized out>,
to=<value optimized out>,
    from_gsym=<value optimized out>) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864
#6  0x0000000000572506 in gfc_get_derived_type (derived=0x132fc30)
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948
#7  0x0000000000572861 in copy_dt_decls_ifequal (from=<value optimized out>,
to=<value optimized out>,
    from_gsym=<value optimized out>) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864
#8  0x0000000000572506 in gfc_get_derived_type (derived=0x13309f0)
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948
#9  0x0000000000572861 in copy_dt_decls_ifequal (from=<value optimized out>,
to=<value optimized out>,
    from_gsym=<value optimized out>) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864
#10 0x0000000000572506 in gfc_get_derived_type (derived=0x132fc30)
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #31 from dominiq at lps dot ens dot fr  2009-06-02 09:29 -------
With the patch in comment #28, I have a dozen new ICEs in my test suite.  They
seems to be in two classes:

[ibook-dhum] f90/bug% cat pr33295.f90
module A
  type A_type
    real comp
  end type
end module A
module B
contains
  function initA()
    use A
    implicit none
    type(A_type):: initA
    initA%comp=1.0
  end function
end module B
program C
  use B
  use A
  implicit none
  type(A_type):: A_var
  A_var = initA()
end program C
[ibook-dhum] f90/bug% gfc pr33295.f90
pr33295.f90: In function 'c':
pr33295.f90:24: internal compiler error: in fold_convert, at fold-const.c:2687

and

[ibook-dhum] f90/bug% cat test_point.f90
module global
 type                                ::  mytype
    type(mytype),pointer   ::  this
 end type mytype
 type(mytype),target        :: base
end module global
program test_equi
 use global
 call check()
 print *, "base%this%this=>base?"  ,  associated(base%this%this,base)
 print *, "base%this%this=>?" ,          associated(base%this%this)
 print *, "base%this=>?" ,                   associated(base%this)
contains
 subroutine check()
 type(mytype),target        :: j
 base%this => j                      !have the variables point
 j%this => base                      !to one another
 end subroutine check             !take j out of scope
end program test_equi
[ibook-dhum] f90/bug% gfc test_point.f90
gfc: Internal error: Segmentation fault (program f951)

Concerning gfortran.dg/default_initialization_3.f90, I cannot say if the
problem is with the front-end or the middle-end, but it is certainly tricky to
do the correct inlining. I think the problem should go to another pr.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #32 from dominiq at lps dot ens dot fr  2009-06-02 12:32 -------
I think the following code:

function CHECK_INTEGER4_RANK1 (EXPECTED, COMPUTED)
  integer(4), intent(in), dimension(:) ::  EXPECTED
  integer(4), intent(in), dimension(:) ::  COMPUTED
  logical  :: CHECK_INTEGER4_RANK1
  CHECK_INTEGER4_RANK1 = all(COMPUTED == EXPECTED)
end function CHECK_INTEGER4_RANK1
program array_test
!use CHECK_SEM
logical :: CHECK_INTEGER4_RANK1
  integer,dimension(-1:1,-1:1)      :: mis1=1.1 
  logical,dimension(-1:1,-1:1)      :: ml2=.true.
  logical :: res
  integer, dimension(3) :: theo, dat
  theo = sum(mis1,dim=1,mask=ml2)
  dat = (/8,5,12/)
  res = CHECK_INTEGER4_RANK1 (theo, dat)
end program array_test

should give an error about missing interface with -fwhole-file (it does not
with the patch in comment #28).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

------- Comment #33 from rguenth at gcc dot gnu dot org  2009-06-14 16:58 -------
I am willing to help with analyzing/fixing middle-end problems with
-fwhole-file,
but it would be nice to have some of the progression pieces in trunk to do so
;)

That said - I'm currently trying to hook up LTO for gfortran, which does seem
to work for a simple two-file hello world.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]



------- Comment #34 from jv244 at cam dot ac dot uk  2009-07-24 05:39 -------
Testing paul's latest patch at 

http://gcc.gnu.org/ml/fortran/2009-07/msg00202.html 

on the latest all file CP2K (see also PR40005)

http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2009-05-01.f90.gz

I get the following ICE for 

ulimit -s 512000
gfortran -c -O2 -march=native -fwhole-file CP2K_2009-05-01.f90

CP2K_2009-05-01.f90: In function ‘broadcast_input_information’:
CP2K_2009-05-01.f90:53523:0: internal compiler error: tree check: expected
record_type or union_type or qual_union_type, have H��H$@
in gfc_get_derived_type, at fortran/trans-types.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

I won't be able to reduce this failure for the next 10 days or so.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #35 from jv244 at cam dot ac dot uk  2009-07-24 05:48 -------
(In reply to comment #34)
> I won't be able to reduce this failure for the next 10 days or so.

as a PS, the multiple-file compilation of trunk cp2k goes fine. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

------- Comment #36 from rguenth at gcc dot gnu dot org  2009-07-24 10:24 -------
With the newest whole-file patch I instead get

#1  0x087a1c89 in tree_check_failed (node=0xb6e9fcb0, 
    file=0x8b9d398 "/home/richard/src/trunk/gcc/fortran/trans-types.c", 
    line=2010, function=0x8b9da9d "gfc_get_derived_type")
    at /home/richard/src/trunk/gcc/tree.c:7460
7460      internal_error ("tree check: %s, have %s in %s, at %s:%d",
(gdb) 
#2  0x081e2850 in gfc_get_derived_type (derived=0x136519f0)
    at /home/richard/src/trunk/gcc/fortran/trans-types.c:2010
2010          if (TYPE_FIELDS (derived->backend_decl))

with derived->backend_decl looking like random crap.
(in fact it seems to be GC collected memory, all 0xa5a5a5a5).

All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their 2nd argument.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

------- Comment #37 from rguenth at gcc dot gnu dot org  2009-07-24 10:27 -------
We then get to the next ICE ...

(gdb) up
#1  0x0819bfaa in gfc_create_module_variable (sym=0x22cb3750)
    at /home/richard/src/trunk/gcc/fortran/trans-decl.c:3327
3327          gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
(gdb) l
3327          gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
3328                      || TYPE_CONTEXT (decl) ==
sym->ns->proc_name->backend_decl);

   context <namespace_decl 0xb7665cb0 global_types>

vs.

 <namespace_decl 0xad5080e0 ep_types
    type <void_type 0xb7ccb9a0 void VOID
        align 8 symtab 0 alias set -1 canonical type 0xb7ccb9a0
        pointer_to_this <pointer_type 0xb7ccba10>>
    VOID file CP2K_2009-05-01.f90 line 332958 col 0
    align 1>

I'll reduce that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

------- Comment #38 from rguenth at gcc dot gnu dot org  2009-07-24 10:56 -------
Too large, not reducing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #39 from jv244 at cam dot ac dot uk  2009-07-24 11:29 -------
(In reply to comment #36)
> All of gfortran.h seems to be ignorant of the GC - which means we may
> not garbage collect while the FE is still running, so all calls to
> cgraph_finalize_function should have true as their 2nd argument.
> 
I wonder if this is the reason for PR40005 ??

since it garbage collector seems to run from within the frontend in that case:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005#c10


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #40 from jv244 at cam dot ac dot uk  2009-07-25 16:53 -------
(In reply to comment #38)
> Too large, not reducing.

since you were so kind fixing PR40005, I felt some obligation ;-)

MODULE replica_types
  TYPE replica_env_type
  END TYPE replica_env_type
CONTAINS
  SUBROUTINE rep_env_create(rep_env, para_env, input, nrep, prep,&
       sync_v,keep_wf_history,row_force)
  END SUBROUTINE rep_env_create
  SUBROUTINE rep_envs_add_rep_env(rep_env)
    TYPE(replica_env_type), POINTER          :: rep_env
  END SUBROUTINE rep_envs_add_rep_env
END MODULE replica_types
MODULE ep_types
  USE replica_types
  TYPE ep_env_type
     TYPE(replica_env_type), POINTER :: mol_envs
  END TYPE ep_env_type
  TYPE ep_env_p_type
     TYPE(ep_env_type), POINTER :: ep_env
  END TYPE ep_env_p_type
  TYPE(ep_env_p_type), DIMENSION(:), POINTER :: ep_envs
CONTAINS
  SUBROUTINE ep_force_release()
  END SUBROUTINE ep_force_release
END MODULE ep_types

bug.f90:7:0: internal compiler error: in gfc_create_module_variable, at
fortran/trans-decl.c:3328


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

------- Comment #41 from rguenth at gcc dot gnu dot org  2009-07-26 21:23 -------
3323          gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
3324                      || TYPE_CONTEXT (decl) ==
sym->ns->proc_name->backend_decl);
3325          gcc_assert (DECL_CONTEXT (TYPE_STUB_DECL (decl)) == NULL_TREE
3326                      || DECL_CONTEXT (TYPE_STUB_DECL (decl))
3327                         == sym->ns->proc_name->backend_decl);

if the second assert isn't bogus then both types (the one in the replica_type
module and the imported one) have to have separate type-stub-decls (thus
two debug information entries).

Personally I think it is quite reasonable to use the replica_type modules
debug info for the USE imported one, thus simply remove the 2nd assert.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #42 from jv244 at cam dot ac dot uk  2009-07-28 07:37 -------
another issue I found is this:

> gfortran -fwhole-file test.f90
/tmp/cciOiaMB.o: In function `__m_MOD_b':
test.f90:(.text+0xa): undefined reference to `c_'
collect2: ld returned 1 exit status

> cat test.f90

SUBROUTINE c()
 CALL a()
END SUBROUTINE c

SUBROUTINE a()
END SUBROUTINE a


MODULE M
CONTAINS
 SUBROUTINE b()
   CALL c()
 END SUBROUTINE
END MODULE


USE M
CALL b()
END

things link fine if I swap the order of definition of the subroutines 'a' and
'c'

it is similar to PR40873, but happens with just -fwhole-file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #43 from pault at gcc dot gnu dot org  2009-08-01 13:45 -------
Subject: Bug 40011

Author: pault
Date: Sat Aug  1 13:45:12 2009
New Revision: 150333

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150333
Log:
2009-08-01  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/40011
        * error.c : Add static flag 'warnings_not_errors'.
        (gfc_error): If 'warnings_not_errors' is set, branch to code
        from gfc_warning.
        (gfc_clear_error): Reset 'warnings_not_errors'.
        (gfc_errors_to_warnings): New function.
        * options.c (gfc_post_options): If pedantic and flag_whole_file
        change the latter to a value of 2.
        * parse.c (parse_module): Add module namespace to gsymbol.
        (resolve_all_program_units): New function.
        (clean_up_modules): New function.
        (translate_all_program_units): New function.
        (gfc_parse_file): If whole_file, do not clean up module right
        away and add derived types to namespace derived types. In
        addition, call the three new functions above.
        * resolve.c (not_in_recursive): New function.
        (not_entry_self_reference): New function.
        (resolve_global_procedure): Symbol must not be IFSRC_UNKNOWN,
        procedure must not be in the course of being resolved and
        must return false for the two new functions. Pack away the
        current derived type list before calling gfc_resolve for the
        gsymbol namespace.  It is unconditionally an error if the ranks
        of the reference and ther procedure do not match. Convert
        errors to warnings during call to gfc_procedure_use if not
        pedantic or legacy.
        (gfc_resolve): Set namespace resolved flag to -1 during
        resolution and store current cs_base.
        * trans-decl.c (gfc_get_symbol_decl): If whole_file compilation
        substitute a use associated variable, if it is available in a
        gsymbolnamespace.
        (gfc_get_extern_function_decl): If the procedure is use assoc,
        do not attempt to find it in a gsymbol because it could be an
        interface. If the symbol exists in a module namespace, return
        its backend_decl.
        * trans-expr.c (gfc_trans_scalar_assign): If a derived type
        assignment, set the rhs TYPE_MAIN_VARIANT to that of the rhs.
        * trans-types.c (copy_dt_decls_ifequal): Add 'from_gsym' as a
        boolean argument. Copy component backend_decls directly if the
        components are derived types and from_gsym is true.
        (gfc_get_derived_type): If whole_file copy the derived type from
        the module if it is use associated, otherwise, if can be found
        in another gsymbol namespace, use the existing derived type as
        the TYPE_CANONICAL and build normally.
        * gfortran.h : Add derived_types and resolved fields to
        gfc_namespace. Include prototype for gfc_errors_to_warnings.

2009-08-01  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/40011
        * gfortran.dg/whole_file_7.f90: New test.
        * gfortran.dg/whole_file_8.f90: New test.
        * gfortran.dg/whole_file_9.f90: New test.
        * gfortran.dg/whole_file_10.f90: New test.
        * gfortran.dg/whole_file_11.f90: New test.
        * gfortran.dg/whole_file_12.f90: New test.
        * gfortran.dg/whole_file_13.f90: New test.
        * gfortran.dg/whole_file_14.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/whole_file_10.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_11.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_12.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_13.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_14.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_7.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_8.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_9.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/error.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/options.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #44 from jv244 at cam dot ac dot uk  2009-08-03 10:12 -------
Just for completeness, current trunk still fails on the testcases in comment
#40 and comment #42.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #45 from jv244 at cam dot ac dot uk  2009-08-26 09:23 -------
Paul, are there issues other than the ones reported in comment #44 that prevent
making -fwhole-file the default? 
Richard, do you believe PR38913 (Fortran does not set TYPE_CANONICAL properly)
can be fixed for 4.5? 

I believe whole-file should be made default before the end of stage 1, if any
serious problem emerges that can not be fixed, one can always do a step back.

For example, LTO (-flto) enables -fwhole-file by default, and presumably will
be merged in trunk one of these days.

Furthermore, I believe that it would be a good idea to enable -fwhole-file by
default for Fortan anyway, so that the additional, useful, warning messages are
generated. This will furthermore guarantee that the number of warnings
generated by the FE doesn't depend on optimization flags such as -flto. A bonus
is of course that whole-file gets more testing, so that it becomes reliable.


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenther at suse dot de]

------- Comment #46 from rguenther at suse dot de  2009-08-26 09:34 -------
Subject: Re:  Problems with -fwhole-file

On Wed, 26 Aug 2009, jv244 at cam dot ac dot uk wrote:

> ------- Comment #45 from jv244 at cam dot ac dot uk  2009-08-26 09:23 -------
> Paul, are there issues other than the ones reported in comment #44 that prevent
> making -fwhole-file the default? 
> Richard, do you believe PR38913 (Fortran does not set TYPE_CANONICAL properly)
> can be fixed for 4.5? 

I don't really know.

> I believe whole-file should be made default before the end of stage 1, if any
> serious problem emerges that can not be fixed, one can always do a step back.

True.

> For example, LTO (-flto) enables -fwhole-file by default, and presumably will
> be merged in trunk one of these days.
> 
> Furthermore, I believe that it would be a good idea to enable -fwhole-file by
> default for Fortan anyway, so that the additional, useful, warning messages are
> generated. This will furthermore guarantee that the number of warnings
> generated by the FE doesn't depend on optimization flags such as -flto. A bonus
> is of course that whole-file gets more testing, so that it becomes reliable.

Correct.  If required I can build SPEC2000 and SPEC2006 with -fwhole-file
again and see what the fallout is.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #47 from dominiq at lps dot ens dot fr  2009-08-26 10:32 -------
Created an attachment (id=18427)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18427&action=view)
Self contained reduced test for pr40440


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #48 from dominiq at lps dot ens dot fr  2009-08-26 10:34 -------
> are there issues other than the ones reported in comment #44

I have opened pr41056 and pr41059 for other problems. There are ICEs for the
original test in pr40440 (with external iso_varying_string.mod, but not if
iso_varying_string.f95 is included) and a self contained reduced test I have
posted on the mailing list and I am attaching. Also the test in comment #5 of
pr40737 gives an ICE:

[ibook-dhum] f90/bug% gfc -fwhole-file pr40737.f90
pr40737.f90: In function 'tf_ad_splitting_driver_plane':
pr40737.f90:11:0: internal compiler error: Bus error

On the positive side -fwhole-file fixes some ICE after errors as in pr37744
(with both .FALSE._C_BOOL and .FALSE.) and pr40994.f90.

Finally the last time -fwhole-file was the default, -fno-whole-file, it was not
working.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #49 from dominiq at lps dot ens dot fr  2009-08-26 10:35 -------
> Finally the last time -fwhole-file was the default, -fno-whole-file, it was not working.

Please read: "Finally the last time -fwhole-file was the default,
-fno-whole-file was not working."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #50 from jv244 at cam dot ac dot uk  2009-10-11 12:45 -------
As expected, the testcases in comment #40 and comment #42 now also fail at '-O2
-flto'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #51 from jv244 at cam dot ac dot uk  2009-12-09 11:50 -------
still failing with current trunk, also leading to miscomples (see PR38913). As
a consequence, should one disable -fwhole-file (and consequently -flto) for
Fortran before release?


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2009-05-04 09:10:10         |2009-12-09 11:50:57
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenther at suse dot de]

------- Comment #52 from rguenther at suse dot de  2009-12-09 11:52 -------
Subject: Re:  Problems with -fwhole-file

On Wed, 9 Dec 2009, jv244 at cam dot ac dot uk wrote:

> ------- Comment #51 from jv244 at cam dot ac dot uk  2009-12-09 11:50 -------
> still failing with current trunk, also leading to miscomples (see PR38913). As
> a consequence, should one disable -fwhole-file (and consequently -flto) for
> Fortran before release?

As neither is enabled by default I instead recommend to document the
experimental status instead.  Note that -flto works around most of
the frontend issues by performing its own type and decl unification.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #53 from jv244 at cam dot ac dot uk  2010-05-03 10:57 -------
testcase in comment #40 now works. Comment #42 still fails.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jvdelisle at gcc dot gnu dot org]

------- Comment #54 from jvdelisle at gcc dot gnu dot org  2010-05-03 19:24 -------
We should get the case in comment 40 added to the test suite if not already so
we do not regress it later.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[pault at gcc dot gnu dot org]

------- Comment #55 from pault at gcc dot gnu dot org  2010-05-26 05:11 -------
Subject: Bug 40011

Author: pault
Date: Wed May 26 05:11:04 2010
New Revision: 159852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159852
Log:
2010-05-26  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/40011
        * resolve.c (resolve_global_procedure): Resolve the gsymbol's
        namespace before trying to reorder the gsymbols.

2010-05-26  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/40011
        * gfortran.dg/whole_file_19.f90 : New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/whole_file_19.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #56 from jv244 at cam dot ac dot uk  2010-05-26 13:13 -------
(In reply to comment #55)
> Subject: Bug 40011
> 
> Author: pault
> Date: Wed May 26 05:11:04 2010
> New Revision: 159852

I'm still having linking problems with -fwhole-file on the single source file
version of CP2K. Will try to get to a testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dominiq at lps dot ens dot fr]

------- Comment #57 from dominiq at lps dot ens dot fr  2010-05-26 14:52 -------
> Author: pault
> Date: Wed May 26 05:11:04 2010
> New Revision: 159852

The original code of pr40440 and the reduced test of comment #47 still ICE:

(gdb) run -fwhole-file pr40440_red.f90
Starting program:
/opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.3.0/4.6.0/f951 -fwhole-file
pr40440_red.f90
 line_get_string_advance line_init syntax_init_from_ifile
Breakpoint 1, fancy_abort (file=0x1009c1d20 "../../work/gcc/fold-const.c",
line=2042, function=0x100a2b850 "fold_convert_loc") at
../../work/gcc/diagnostic.c:787
787     {
(gdb) bt
#0  fancy_abort (file=0x1009c1d20 "../../work/gcc/fold-const.c", line=2042,
function=0x100a2b850 "fold_convert_loc") at ../../work/gcc/diagnostic.c:787
#1  0x00000001004bb6d1 in fold_convert_loc (loc=0, type=0x141e17930, arg=<value
temporarily unavailable, due to optimizations>) at
../../work/gcc/fold-const.c:2042
#2  0x00000001000cc014 in gfc_trans_scalar_assign (lse=0x7fff5fbfd5f0,
rse=0x7fff5fbfd5a0, ts={type = BT_DERIVED, kind = 0, u = {derived = 0x0, cl =
0x0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = 0},
l_is_temp=0 '\0', r_is_var=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:4836
#3  0x00000001000cf844 in gfc_trans_assignment_1 (expr1=0x14181e5d0,
expr2=0x14181e750, init_flag=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:5282
#4  0x00000001000cfc34 in gfc_trans_assignment (expr1=0x14181e5d0,
expr2=0x14181e750, init_flag=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:5424
#5  0x00000001000aa8e6 in trans_code (code=0x14181e810, cond=0x0) at
../../work/gcc/fortran/trans.c:1082
#6  0x00000001000c769f in gfc_generate_function_code (ns=<value temporarily
unavailable, due to optimizations>) at ../../work/gcc/fortran/trans-decl.c:4483
#7  0x00000001000aad0b in gfc_generate_module_code (ns=<value temporarily
unavailable, due to optimizations>) at ../../work/gcc/fortran/trans.c:1392
#8  0x000000010006cd0f in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4287
#9  0x00000001000a586c in gfc_be_parse_file (set_yydebug=<value temporarily
unavailable, due to optimizations>) at ../../work/gcc/fortran/f95-lang.c:239
#10 0x00000001006dc789 in toplev_main (argc=3, argv=0x7fff5fbfdad0) at
../../work/gcc/toplev.c:1049
#11 0x0000000100001094 in start ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[dfranke at gcc dot gnu dot org]

------- Comment #58 from dfranke at gcc dot gnu dot org  2010-07-18 20:49 -------
Subject: Bug 40011

Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287
Log:
gcc/fortran/:
2010-07-18  Daniel Franke  <franke.daniel@gmail.com>
            Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/30668
        PR fortran/31346
        PR fortran/34260
        * resolve.c (resolve_global_procedure): Improved checking if an
        explicit interface is required.

        PR fortran/40011
        * resolve.c (resolve_global_procedure): Resolve the gsymbol's
        namespace before trying to reorder the gsymbols.

gcc/testsuite/:
2010-07-18  Daniel Franke  <franke.daniel@gmail.com>
            Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/30668
        PR fortran/31346
        PR fortran/34260
        PR fortran/40011
        * gfortran.dg/pr40999.f: Fix function type.
        * gfortran.dg/whole_file_5.f90: Likewise.
        * gfortran.dg/whole_file_6.f90: Likewise.
        * gfortran.dg/whole_file_16.f90: New.
        * gfortran.dg/whole_file_17.f90: New.
        * gfortran.dg/whole_file_18.f90: New.
        * gfortran.dg/whole_file_19.f90: New.


Added:
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90
Modified:
    branches/gcc-4_5-branch/gcc/fortran/ChangeLog
    branches/gcc-4_5-branch/gcc/fortran/resolve.c
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #59 from jv244 at cam dot ac dot uk  2010-07-23 22:15 -------
I'm trying a recent trunk (162490), and I'm still observing that -fwhole-file
causing linking errors. I have no easy testcase, the way to reproduce is:

download http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz
compile and link (takes several minutes & about 2Gb RAM) in
CP2K_gcc_2007_06/src as:

gfortran -fwhole-file -O0  all.f90 -llapack -lblas

this leads to undefined references to:

/tmp/ccSrltD0.o: In function `__fft_tools_MOD_fft3d_pb':
all.f90:(.text+0xb1c61): undefined reference to `fft_1dm_'
all.f90:(.text+0xb2824): undefined reference to `fft_1dm_'
all.f90:(.text+0xb33f7): undefined reference to `fft_1dm_'
all.f90:(.text+0xb4227): undefined reference to `fft_1dm_'
all.f90:(.text+0xb4dea): undefined reference to `fft_1dm_'
/tmp/ccSrltD0.o:all.f90:(.text+0xb5984): more undefined references to
`fft_1dm_' follow
/tmp/ccSrltD0.o: In function `mltfftsg_':
all.f90:(.text+0xdbb41a): undefined reference to `ctrig_'
all.f90:(.text+0xdbb895): undefined reference to `fftpre_'
all.f90:(.text+0xdbb95b): undefined reference to `fftstp_'
all.f90:(.text+0xdbbd14): undefined reference to `fftstp_'
all.f90:(.text+0xdbbe5c): undefined reference to `fftrot_'
all.f90:(.text+0xdbbf64): undefined reference to `fftstp_'

but goes fine without the '-fwhole-file'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #60 from jv244 at cam dot ac dot uk  2010-07-23 22:55 -------
(In reply to comment #59)
>  I have no easy testcase

it seems possible to retain only the first 60498 lines of all.f90 (till the end
of module fft_tools), and add END to get a much smaller testcase...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #61 from jv244 at cam dot ac dot uk  2010-07-24 08:24 -------
(In reply to comment #60)
> it seems possible to retain only the first 60498 lines of all.f90 (till the end
> of module fft_tools), and add END to get a much smaller testcase...

I've started a delta reduction, I believe it is feasible, but could take a
while. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #62 from jv244 at cam dot ac dot uk  2010-07-24 11:10 -------
a testcase...

> cat bug.f90
SUBROUTINE fft_3d ( fft_type, fft_in_place, fsign, scale, n, zin, zout )
        CALL fftsg3d ( fft_in_place, fsign, scale, n, zin, zout )
END SUBROUTINE fft_3d
SUBROUTINE fft_1dm ( fft_type, fsign, trans, n, m, zin, zout, scale )
END SUBROUTINE fft_1dm
SUBROUTINE fftsg3d ( fft_in_place, fsign, scale, n, zin, zout )
  INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND ( 14, 200 )
    CALL mltfftsg ( 'N', 'T', zin, nx, ny*nz, xf, ny*nz, nx, nx,  &
           ny*nz, fsign, 1.0_dp )
END SUBROUTINE fftsg3d
SUBROUTINE mltfftsg ( transa, transb, a, ldax, lday, b, ldbx, ldby,  n, m,
isign, scale )
END SUBROUTINE mltfftsg
MODULE fft_tools
CONTAINS
SUBROUTINE fft3d_s ( fsign, n, zin, zout, scale, status, debug )
  CALL fft_3d ( fft_type, fft_in_place, sign, norm, n, zin, zoptr )
END SUBROUTINE fft3d_s
SUBROUTINE fft3d_ps ( fsign, n, cin, gin, gs_group, rs_group, yzp, &
                      nyzray,  bo, scale, status, debug )
      CALL fft_1dm ( fft_type, sign, .TRUE., n(3), mx1*my1, pbuf, qbuf, norm )
END SUBROUTINE fft3d_ps
END MODULE fft_tools
END

links with:
gfortran-trunk -fno-whole-file  bug.f90

fails with:
gfortran-trunk -fwhole-file  bug.f90

some of the argument mismatches are a result of the reduction, but not all of
them, so I guess that is key.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

------- Comment #63 from jv244 at cam dot ac dot uk  2010-07-24 11:14 -------
even better testcase... no mismatching arguments:

SUBROUTINE fft_3d ( )
        CALL fftsg3d ()
END SUBROUTINE fft_3d
SUBROUTINE fft_1dm ( )
END SUBROUTINE fft_1dm
SUBROUTINE fftsg3d ( )
    CALL mltfftsg ( )
END SUBROUTINE fftsg3d
SUBROUTINE mltfftsg ( )
END SUBROUTINE mltfftsg
MODULE fft_tools
CONTAINS
SUBROUTINE fft3d_s ( )
  CALL fft_3d ( )
END SUBROUTINE fft3d_s
SUBROUTINE fft3d_ps ( )
      CALL fft_1dm ( )
END SUBROUTINE fft3d_ps
END MODULE fft_tools
END


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #64 from burnus at gcc dot gnu dot org  2010-07-24 11:31 -------
Reduced a tiny bit more. If one swaps "one" and "two" (functions or use) it
works - if one swaps both, it fails again. Wild guess: gfortran does not
properly walk the tree.

Failure with -fwhole-file:
  /tmp/ccN7F1tB.o: In function `__mod_MOD_four':
  test.f90:(.text+0x3): undefined reference to `one_'


SUBROUTINE one ( )
END SUBROUTINE one

SUBROUTINE two ( )
END SUBROUTINE two

MODULE mod
CONTAINS
  SUBROUTINE three ( )
    CALL two ( )
  END SUBROUTINE three
  SUBROUTINE four ( )
      CALL one ( )
  END SUBROUTINE four
END MODULE mod
END


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
         AssignedTo|pault at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #65 from burnus at gcc dot gnu dot org  2010-07-24 13:08 -------
(In reply to comment #64)
> Failure with -fwhole-file:
>   /tmp/ccN7F1tB.o: In function `__mod_MOD_four':
>   test.f90:(.text+0x3): undefined reference to `one_'

If one sets a breakpoint in gfc_create_function_decl,
gfc_generate_function_code, and gfc_get_extern_function_decl one has:
...
gfc_get_extern_function_decl "two"
<--- (1) --->
gfc_generate_function_code "two"
...

In between those functions calls, the gfc_global_ns_list changes from:
"two"->"one" to "two"->"MAIN__".

If I add the following patch, it works with the reduced test case and seems to
also work with the one-file CP2K. I wonder why this problem did not show up
before. It seems to be pretty obvious and not restricted to -fwhole-file
(though, the chance of miscompilation is much increased with -fwhole-file).

Index: parse.c
===================================================================
--- parse.c     (Revision 162498)
+++ parse.c     (Arbeitskopie)
@@ -4414,7 +4414,11 @@
      later and all their interfaces resolved.  */   gfc_current_ns->code =
s.head;
   if (next)
-    next->sibling = gfc_current_ns;
+    {
+      for (; next->sibling; next = next->sibling)
+       ;
+      next->sibling = gfc_current_ns;
+    }
   else
     gfc_global_ns_list = gfc_current_ns;


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-12-09 11:50:57         |2010-07-24 13:08:14
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenther at suse dot de]

------- Comment #66 from rguenther at suse dot de  2010-07-24 13:46 -------
Subject: Re:  Problems with -fwhole-file

On Sat, 24 Jul 2010, burnus at gcc dot gnu dot org wrote:

> 
> 
> ------- Comment #64 from burnus at gcc dot gnu dot org  2010-07-24 11:31 -------
> Reduced a tiny bit more. If one swaps "one" and "two" (functions or use) it
> works - if one swaps both, it fails again. Wild guess: gfortran does not
> properly walk the tree.
> 
> Failure with -fwhole-file:
>   /tmp/ccN7F1tB.o: In function `__mod_MOD_four':
>   test.f90:(.text+0x3): undefined reference to `one_'
> 
> 
> SUBROUTINE one ( )
> END SUBROUTINE one
> 
> SUBROUTINE two ( )
> END SUBROUTINE two
> 
> MODULE mod
> CONTAINS
>   SUBROUTINE three ( )
>     CALL two ( )
>   END SUBROUTINE three
>   SUBROUTINE four ( )
>       CALL one ( )
>   END SUBROUTINE four
> END MODULE mod
> END

To diagnose these kind of problems look at -fdump-tree-original-uid
and/or -fdump-ipa-cgraph.  You'll see if the middle-end thinks
you have two different entities for one function or variable.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #67 from burnus at gcc dot gnu dot org  2010-07-24 14:08 -------
 (In reply to comment #66)
> > Failure with -fwhole-file:
> >   /tmp/ccN7F1tB.o: In function `__mod_MOD_four':
> >   test.f90:(.text+0x3): undefined reference to `one_'
> 
> To diagnose these kind of problems look at -fdump-tree-original-uid
> and/or -fdump-ipa-cgraph.  You'll see if the middle-end thinks
> you have two different entities for one function or variable.

Thanks for suggestion; I try to remember it for debugging the -fwhole-program
issues for which it should be very useful. Though, in this case there is only
one UID for "one" - for the external call. The function itself not even
generated without the patch. Thus, the linker error says it all :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #68 from burnus at gcc dot gnu dot org  2010-07-24 16:32 -------
Subject: Bug 40011

Author: burnus
Date: Sat Jul 24 16:32:11 2010
New Revision: 162500

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162500
Log:
2010-07-24  Tobias Burnus  <burnus@net-b.de>

        PR fortran/40011
        * parse.c (gfc_parse_file): Do not override
        gfc_global_ns_list items.

2010-07-24  Tobias Burnus  <burnus@net-b.de>

        PR fortran/40011
        * gfortran.dg/whole_file_21.f90: New.

        * gfortran.dg/integer_exponentiation_3.F90: Use
        -ffloat-store only for i?86/x86-64 -m32.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/parse.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_3.F90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[jvdelisle at gcc dot gnu dot org]

------- Comment #69 from jvdelisle at gcc dot gnu dot org  2010-07-25 01:21 -------
Great detective work folks!  The sneaky bugs usually are simple to fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #70 from burnus at gcc dot gnu dot org  2010-07-25 10:11 -------
Are there still remaining issues, and if so which? I think this PR gets too
long to have an overview...

I only found the one in comment 47: Works -fno-whole-file but fails otherwise
with an ICE in fold_convert_loc, at fold-const.c:2021.

With the patch of PR 40873 comment 18 applied, all tests seem to work with
"-fwhole-program -O3" - except of the comment 47 failure and an additional one
for comment 0 test (4) (cf. PR 40873 comment 21)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #71 from burnus at gcc dot gnu dot org  2010-07-26 09:53 -------
Subject: Bug 40011

Author: burnus
Date: Mon Jul 26 09:53:19 2010
New Revision: 162531

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162531
Log:
Add file forgotten in commit Rev. 162500

2010-07-24  Tobias Burnus  <burnus@net-b.de>

        PR fortran/40011
        * gfortran.dg/whole_file_21.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/whole_file_21.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[burnus at gcc dot gnu dot org]

------- Comment #72 from burnus at gcc dot gnu dot org  2010-07-26 13:15 -------
(In reply to comment #70)
> With the patch of PR 40873 comment 18 applied [...]

There is now a new patch which fixes tons of issues including the test case of
comment 0 number 4, but not the one from comment 47.


> Are there still remaining issues, and if so which? I think this PR gets too
> long to have an overview...
> 
> I only found the one in comment 47: Works -fno-whole-file but fails otherwise
> with an ICE in fold_convert_loc, at fold-const.c:2021.

I have now filled PR 45077 to track that issue. If you find a new issue - or if
there is a left over, which I have missed, please fill a new PR.

Thus: Close as FIXED. Thanks to all involved for the bug reporting and fixing!


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|45077                       |
              nThis|                            |
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011