Re: [RFC, Fortran, (pr66775)] Allocatable function result
On Jul 11, 2015, at 4:58 AM, Dan Nagle danlna...@mac.com wrote: The standard is written in standardese, not English. While what you say is true, sorry, shall _is_ English: used in laws, regulations, or directives to express what is mandatory
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Le 10/07/2015 20:57, Steve Kargl a écrit : On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote: I'm not completely convinced by the standard excerpts that have been quoted about this topic, as they don't have any explicit mention of allocatable variables/expressions. I did not quote 12.3.3 about characteristics of function results, which mentions the allocatable attribute. But, that is not necessarily relevant. The pieces I quoted explicitly states On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. Yeah, well, if the standard committee had allowed unallocated allocatable results, they would have put it here together with pointer, I guess. The function not only needs to allocate memory, it needs to assign it a value. In the following, if i = 0, the function result is not defined. module foo contains function bar(i) integer, allocatable :: bar integer, intent(in) :: i if (i 0) bar = i end function bar end module foo program test use foo integer j j = bar( 3); print *, j j = bar(-3); print *, j end if end program test Even if Andre developed a patch to allocate memory in bar() for the i = 0 case to prevent the segfault, the function must return a value. What should that value be? Your example is, of course, 100% invalid; a value is needed to put in j. But the case is more debatable to me, if j is allocatable. In that case an unallocated bar() result could just make j unallocated. Mikael
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi, snip On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. Now we can argue whether the shall be defined is to be interpreted as has to be or as might be. For me - being a non-native English speaker - that shall is not an obligation but should be interpreted as commonly the function result is to be defined, but there can be exceptions. Now I am curious about how native English speakers understand that standard statement. My argument on returning an unallocated object is not to support programatical errors, but rather for circumstances, where one tries to allocate a resource and on failure nothing is returned. Think about a function like try_to_acquire_resource(), when the resource could be reserved (like, for example, a co-processor), then its (private) structure is returned (implementing the OO concept of information hiding). Furthermore one could think about using concepts like memory pools, where a memory fragment is returned by a function as long as the capacity of the pool is no exhausted. This of course is more difficult in Fortran as is lacks the ways of doing C-style pointer arithmetic. This is just an example. So please don't nail me on this one. I just wanted to give you my idea, why I think returning an unallocated object should be legal for an allocatable function result. (Note, the result is called allocatable, not allocated function result :-). Meaning, that it can be allocated, but does not have to be.) When someone has other compilers available the test program is attached. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de test_pr66775.f03 Description: Binary data
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Le 11/07/2015 12:36, Andre Vehreschild a écrit : Hi, snip On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. Now we can argue whether the shall be defined is to be interpreted as has to be or as might be. For me - being a non-native English speaker - that shall is not an obligation but should be interpreted as commonly the function result is to be defined, but there can be exceptions. Now I am curious about how native English speakers understand that standard statement. I'm non-native as well, but my interpretation is has to be. :-( Which (if correct) puts this topic out of the standard territory. Mikael
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi, module foo contains function bar(i) integer, allocatable :: bar integer, intent(in) :: i if (i 0) bar = i end function bar end module foo program test use foo integer j j = bar( 3); print *, j j = bar(-3); print *, j end if end program test Even if Andre developed a patch to allocate memory in bar() for the i = 0 case to prevent the segfault, the function must return a value. What should that value be? Your example is, of course, 100% invalid; a value is needed to put in j. But the case is more debatable to me, if j is allocatable. In that case an unallocated bar() result could just make j unallocated. Yes, completely right. The example so far is not on the point I try to make. For your example Steve, the result of bar has to be allocated, no argument on that, but what about, when j is allocatable? As stated in a previous mail, that property is not called allocated, but allocatable... - Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi, On Jul 11, 2015, at 04:36 , Andre Vehreschild ve...@gmx.de wrote: On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. Now we can argue whether the shall be defined is to be interpreted as has to be or as might be. For me - being a non-native English speaker - that shall is not an obligation but should be interpreted as commonly the function result is to be defined, but there can be exceptions. Now I am curious about how native English speakers understand that standard statement. The standard is written in standardese, not English. “Shall” is a requirement. Full stop. -- Cheers! Dan Nagle
Re: [RFC, Fortran, (pr66775)] Allocatable function result
On Sat, Jul 11, 2015 at 12:54:33PM +0200, Mikael Morin wrote: Le 10/07/2015 20:57, Steve Kargl a ?crit : On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote: I'm not completely convinced by the standard excerpts that have been quoted about this topic, as they don't have any explicit mention of allocatable variables/expressions. I did not quote 12.3.3 about characteristics of function results, which mentions the allocatable attribute. But, that is not necessarily relevant. The pieces I quoted explicitly states On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. Yeah, well, if the standard committee had allowed unallocated allocatable results, they would have put it here together with pointer, I guess. From F95, 6.3.1.1. An allocatable array that has been allocated by an ALLOCATE statement and has not been subsequently deallocated (6.3.3) is currently allocated and is definable. Note it is definable. It is not defined. I cannot find a similar statement in F08 due to the massive rewrite of the standard to accommodate new features (e.g., co-arrays and allocation-on-assignment). F08 6.7.1.3 does say The allocation status of an allocatable entity is one of the following at any time. * The status of an allocatable variable becomes allocated if it is allocated by and ALLOCATE statement, if it allocated during assignment, or if it is given that status by the intrinsic subroutine MOVE_ALLOC (13.7.118). An allocatable variable with this status my be referenced, defined, or deallocated; ... * An allocatable variable has a status of unallocated if it is not allocated. The status of an allocatable variable becomes unallocated if it is deallocated (6.7.3) or if it is given that status by the allocation transfer procedure. So, change my example to what you want module foo contains function bar(i) integer, allocatable :: bar integer, intent(in) :: i if (i 0) bar = i end function bar end module foo program test use foo integer, allocatable :: j j = bar( 3); if (allocated(j)) print *, j j = bar(-3); if (allocated(j)) print *, j end program test So, it seems you want the allocation status of j in 'j = bar(-3)' to be unallocated due to the allocation-on-assignment feature of f08. I'll simply note that *there is no assignment* as bar(-3) does not return an a value, which is required by If the function result is not a pointer, its value shall be defined by the function. So, you want unallocation-on-nonassignment, which is not in the standard. -- steve
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi all, this means that pr66775 is to be closed as resolved invalid, because the current implementation is alright, but only the program to compile is garbage. Ok, suits me. - Andre On Thu, 9 Jul 2015 12:41:31 -0700 Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote: Hi Steve, Thanks for your knowledge. Can you support your statement that an allocatable function has to return an allocated object by a part of the standard? I totally agree with you that this code is ill-designed, but IMO is it not the task of the compiler to address ill design. The compiler has to comply to the standard and the standard allows allocatable objects to be unallocated. So why has the result of a function be allocated always? Regards, Andre I think the following excerpts from F2008 are the relevant clauses, especially the 2nd to last sentence in the excerpt from 12.6.2.2. ! 12.5.3 ! ! When execution of the function is complete, the value of ! the function result is available for use in the expression ! that caused the function to be invoked. ! ! 12.6.2.2 ! ! If RESULT appears, the name of the result variable of the ! function is result-name and all occurrences of the function ! name in execution-part statements in its scope refer to the ! function itself. If RESULT does not appear, the name of the ! result variable is function-name and all occurrences of the ! function name in execution-part statements in its scope are ! references to the result variable. The characteristics (12.3.3) ! of the function result are those of the result variable. On ! completion of execution of the function, the value returned is ! that of its result variable. If the function result is a pointer, ! the shape of the value returned by the function is determined by ! the shape of the result variable when the execution of the function ! is completed. If the result variable is not a pointer, its value ! shall be defined by the function. If the function result is a ! pointer, on return the pointer association status of the result ! variable shall not be undefined. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Yes, it should be closed. When I asked you to open it, I thought the issue was a corner case in your patch. -- steve On Fri, Jul 10, 2015 at 11:44:32AM +0200, Andre Vehreschild wrote: this means that pr66775 is to be closed as resolved invalid, because the current implementation is alright, but only the program to compile is garbage. Ok, suits me. - Andre On Thu, 9 Jul 2015 12:41:31 -0700 Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote: Hi Steve, Thanks for your knowledge. Can you support your statement that an allocatable function has to return an allocated object by a part of the standard? I totally agree with you that this code is ill-designed, but IMO is it not the task of the compiler to address ill design. The compiler has to comply to the standard and the standard allows allocatable objects to be unallocated. So why has the result of a function be allocated always? Regards, Andre I think the following excerpts from F2008 are the relevant clauses, especially the 2nd to last sentence in the excerpt from 12.6.2.2. ! 12.5.3 ! ! When execution of the function is complete, the value of ! the function result is available for use in the expression ! that caused the function to be invoked. ! ! 12.6.2.2 ! ! If RESULT appears, the name of the result variable of the ! function is result-name and all occurrences of the function ! name in execution-part statements in its scope refer to the ! function itself. If RESULT does not appear, the name of the ! result variable is function-name and all occurrences of the ! function name in execution-part statements in its scope are ! references to the result variable. The characteristics (12.3.3) ! of the function result are those of the result variable. On ! completion of execution of the function, the value returned is ! that of its result variable. If the function result is a pointer, ! the shape of the value returned by the function is determined by ! the shape of the result variable when the execution of the function ! is completed. If the result variable is not a pointer, its value ! shall be defined by the function. If the function result is a ! pointer, on return the pointer association status of the result ! variable shall not be undefined. -- Andre Vehreschild * Email: vehre ad gmx dot de -- Steve
Re: [RFC, Fortran, (pr66775)] Allocatable function result
On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote: I'm not completely convinced by the standard excerpts that have been quoted about this topic, as they don't have any explicit mention of allocatable variables/expressions. I did not quote 12.3.3 about characteristics of function results, which mentions the allocatable attribute. But, that is not necessarily relevant. The pieces I quoted explicitly states On completion of execution of the function, the value returned is that of its function result. ... If the function result is not a pointer, its value shall be defined by the function. The function not only needs to allocate memory, it needs to assign it a value. In the following, if i = 0, the function result is not defined. module foo contains function bar(i) integer, allocatable :: bar integer, intent(in) :: i if (i 0) bar = i end function bar end module foo program test use foo integer j j = bar( 3); print *, j j = bar(-3); print *, j end if end program test Even if Andre developed a patch to allocate memory in bar() for the i = 0 case to prevent the segfault, the function must return a value. What should that value be? I suppose one could argue that gfortran should issue a run-time error if it can detect the undefined function result. But may lead to a run-time penalty. -- Steve
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hello all, I'm not completely convinced by the standard excerpts that have been quoted about this topic, as they don't have any explicit mention of allocatable variables/expressions. For what it's worth, in my opinion, the handling of allocatable that was proposed by Andre makes sense to me. It's consistent with what is done for derived type assignment, the lhs' allocatable components are deallocated if their rhs counter part are unallocated. Doing the same for whole objects would be, well, consistent. What is done by the other compilers? Mikael
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi Mikael, hi all, I only had the chance to check with ifort (different versions; including the most recent one) and that compiler is consistent with gfortran as it is now, I.e., the executable segfaults after the function has been called. I am though curious what other compilers opinion on that point is. Regards, Andre Am 10. Juli 2015 18:20:47 MESZ, schrieb Mikael Morin mikael.mo...@sfr.fr: Hello all, I'm not completely convinced by the standard excerpts that have been quoted about this topic, as they don't have any explicit mention of allocatable variables/expressions. For what it's worth, in my opinion, the handling of allocatable that was proposed by Andre makes sense to me. It's consistent with what is done for derived type assignment, the lhs' allocatable components are deallocated if their rhs counter part are unallocated. Doing the same for whole objects would be, well, consistent. What is done by the other compilers? Mikael -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Mail: ve...@gmx.de * Tel.: +49 241 9291018
Re: [RFC, Fortran, (pr66775)] Allocatable function result
Hi Steve, Thanks for your knowledge. Can you support your statement that an allocatable function has to return an allocated object by a part of the standard? I totally agree with you that this code is ill-designed, but IMO is it not the task of the compiler to address ill design. The compiler has to comply to the standard and the standard allows allocatable objects to be unallocated. So why has the result of a function be allocated always? Regards, Andre Am 9. Juli 2015 19:50:47 MESZ, schrieb Steve Kargl s...@troutmask.apl.washington.edu: On Thu, Jul 09, 2015 at 12:25:18PM +0200, Andre Vehreschild wrote: I need your help on how to interpret the standard(s) or how to implement handling an allocatable function's result, when that result is not allocated by the function. Imagine the simple (albeit artificial) case: integer function read_input() read_input = ... end function integer function getNext() allocatable :: getNext if (more_input_available ()) getNext = read_input() end function where the function getNext () returns an (automatically) allocated result when more_input_available() returns .true.. Otherwise getNext () returns an unallocated object, i.e., the result's allocation status is .false.. I don't want to argue about this design's quality (considering it poor myself). I suppose that this code is legal, right? Code is both valid and invalid. As you point out, it depends on the return value of more_input_available(). Also, note, it is always invalid under -std=f95 as it is using automatic (re-)allocation of the LHS. Unfortunately gfortran can not handle it currently. Whatever gfortran does is correct, because the code is invalid in the more_input_available() = .false. case. It is the responsible of the programmer to ensure that getNext() has an allocated and assigned value before it returns. IHMO, I think that gfortran should not try to guess what the programmer might have intended. Yes, the compiled code may dereference a possibly invalid pointer. The compiled program should segfault, and the programmer should fix the Fortran code. function getNext() allocatable :: getNext if (more_input_available ()) getNext = read_input() else allocate(getNext, source=some_error_code?) end if end function or function getNext() allocatable :: getNext allocate(getNext, source=some_error_code?) if (more_input_available ()) getNext = read_input() end function -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Mail: ve...@gmx.de * Tel.: +49 241 9291018
Re: [RFC, Fortran, (pr66775)] Allocatable function result
On Thu, Jul 09, 2015 at 12:25:18PM +0200, Andre Vehreschild wrote: I need your help on how to interpret the standard(s) or how to implement handling an allocatable function's result, when that result is not allocated by the function. Imagine the simple (albeit artificial) case: integer function read_input() read_input = ... end function integer function getNext() allocatable :: getNext if (more_input_available ()) getNext = read_input() end function where the function getNext () returns an (automatically) allocated result when more_input_available() returns .true.. Otherwise getNext () returns an unallocated object, i.e., the result's allocation status is .false.. I don't want to argue about this design's quality (considering it poor myself). I suppose that this code is legal, right? Code is both valid and invalid. As you point out, it depends on the return value of more_input_available(). Also, note, it is always invalid under -std=f95 as it is using automatic (re-)allocation of the LHS. Unfortunately gfortran can not handle it currently. Whatever gfortran does is correct, because the code is invalid in the more_input_available() = .false. case. It is the responsible of the programmer to ensure that getNext() has an allocated and assigned value before it returns. IHMO, I think that gfortran should not try to guess what the programmer might have intended. Yes, the compiled code may dereference a possibly invalid pointer. The compiled program should segfault, and the programmer should fix the Fortran code. function getNext() allocatable :: getNext if (more_input_available ()) getNext = read_input() else allocate(getNext, source=some_error_code?) end if end function or function getNext() allocatable :: getNext allocate(getNext, source=some_error_code?) if (more_input_available ()) getNext = read_input() end function -- Steve
Re: [RFC, Fortran, (pr66775)] Allocatable function result
On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote: Hi Steve, Thanks for your knowledge. Can you support your statement that an allocatable function has to return an allocated object by a part of the standard? I totally agree with you that this code is ill-designed, but IMO is it not the task of the compiler to address ill design. The compiler has to comply to the standard and the standard allows allocatable objects to be unallocated. So why has the result of a function be allocated always? Regards, Andre I think the following excerpts from F2008 are the relevant clauses, especially the 2nd to last sentence in the excerpt from 12.6.2.2. ! 12.5.3 ! ! When execution of the function is complete, the value of ! the function result is available for use in the expression ! that caused the function to be invoked. ! ! 12.6.2.2 ! ! If RESULT appears, the name of the result variable of the ! function is result-name and all occurrences of the function ! name in execution-part statements in its scope refer to the ! function itself. If RESULT does not appear, the name of the ! result variable is function-name and all occurrences of the ! function name in execution-part statements in its scope are ! references to the result variable. The characteristics (12.3.3) ! of the function result are those of the result variable. On ! completion of execution of the function, the value returned is ! that of its result variable. If the function result is a pointer, ! the shape of the value returned by the function is determined by ! the shape of the result variable when the execution of the function ! is completed. If the result variable is not a pointer, its value ! shall be defined by the function. If the function result is a ! pointer, on return the pointer association status of the result ! variable shall not be undefined. -- Steve
