syntax error: logical expression in sourced allocation

[Ferdinand_T_]

Hello,

today ifort 14.0.1 got me confused with the followign syntax error where I think I wrote legal code:

[fortran]

program p
    implicit none
    logical, allocatable :: flag
 
    ! allocation and assignment from logical expression
    allocate(flag)
    flag = .true. .or. .false.            ! OK
 
    ! sourced allocation from logical expression
    allocate(flag, source = (.true. .or. .false.))    ! OK
    allocate(flag, source =  .true. .or. .false. )    ! ERROR
 
end program

[/fortran]

Output:

error #5082: Syntax error, found '.' when expecting one of: * ) :: , <END-OF-STATEMENT> ; . (/ + - : ] /) ' ** / // > .LT. < ...
    allocate(flag, source = .true. .or. .false.)
---------------------------------------^

Just out of curiosity: can somebody comment on this?

Best regards
Ferdinand

[Steven_L_Intel1]

I think that's legal and will ask the developers to fix this.

[Intel_C_19]

I add a logical :: a,b in the statements, and change line 11 into "allocate(flag, source = a.or.b )"

then I get:

error #6866: Dotted string neither a defined operator nor a structure component [OR]
allocate(flag, source = a.or.b ) ! ERROR
-------------------------------^
error #8155: In an ALLOCATE statement the source expression in SOURCE= or MOLD= specifiers must be of the same type and kind type parameters as the object being allocated.
allocate(flag, source = a.or.b ) ! ERROR

seems the compiler forget what is "or" here.....

[Izaak_Beekman]

Perhaps I missed something, but don't you need to deallocate flag before reallocating it? This is certainly the case for allocatble arrays, and I beleive it applies to allocatable scalars as well. (Although, this isn't explicitly stated to be true for scalars in Modern Fortran Explained... AFAICT)

[Ferdinand_T_]

Thanks, Steve.

@ heylouis,
Any logical operation (not only .or.) raises an error. Only a logical primary or a parenthesed expression is currently accepted in the source.

[Steven_L_Intel1]

Izaak, yes, the code as shown would be an invalid double (or even triple) allocation, but the code does demonstrate the problem reported.

[Steven_L_Intel1]

This problem has been fixed for a future release.