--- Comment #27 from burnus at gcc dot gnu dot org 2010-07-27 08:44 ---
Subject: Bug 40873
Author: burnus
Date: Tue Jul 27 08:44:22 2010
New Revision: 162557
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162557
Log:
2010-07-26 Tobias Burnus bur...@net-b.de
PR
--- Comment #28 from burnus at gcc dot gnu dot org 2010-07-27 08:46 ---
FIXED on the trunk (4.6). Thanks for the reports, comments, patches,
suggestions, and reviews!
See PR 45077, PR 45087, and PR 44945 for remaining -fwhole-(file,program) bugs.
--
burnus at gcc dot gnu dot org
--- Comment #23 from burnus at gcc dot gnu dot org 2010-07-26 13:25 ---
Created an attachment (id=21315)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21315action=view)
New trans-decl.c patch - seems to work well
New patch. Found the problem with the help of Jakub (thanks!); not
--- Comment #24 from dominiq at lps dot ens dot fr 2010-07-26 17:02 ---
With the patch in comment #23, the polyhedron tests gas_dyn.f90 and
test_fpu.f90 do not link and compiling the test in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867#c6 gives an ICE (Segmentation
fault).
--- Comment #25 from burnus at gcc dot gnu dot org 2010-07-26 17:03 ---
(In reply to comment #23)
Created an attachment (id=21315)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21315action=view) [edit]
New trans-decl.c patch - seems to work well
Dominique has found a failure
--- Comment #26 from dominiq at lps dot ens dot fr 2010-07-26 21:00 ---
The patch in comment #25 fixes the ICE for PR 31867 comment 6, but causes also
several regressions with ... must have an explicit interface errors:
FAIL: gfortran.dg/allocatable_function_1.f90 (test for excess
--- Comment #21 from dominiq at lps dot ens dot fr 2010-07-25 10:03 ---
With the patch in comment #18, I see all the failures reported in comment #19,
plus
FAIL: gfortran.dg/whole_file_9.f90 -O (internal compiler error)
FAIL: gfortran.dg/g77/13037.f -O3 -g (internal compiler error)
--- Comment #22 from burnus at gcc dot gnu dot org 2010-07-25 10:14 ---
The patch in comment 18 causes a segfault (in gfc_generate_function_code for
cfun-function_end_locus = input_location [Invalid write of size 4]) for the
test case in PR 40011 comment 0 (the one after Your patch
--- Comment #17 from jv244 at cam dot ac dot uk 2010-07-24 18:15 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873#c1 still fails with current
trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #18 from burnus at gcc dot gnu dot org 2010-07-24 19:13 ---
(In reply to comment #17)
comment 1 still fails with current trunk
(In reply to comment #1)
subroutine two()
call three()
end subroutine two
subroutine three()
end subroutine
--- Comment #19 from burnus at gcc dot gnu dot org 2010-07-24 20:16 ---
And of course the patch won't work out of the box:
$ gfortran -O2 -g gfortran.dg/entry_array_specs_2.f ./a.out
gfortran.dg/entry_array_specs_2.f:16:0: internal compiler error: in output_die,
at dwarf2out.c:11046
--- Comment #20 from burnus at gcc dot gnu dot org 2010-07-24 22:05 ---
(In reply to comment #19)
$ gfortran -O2 -g gfortran.dg/entry_array_specs_2.f ./a.out
gfortran.dg/entry_array_specs_2.f:16:0: internal compiler error:
in output_die, at dwarf2out.c:11046
I had a closer look
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-06-09 22:10
---
Another one that fails:
subroutine func (x)
use demo
integer :: x
x = 999
end subroutine func
subroutine foo
interface
subroutine func(x)
integer :: x
end subroutine func
end interface
--- Comment #13 from burnus at gcc dot gnu dot org 2010-05-26 14:28 ---
Is this now fixed by the following commit? Or is something else to be done
(additional fix, backporting, ...)?
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159852
Log:
2010-05-26 Paul Thomas
--- Comment #14 from dominiq at lps dot ens dot fr 2010-05-26 14:41 ---
Is this now fixed by the following commit? Or is something else to be done
(additional fix, backporting, ...)?
At least ac.f90 (probably all the items of the list) fails to link with -O
-fwhole-program at
--- Comment #15 from burnus at gcc dot gnu dot org 2010-05-26 14:45 ---
(In reply to comment #13)
Is this now fixed by the following commit?
Answer: It is not. Comment 1 now works with -fwhole-program -O1, but comment
0 and comment 4 still fail. (Though, they work with -fwhole-file
--- Comment #12 from pault at gcc dot gnu dot org 2010-05-24 12:31 ---
Created an attachment (id=20734)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20734action=view)
Fix for this PR and PR40011 #42
This patch regtests OK apart from some peculiarities in proc_ptr_comp_9.f90 and
--- Comment #11 from pault at gcc dot gnu dot org 2010-05-20 13:51 ---
(In reply to comment #10)
Am I right in thinking that -fwhole-file could be enabled by default, if this
PR were to be fixed? (The appropriate changes in the testsuite would have to
be mad too.)
Paul
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-16 10:53 ---
(In reply to comment #5)
A few comments:
(1) adding -flto or -fwhopr solves the linking problem for the polyhedron
tests
and the reduced one in comment #1.
(2) the test in comment #4 is different as it
--- Comment #7 from dominiq at lps dot ens dot fr 2010-05-16 11:00 ---
-fwhole-program enables -fwhole-file.
Yes, but -fwhole-file does not enable -fwhole-program. All the polyhedron tests
pass with -fwhole-file (and say -O3 -ffast-math), but the test in comment #4
fails with
--- Comment #8 from rguenther at suse dot de 2010-05-16 11:04 ---
Subject: Re: -fwhole-file -fwhole-program: Wrong decls
cause too much to be optimized away
On Sun, 16 May 2010, dominiq at lps dot ens dot fr wrote:
--- Comment #7 from dominiq at lps dot ens dot fr 2010-05-16
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16 11:16 ---
You cant' compare -fwhole-file numbers to -fwhole-program numbers.
-fwhole-file is a correctness option, w/o it the Frontend generates
an invalid representation for the middle-end.
Well, from what I saw running
--- Comment #10 from rguenther at suse dot de 2010-05-16 11:21 ---
Subject: Re: -fwhole-file -fwhole-program: Wrong decls
cause too much to be optimized away
On Sun, 16 May 2010, dominiq at lps dot ens dot fr wrote:
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-15 19:53 ---
A few comments:
(1) adding -flto or -fwhopr solves the linking problem for the polyhedron tests
and the reduced one in comment #1.
(2) the test in comment #4 is different as it shows up for -fwhole-file and is
not
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-22 15:34 ---
Reconfirmed with current trunk. If I move three to the top of the file I
even get
/tmp/ccGHHCCU.o: In function `main':
t.f90:(.text+0x1e): undefined reference to `three_'
t.f90:(.text+0x28): undefined reference to
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-22 15:42 ---
Similar testcase from PR40011
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
gfortran
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-28 13:12 ---
We have the following cgraph nodes related to daxpy:
daxpy/17(-1) @0x75fc8700
called by: dgesl/3 (1.00 per call) dgesl/3 (1.00 per call)
calls:
dgefa/7(7) @0x75f7b100 174 time, 45 benefit 138 size, 36
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-27 14:47 ---
(Note: -fwhole-program implies -fwhole-file; the -On option is required.)
Test case. Run with -O1 -fwhole-program.
Fails with: test.f90:(.text+0x1b): undefined reference to `three_'
program prog
call
28 matches
Mail list logo
