From: Paul van Delst on
Richard Maine wrote:
> Paul van Delst <paul.vandelst(a)noaa.gov> wrote:
>
>> Arno wrote:
>
>>> Find below a piece of code that gives a run-time error with the ifort
>>> compiler. I thought this to be legal code, but maybe I am overlooking
>>> something.
>
> [code elided]
>> What happens if you declare the string arguments as
>>
>> character(*),intent(in),optional :: str
>>
>> (which you should do all the time anyway)
>
> While I agree with that as good advice, it does not relate to the
> legality of the code. I see nothing wrong with the original code in
> terms of the standard.

Neither did I (not that that means much! :o) but I don't have handy access to a copy of
the standard (or text) so I took the lazy "Try This" route [apologies to the OP]. I was
reasonably sure that it shouldn't matter if one did
character(*)
or
character(9)
but as I have never used the latter form for dummy arguments, I had no first hand
experience to relate.

cheers,

paulv
From: Gordon Sande on
On 2009-09-22 13:40:46 -0300, nospam(a)see.signature (Richard Maine) said:

> Gordon Sande <g.sande(a)worldnet.att.net> wrote:
>
>> Perhpas you meant
>>
>> if ( present (str ) ) then
>> call show ( str )
>> else
>> call show ( )
>> end if
>>
>> as the property of being present does not "pass through" in
>> the way you seem to expect.
>
> Eh? I thought the standard went out of its way to be quite explicit that
> it does pass through exactly like that. Otherwise, things rapidly get
> very awkward when you extend the above workaround construct to multiple
> optional arguments. Looks to me like the standard even repeats itself, I
> suppose to make sure that the point comes across. See 12.4.1.6 of F2003
> (and this same stuff is in f90 and f95 - not new to f2003),
> "Restrictions on dummy arguments not present." First sentence of the
> section:
>
> "A dummy argument... is not present if the dummy argument...
> (2) is associated with an actual argument that is not present."
>
> In case someone missed that, the last sentence in the section says
>
> "Except as noted in the list above, it [a dummy arg that is not
> present] may be supplied as an actual argument corresponding to an
> optional dummy argument, which is then also considered to be not
> associated with an actual argument."

Oops! Reverse engineering from diagnostics to problem did not work as intended.
Excess caution from making simple cases "more readily understood" does not
generalize very well either.

Thank heavens I was wrong as it would be rather awkward for more than one
optional arguement if one had to sort through all the combinations.


From: fj on
On 22 sep, 17:19, Arno <arnoinp...(a)hotmail.com> wrote:
> Dear all,
>
> Find below a piece of code that gives a run-time error with the ifort
> compiler. I thought this to be legal code, but maybe I am overlooking
> something.
>
> Thanks in advance,
>
> Arno
>
> ===========================
> file 1 (main.f90)
>
> program main
>   use my_module
>   call wrapper()
> end program main
>
> ===========================
>
> file 2 (my_module.f90)
>
> module my_module
>
> contains
>
> subroutine wrapper(str)
>   character(9),intent(in),optional :: str
>   call show(str)
> end subroutine wrapper
>
> subroutine show(str)
>   character(9),intent(in),optional :: str
>   if (present(str)) write(*,*) str
> end subroutine show
>
> end module my_module
>
> ==========================
>
> % ifort -V
> Intel(R) Fortran Compiler Professional for applications running on
> IA-32, Version 11.1    Build 20090630 Package ID: l_cprof_p_11.1.046
> Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.
> % ifort  -traceback -ftrapuv -fp-stack-check -check all my_module.f90
> main.f90
> % a.out
> forrtl: severe (408): fort: (18): Dummy character variable 'STR' has
> length 9 which is greater then actual variable length 0
>
> Image              PC        Routine            Line        Source
> a.out              08093FED  Unknown               Unknown  Unknown
> a.out              08092DE5  Unknown               Unknown  Unknown
> a.out              0805FDC8  Unknown               Unknown  Unknown
> a.out              0804ADA9  Unknown               Unknown  Unknown
> a.out              0804B078  Unknown               Unknown  Unknown
> a.out              08049D19  my_module_mp_wrap          11
> my_module.f90
> a.out              08049F5C  MAIN__                      5  main.f90
> a.out              08049CB1  Unknown               Unknown  Unknown
> libc.so.6          B7DAA455  Unknown               Unknown  Unknown
> a.out              08049BC1  Unknown               Unknown  Unknown

Declaring CHARACTER(*) any dummy character argument is always a good
advice (as mentioned by Paul).

Anyway, as mentioned by R. Maine, there is no mistake in your example.
So you should report your problem to the intel FORTRAN forum because
it looks like a compiler bug ...

http://softwarecommunity.intel.com/isn/Community/en-US/forums/1011/ShowForum.aspx
From: Ron Shepard on
In article <2009092213274116807-gsande(a)worldnetattnet>,
Gordon Sande <g.sande(a)worldnet.att.net> wrote:

> Perhpas you meant
>
> if ( present (str ) ) then
> call show ( str )
> else
> call show ( )
> end if
>
> as the property of being present does not "pass through" in
> the way you seem to expect.

That's the point of the original post, right? It is supposed to "pass
through" in exactly the way he expects. At least I don't see anything
wrong with the original code, but maybe I'm overlooking something.

$.02 -Ron Shepard
From: Harald Anlauf on
On Sep 22, 5:19 pm, Arno <arnoinp...(a)hotmail.com> wrote:
> Intel(R) Fortran Compiler Professional for applications running on
> IA-32, Version 11.1    Build 20090630 Package ID: l_cprof_p_11.1.046
> Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.
> % ifort  -traceback -ftrapuv -fp-stack-check -check all my_module.f90
> main.f90
> % a.out
> forrtl: severe (408): fort: (18): Dummy character variable 'STR' has
> length 9 which is greater then actual variable length 0
>
> Image              PC        Routine            Line        Source
> a.out              08093FED  Unknown               Unknown  Unknown
> a.out              08092DE5  Unknown               Unknown  Unknown
> a.out              0805FDC8  Unknown               Unknown  Unknown
> a.out              0804ADA9  Unknown               Unknown  Unknown
> a.out              0804B078  Unknown               Unknown  Unknown
> a.out              08049D19  my_module_mp_wrap          11
> my_module.f90
> a.out              08049F5C  MAIN__                      5  main.f90
> a.out              08049CB1  Unknown               Unknown  Unknown
> libc.so.6          B7DAA455  Unknown               Unknown  Unknown
> a.out              08049BC1  Unknown               Unknown  Unknown

Hi,

try compiling without -check all or use -check all,nobounds with ifort
11.
This is a known regression :-(

Cheers,
Harald