On Jul 11, 2015, at 4:58 AM, Dan Nagle 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
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 hav
Hi,
> On Jul 11, 2015, at 04:36 , Andre Vehreschild 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 whethe
Le 11/07/2015 12:36, Andre Vehreschild a écrit :
> Hi,
>
>
>>"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 th
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 =
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 d
Hi,
>"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
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 functi
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 tha
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
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 alrig
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 wrote:
> On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschi
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
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 h
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:
>
> int
15 matches
Mail list logo
