------- 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:[EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 3:08 PM To: [EMAIL PROTECTED] 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
