Conformant program or not?

[Peter Klausler US]

complex, save, target :: a(10) = [(j,j=1,10)]
real, pointer :: p(:) => a(1:9:2)%re
print *, p
end


No released Fortran compiler to which I have access can compile and run this short program, but they each have a distinct error message or runtime crash. I think that it's conformant with Fortran 2018. Am I missing anything?

[Steven G. Kargl]

On Thu, 16 Mar 2023 09:41:32 -0700, Peter Klausler US wrote:
> Am I missing anything?

Yes. Conversations are normally two-way.

--
steve

[gah4]

On Thursday, March 16, 2023 at 9:41:34 AM UTC-7, Peter Klausler US wrote:

> complex, save, target :: a(10) = [(j,j=1,10)]

What is the rule on array initializers having a different type from
the array being initialized?

[Peter Klausler US]

On Thursday, March 16, 2023 at 12:58:34 PM UTC-7, gah4 wrote:
> > complex, save, target :: a(10) = [(j,j=1,10)]
> What is the rule on array initializers having a different type from
> the array being initialized?

They get converted, but that's not important for this example, you can expand the initializer or use a DATA statement if you like. Or omit it entirely.

[gah4]

I think there is a case where they don't, but I don't remember it now.
And you didn't say the error messages, so we don't know what to look for.

[Peter Klausler US]

Okay. Here's an update with no question of data conversion:

complex, save, target :: a(4) = [(1.,0.),(2.,0.),(3.,0.),(4.,0)]
real, pointer :: p(:) => a(1:3:2)%re
print *, p
end

The results, anonymized:

One compiler compiles it without complaint and then it crashes at runtime with SIGSEGV.

Two compilers complain about line 2: "When the target is an expression it must deliver a pointer result." -- which makes no sense to me.

Another compiler complains: "Syntax error at or near integer constant 1" on line 2.

Yet another compiler: "P dereferenced or deallocated but not pointer-assigned or allocated" on line 4.

Moving on, another says: "Syntax is incorrect." on line 2.

A compiler in development says: "Variable 'end' is not declared" on line 4, which seems like a misparse.

[Steve Lionel]

I discussed this with Malcolm (nagfor gets an internal error for it). We
both agree that this is awful, but valid F2018 code. It's an unfortunate
side effect of expanding the cases of pointer assignment - no good deed
goes unpunished.

Malcolm has entered a bug report against nagfor, and I will do one for
ifort/ifx (which gives a nonsense message, as you say.)
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[John]

The ifort/ifx message would make sense if instead of a(1:3:2)%re it was real(a(1:3:2)) as that would be an expression; so I might have reported the bug in another form where if a%re was passed to a procedure that changed the value as a real argument. the value was not changed on return. Of course that would also be assigning a non-constant expression on initialization as well, but that is what you should
get (perhaps less cryptically) if you did not initialize it but used an assignment like "p=real(a(1:3:2))". If no one reported the segfault, which I
assume was gfortran I was going to report it as I do not see it in the bugzilla reports, with

program boom
implicit none
complex, save, target :: a(4)
#ifdef INITIALIZE
real, pointer :: p(:) => a(1:3:2)%re
#else
real, pointer :: p(:)
p => a(1:3:2)%re
#endif
a = [(1., 0.), (2., 0.), (3., 0.), (4., 0)]
print *, p
end program boom
t
as it works with the assignment but not the initialization with the 12.2 version.

The ifort message would make sense if the error were

complex, save, target :: a(4)
real, pointer :: p(:)
a = [(1., 0.), (2., 0.), (3., 0.), (4., 0)]
p => real(a(1:3:2)) <== SHOULD get an error
!p => a(1:3:2)%re <== should work but does not
print *, p
end
xx.f90(4): error #6678: When the target is an expression it must deliver a pointer result.
p => real(a(1:3:2))

the message makes more sense seen in this context.

ifx appears to be treating a(1:3:2)%re as equivalent to real(a(1:3:2)), similar to the error I reported, although not totally sure fixing the previous report would fix this as well.

[Ron Shepard]

Here is a version that seems to work as expected for gfortran, but not
ifort.

complex, save, target :: a(4) = [(1.,0.),(2.,0.),(3.,0.),(4.,0)]
real, pointer :: p(:)

p => a%re
p => p(1:3:2)
print *, p
end

[John]

I think that makes sense, as it looks like gfortran does not initialize pointers yet, per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101047
while investigating if my gfortran bug report was a duplicate. That would explain it, as P is not even associated by an initialization, but is by an assignment per #101047