* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
@ 2007-12-21 4:50 ` jon_d_r at msn dot com
2007-12-21 4:57 ` jon_d_r at msn dot com
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jon_d_r at msn dot com @ 2007-12-21 4:50 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from jon_d_r at msn dot com 2007-12-21 04:50 -------
Created an attachment (id=14803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14803&action=view)
Source code that causes ICE
This is the code that caused the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
2007-12-21 4:50 ` [Bug fortran/34545] " jon_d_r at msn dot com
@ 2007-12-21 4:57 ` jon_d_r at msn dot com
2007-12-21 6:09 ` jv244 at cam dot ac dot uk
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jon_d_r at msn dot com @ 2007-12-21 4:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from jon_d_r at msn dot com 2007-12-21 04:57 -------
Downloaded and installed later version of gfortran.
GNU F95 (GCC) version 4.3.0 20071130 (experimental) [trunk revision 130537]
I still get ICE:
G:\fortran\KMeansClust>gfortran -v -Wall -save-temps kmeans.f90
Driving: gfortran -v -Wall -save-temps kmeans.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld
-
-with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads
--disable-nls --build=i386-pc-mingw32 --enable-libgomp -
-disable-shared
Thread model: win32
gcc version 4.3.0 20071130 (experimental) [trunk revision 130537] (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-save-temps' '-mtune=i386'
c:/program files/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe
kmeans.f90 -quiet -dumpbase kmeans.f90 -mtune=i386 -aux
base kmeans -Wall -version -fintrinsic-modules-path c:/program
files/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o kmean
s.s
GNU F95 (GCC) version 4.3.0 20071130 (experimental) [trunk revision 130537]
(i386-pc-mingw32)
compiled by GNU C version 4.3.0 20071130 (experimental) [trunk revision
130537], GMP version 4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
kmeans.f90: In function 'kmeans_driver':
kmeans.f90:2054: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
jon_d_r at msn dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jon_d_r at msn dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
2007-12-21 4:50 ` [Bug fortran/34545] " jon_d_r at msn dot com
2007-12-21 4:57 ` jon_d_r at msn dot com
@ 2007-12-21 6:09 ` jv244 at cam dot ac dot uk
2007-12-21 6:14 ` kargl at gcc dot gnu dot org
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jv244 at cam dot ac dot uk @ 2007-12-21 6:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from jv244 at cam dot ac dot uk 2007-12-21 06:09 -------
code compiles fine with NAG and g95, the line at the segfault looks OK.
--
jv244 at cam dot ac dot uk changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |32834
nThis| |
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2007-12-21 06:09:04
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (2 preceding siblings ...)
2007-12-21 6:09 ` jv244 at cam dot ac dot uk
@ 2007-12-21 6:14 ` kargl at gcc dot gnu dot org
2007-12-21 7:39 ` burnus at gcc dot gnu dot org
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-12-21 6:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from kargl at gcc dot gnu dot org 2007-12-21 06:14 -------
Here's a reduced testcase.
module const_mod
implicit none
integer, parameter :: mp = selected_real_kind(15,300)
end module const_mod
module blk1_mod
implicit none
integer :: numclusters = 2
end module blk1_mod
module kmeans_aux
implicit none
contains
function get_nfirst( ) result(fnres)
use const_mod, only: mp
use blk1_mod, only: numclusters
implicit none
real(mp) :: fnres(numclusters)
end function get_nfirst
end module kmeans_aux
program kmeans_driver
use blk1_mod
use kmeans_aux
implicit none
integer, allocatable :: nfirst(:)
allocate(nfirst(1:numclusters))
nfirst(1:numclusters) = get_nfirst( )
end program kmeans_driver
--
kargl at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (3 preceding siblings ...)
2007-12-21 6:14 ` kargl at gcc dot gnu dot org
@ 2007-12-21 7:39 ` burnus at gcc dot gnu dot org
2007-12-21 9:47 ` dfranke at gcc dot gnu dot org
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-12-21 7:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from burnus at gcc dot gnu dot org 2007-12-21 07:39 -------
valgrind:
==6521== Invalid read of size 1
==6521== at 0x49C7D0: gfc_get_symbol_decl (trans-decl.c:899)
==6521== by 0x4A47DC: gfc_conv_variable (trans-expr.c:424)
==6521== by 0x4A7079: gfc_apply_interface_mapping (trans-expr.c:1949)
==6521== by 0x486BFA: gfc_set_loop_bounds_from_array_spec
(trans-array.c:474)
==6521== by 0x4A16C3: gfc_conv_function_call (trans-expr.c:2633)
==6521== by 0x4A2398: gfc_conv_function_expr (trans-expr.c:3050)
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
Known to fail| |4.1.3 4.2.2 4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (4 preceding siblings ...)
2007-12-21 7:39 ` burnus at gcc dot gnu dot org
@ 2007-12-21 9:47 ` dfranke at gcc dot gnu dot org
2007-12-21 12:28 ` pinskia at gcc dot gnu dot org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dfranke at gcc dot gnu dot org @ 2007-12-21 9:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from dfranke at gcc dot gnu dot org 2007-12-21 09:47 -------
I can not reproduce the valgrind error, but ...
> module blk1_mod
> implicit none
> integer :: numclusters = 2
> end module blk1_mod
... the ICE goes away if 'numclusters' is defined as a parameter.
Further reduced testcase:
module blk1_mod
implicit none
integer :: numclusters = 2
end module blk1_mod
module kmeans_aux
implicit none
contains
function get_nfirst( ) result(fnres)
use blk1_mod, only: numclusters
implicit none
real :: fnres(numclusters)
end function get_nfirst
end module kmeans_aux
program kmeans_driver
use blk1_mod
use kmeans_aux
implicit none
integer, allocatable :: nfirst(:)
allocate(nfirst(1:numclusters))
nfirst(1:numclusters) = get_nfirst( )
end program kmeans_driver
--
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=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (5 preceding siblings ...)
2007-12-21 9:47 ` dfranke at gcc dot gnu dot org
@ 2007-12-21 12:28 ` pinskia at gcc dot gnu dot org
2007-12-26 18:36 ` jon_d_r at msn dot com
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-12-21 12:28 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
Severity|critical |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (6 preceding siblings ...)
2007-12-21 12:28 ` pinskia at gcc dot gnu dot org
@ 2007-12-26 18:36 ` jon_d_r at msn dot com
2007-12-26 22:07 ` kargl at gcc dot gnu dot org
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jon_d_r at msn dot com @ 2007-12-26 18:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from jon_d_r at msn dot com 2007-12-26 18:36 -------
Maybe this should best be described as:
"ICE when function returns array of values to dynamically allocated array"
If the LHS is a 'statically allocated' array, the function returns array of
values without problem. If the LHS is a dynamically allocated array,
attempting to assign the array of values from the functions causes an ICE.
So gfortran fails to implement an essential feature of Fortran 95.
Workaround is to call a subroutine and have the array of values returned in the
argument list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (7 preceding siblings ...)
2007-12-26 18:36 ` jon_d_r at msn dot com
@ 2007-12-26 22:07 ` kargl at gcc dot gnu dot org
2007-12-27 10:34 ` jon_d_r at msn dot com
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-12-26 22:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from kargl at gcc dot gnu dot org 2007-12-26 22:07 -------
(In reply to comment #7)
> Maybe this should best be described as:
> "ICE when function returns array of values to dynamically allocated array"
> If the LHS is a 'statically allocated' array, the function returns array of
> values without problem. If the LHS is a dynamically allocated array,
> attempting to assign the array of values from the functions causes an ICE.
Well, no. A better description probably involves the use of stack
memory for a function result gets trashed when you return from
the function.
I can assure that gfortran can assign array function results to
allocated memory. You appear to have stumbled on a bug.
>
> So gfortran fails to implement an essential feature of Fortran 95.
>
This statement is in rather poor taste, and is an example of why I
quit working on gfortran. But, thanks for the bug report.
> Workaround is to call a subroutine and have the array of values
> returned in the argument list.
One can also learn to do proper memory management.
module kmeans_aux
implicit none
contains
function get_nfirst( ) result(fnres)
use const_mod, only: mp
use blk1_mod, only: numclusters
implicit none
! real(mp) :: fnres(numbcluster) ! This uses the stack instead of heap.
real(mp), allocatable :: fnres(:) ! Properly manage heap memory
if (allocated(fnres) .eqv. .true.) deallocate(fnres)
allocate(fnres(numclusters))
fnres = 1
end function get_nfirst
end module kmeans_aux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (8 preceding siblings ...)
2007-12-26 22:07 ` kargl at gcc dot gnu dot org
@ 2007-12-27 10:34 ` jon_d_r at msn dot com
2007-12-29 8:57 ` dfranke at gcc dot gnu dot org
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jon_d_r at msn dot com @ 2007-12-27 10:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from jon_d_r at msn dot com 2007-12-27 10:33 -------
Subject: RE: ICE when compiling Fortran 95 code
-----Original Message-----
From: kargl at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org]
Sent: Wednesday, December 26, 2007 3:08 PM
To: jon_d_r@msn.com
Subject: [Bug fortran/34545] ICE when compiling Fortran 95 code
------- Comment #8 from kargl at gcc dot gnu dot org 2007-12-26 22:07
------- (In reply to comment #7)
> Maybe this should best be described as:
> "ICE when function returns array of values to dynamically allocated
array"
> If the LHS is a 'statically allocated' array, the function returns
> array of values without problem. If the LHS is a dynamically
> allocated array, attempting to assign the array of values from the
functions causes an ICE.
Well, no. A better description probably involves the use of stack memory
for a function result gets trashed when you return from the .function.
I can assure that gfortran can assign array function results to allocated
memory. You appear to have stumbled on a bug.
>
> So gfortran fails to implement an essential feature of Fortran 95.
>
This statement is in rather poor taste, and is an example of why I quit
working on gfortran. But, thanks for the bug report.
I really apologize if this seemed harsh. When I learned to program, I tried
to become less sensitive to apparent critisism, because often it wasn't
meant in the manner I interpreted it. That wasn't supposed to be a hurtful
comment. My point may have been off, but what I was saying (awkwardly) was
that (in my mind) if the compiler can't do what is expected according to the
standard, then it fails to perform up to standard. Fortran itself doesn't
recognise nor care whether values are in stack or heap memory, it does
require that code is produced so that values are returned from the function.
Fortran is agnostic about implementation details. But, yes, it is good for
the programmer to be aware. I'm fairly satisfied with gfortran, really.
When I first encountered the problem, I had no idea what was causing it. I
really do admire your quick and succinct analysis, resulting in a small test
case that exhibits the problem. I never could have done that. (At least in
a reasonable time). You'll never know how much I admire the skill you show
in your work, and how much I appreciate it. Thanks.
> Workaround is to call a subroutine and have the array of values
> returned in the argument list.
One can also learn to do proper memory management.
module kmeans_aux
implicit none
contains
function get_nfirst( ) result(fnres)
use const_mod, only: mp
use blk1_mod, only: numclusters
implicit none
! real(mp) :: fnres(numbcluster) ! This uses the stack instead of
heap.
real(mp), allocatable :: fnres(:) ! Properly manage heap memory
if (allocated(fnres)) deallocate(fnres)
allocate(fnres(1:numclusters), stat=istat) ! and check if the
allocation apparently worked.
fnres = 1
end function get_nfirst
end module kmeans_aux
Yes, that is a really good way, and I do generally do allocations like this.
Realize that I am refactoring some very old code here, and what you see is
only phase one. This is actually the first time I'd used the particular
pattern that caused the problem. The original code had several hundred lines
in the main program. I simply excised sections (cut/paste) into separate
procedures, while still retaining the essense of the common blocks. This was
a quick and dirty chunking of the original code: this is not in my style
when I write code de novo.
The second phase would be to rewrite the main program and remove the
spaghetti code. Then, with the ability to see where the former elements of
the common blocks are active, I'd completely rearrange where and how memory
is allocated. I'd prefer to remove the apparent globalization of many of the
arrays. I'd like to hide them as far as possible from the main program,
which I like to see as the user's view of the problem. All the elements not
relating to the user's problem would be hidden away in the modules. The
original Fortran 77 code, with static array sizes, had all these arrays
upfront.
Actually the partially refactored code is working now. I'm disappointed in
how it works, but that is a problem I have with cluster analysis itself
<grin>.
In the future, I'll simply report the bugs and keep away from what might
seem as value judgements. Lesson learned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (9 preceding siblings ...)
2007-12-27 10:34 ` jon_d_r at msn dot com
@ 2007-12-29 8:57 ` dfranke at gcc dot gnu dot org
2008-01-01 17:11 ` pault at gcc dot gnu dot org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dfranke at gcc dot gnu dot org @ 2007-12-29 8:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from dfranke at gcc dot gnu dot org 2007-12-29 08:57 -------
I'm only passing through, but ...
Jon:
> > If the LHS is a dynamically allocated array, attempting
> > to assign the array of values from the functions causes an ICE.
Steve:
> Well, no. A better description probably involves the use of stack
> memory for a function result gets trashed when you return from
> the function.
rings a bell. This is maybe related to PR32795?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (10 preceding siblings ...)
2007-12-29 8:57 ` dfranke at gcc dot gnu dot org
@ 2008-01-01 17:11 ` pault at gcc dot gnu dot org
2008-01-01 17:24 ` pault at gcc dot gnu dot org
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pault at gcc dot gnu dot org @ 2008-01-01 17:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from pault at gcc dot gnu dot org 2008-01-01 17:11 -------
This is a most peculiar bug, which has nothing to do with allocatability or
temporariness. The result variables of the functions 'get_numbr' and
'get_nfirst' are REAL(mp), whereas they are assigned to INTEGER arrays.
Changing the results to INTEGER in the original clears the problem and, up to
missing input files, the code seems OK.
This very much reduced example illustrates the problem:
module m1
integer :: numclusters = 2
end module m1
module m2
contains
function get_nfirst( ) result(fnres)
use m1, only: numclusters
real :: fnres(numclusters) ! change to REAL and it works!!
end function get_nfirst
end module m2
program kmeans_driver
use m1
use m2
integer :: nfirst(3)
nfirst(1:numclusters) = get_nfirst( )
end program kmeans_driver
Alternatively, moving the USE m1 in 'get_nfirst' to be a module specification
statement, fixes the problem.....:)
I'm thinking about it; the offending version of numclusters is linked to a
namespace that has no proc_name. Why this should cause problems when there is
a type mismatch, I have no idea.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (11 preceding siblings ...)
2008-01-01 17:11 ` pault at gcc dot gnu dot org
@ 2008-01-01 17:24 ` pault at gcc dot gnu dot org
2008-01-01 22:47 ` dominiq at lps dot ens dot fr
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pault at gcc dot gnu dot org @ 2008-01-01 17:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from pault at gcc dot gnu dot org 2008-01-01 17:23 -------
Ah! I feel a light bulb moment coming on.
The type mismatch necessitates the use of the internal real to integer
conversion function, which in its turn checks the interface with 'get_nfirst'.
Being a formal argument to a use associated function, 'numclusters' seems to
wind up with a bad namespace. I have encountered this before and should now
sort it out properly. A kludgy fix is:
Index: ../trunk/gcc/fortran/trans-decl.c
===================================================================
*** ../trunk/gcc/fortran/trans-decl.c (revision 131237)
--- ../trunk/gcc/fortran/trans-decl.c (working copy)
*************** gfc_get_symbol_decl (gfc_symbol * sym)
*** 896,901 ****
--- 896,904 ----
|| sym->attr.use_assoc
|| sym->ns->proc_name->attr.if_source == IFSRC_IFBODY);
+ if (sym->ns && !sym->ns->proc_name)
+ sym->ns = gfc_current_ns;
+
if (sym->ns && sym->ns->proc_name->attr.function)
byref = gfc_return_by_reference (sym->ns->proc_name);
else
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|NEW |ASSIGNED
Last reconfirmed|2007-12-21 06:09:04 |2008-01-01 17:23:35
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (12 preceding siblings ...)
2008-01-01 17:24 ` pault at gcc dot gnu dot org
@ 2008-01-01 22:47 ` dominiq at lps dot ens dot fr
2008-01-02 21:57 ` pault at gcc dot gnu dot org
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens dot fr @ 2008-01-01 22:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from dominiq at lps dot ens dot fr 2008-01-01 22:47 -------
The patch in comment #12 works as advertised without regression in 32 and 64
bit modes on ppc/Intel and my favourite platform.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (13 preceding siblings ...)
2008-01-01 22:47 ` dominiq at lps dot ens dot fr
@ 2008-01-02 21:57 ` pault at gcc dot gnu dot org
2008-01-06 19:36 ` burnus at gcc dot gnu dot org
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: pault at gcc dot gnu dot org @ 2008-01-02 21:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from pault at gcc dot gnu dot org 2008-01-02 21:00 -------
(In reply to comment #13)
> The patch in comment #12 works as advertised without regression in 32 and 64
> bit modes on ppc/Intel and my favourite platform.
>
Thanks for the test. I have been through several variants and think that this
is the most hygenic:
Index: gcc/fortran/module.c
===================================================================
*** gcc/fortran/module.c (revision 131237)
--- gcc/fortran/module.c (working copy)
*************** load_needed (pointer_info *p)
*** 3525,3530 ****
--- 3525,3536 ----
associate_integer_pointer (q, ns);
}
+ /* Use the module sym as 'proc_name' so that gfc_get_symbol_decl
+ doesn't go pear-shaped if the symbol is used. */
+ if (!ns->proc_name)
+ gfc_find_symbol (p->u.rsym.module, gfc_current_ns,
+ 1, &ns->proc_name);
+
sym = gfc_new_symbol (p->u.rsym.true_name, ns);
sym->module = gfc_get_string (p->u.rsym.module);
strcpy (sym->binding_label, p->u.rsym.binding_label);
I'm going to regtest in a few minutes but I'm confident that it's OK. It has
the advantage too that -fdump-parse-tree produces soemthing useful.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (14 preceding siblings ...)
2008-01-02 21:57 ` pault at gcc dot gnu dot org
@ 2008-01-06 19:36 ` burnus at gcc dot gnu dot org
2008-01-06 21:37 ` paulthomas2 at wanadoo dot fr
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: burnus at gcc dot gnu dot org @ 2008-01-06 19:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from burnus at gcc dot gnu dot org 2008-01-06 18:48 -------
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00017.html
Paul, what is with your patch (see above)? (I OKed it a few days ago.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (15 preceding siblings ...)
2008-01-06 19:36 ` burnus at gcc dot gnu dot org
@ 2008-01-06 21:37 ` paulthomas2 at wanadoo dot fr
2008-01-06 22:15 ` pault at gcc dot gnu dot org
2008-01-07 10:05 ` pault at gcc dot gnu dot org
18 siblings, 0 replies; 20+ messages in thread
From: paulthomas2 at wanadoo dot fr @ 2008-01-06 21:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from paulthomas2 at wanadoo dot fr 2008-01-06 20:39 -------
Subject: Re: ICE when compiling Fortran 95 code
Tobias,
Nothing - I have just updated to FC8 and blew all my nice set-up to
pieces. This is the first time that Fedora has let me down. I will be
operational first thing tomorrow morning - I just got back in action
about 20 minutes ago but am too dog-tired to do anything right now.
BTW The PR34431 etc. patch is coming along. I have cured all the
regressions but have found other, very curious bugs.
eg.
integer (kind(1_8)) foo ()
fails with the patch. The bailing out to defer kind association until
USE and IMPORT are over is too soon - the kind expression needs to be
converted and, on the basis of the expression, the deferral mechanism
triggered. I think that it is sufficient to do this if the expression
contains a variable.
I am pretty sure that I know what I have to do to complete this but it
will take a couple of days yet. I'll tidy up the statement decoding,
whilst I am about it.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (16 preceding siblings ...)
2008-01-06 21:37 ` paulthomas2 at wanadoo dot fr
@ 2008-01-06 22:15 ` pault at gcc dot gnu dot org
2008-01-07 10:05 ` pault at gcc dot gnu dot org
18 siblings, 0 replies; 20+ messages in thread
From: pault at gcc dot gnu dot org @ 2008-01-06 22:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from pault at gcc dot gnu dot org 2008-01-06 22:00 -------
Subject: Bug 34545
Author: pault
Date: Sun Jan 6 22:00:00 2008
New Revision: 131364
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131364
Log:
2008-01-06 Paul Thomas <pault@gcc.gnu.org>
PR fortran/34545
* module.c (load_needed): If the namespace has no proc_name
give it the module symbol.
2008-01-06 Paul Thomas <pault@gcc.gnu.org>
PR fortran/34545
* gfortran.dg/use_12.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/use_12.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug fortran/34545] ICE when compiling Fortran 95 code
2007-12-21 4:47 [Bug fortran/34545] New: ICE when compiling Fortran 95 code jon_d_r at msn dot com
` (17 preceding siblings ...)
2008-01-06 22:15 ` pault at gcc dot gnu dot org
@ 2008-01-07 10:05 ` pault at gcc dot gnu dot org
18 siblings, 0 replies; 20+ messages in thread
From: pault at gcc dot gnu dot org @ 2008-01-07 10:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from pault at gcc dot gnu dot org 2008-01-07 08:15 -------
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
^ permalink raw reply [flat|nested] 20+ messages in thread