On Sunday, November 6, 2022 at 11:50:44 AM UTC+11, Steve Lionel wrote:
> On 11/5/2022 7:43 PM, John wrote:
> > implicit none
> > print *, (3+10*3,0)
> > print *, (3+10*3)
> > print *, (3,0)
> > end program main
> >
> > Have to say, the results with ifort and nvfortran were still surprising for the first print
> >
> > 33 0
..
> Why? That's clearly a complex literal.
..
3+10*3 looks like an expression to me, not a constant.

On Sunday, November 6, 2022 at 12:49:47 AM UTC-7, Robin Vowels wrote:

(snip)

> 3+10*3 looks like an expression to me, not a constant.

It is a constant in C. I am not sure about Fortran, which is why this
question is so interesting.

On Saturday, November 5, 2022 at 5:50:44 PM UTC-7, Steve Lionel wrote:
> On 11/5/2022 7:43 PM, John wrote:
> > implicit none
> > print *, (3+10*3,0)
> > print *, (3+10*3)
> > print *, (3,0)
> > end program main
> >
> > Have to say, the results with ifort and nvfortran were still surprising for the first print
> >
> > 33 0
> Why? That's clearly a complex literal.

It is not a complex-literal-constant (R718) -- the real and imaginary parts would have to be both signed-int-literal-constant, signed-real-literal-constant, or named constants.

It is not a complex constant expression, either, in standard Fortran, for obvious reasons.

On 11/6/2022 1:00 PM, Peter Klausler US wrote:
> It is not a complex-literal-constant (R718) -- the real and imaginary parts would have to be both signed-int-literal-constant, signed-real-literal-constant, or named constants.

Agree - I thought I posted a correction yesterday, but don't see it.

NAG Fortran rejects "print *, (3+10*3,0)". Intel Fortran accepts it as
it has an extension allowing a parenthesized I/O list - it will complain
if you ask for standards checking.
--
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

On Monday, November 7, 2022 at 9:14:25 AM UTC-5, Steve Lionel wrote:
> On 11/6/2022 1:00 PM, Peter Klausler US wrote:
> > It is not a complex-literal-constant (R718) -- the real and imaginary parts would have to be both signed-int-literal-constant, signed-real-literal-constant, or named constants.
> Agree - I thought I posted a correction yesterday, but don't see it.
>
> NAG Fortran rejects "print *, (3+10*3,0)". Intel Fortran accepts it as
> it has an extension allowing a parenthesized I/O list - it will complain
> if you ask for standards checking.
> --
> 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

Another thing the vexes me about complex variables is which compilers have it right for passing x%re and x%im as arguments?
I should probably report this to one or the other, but I cannot find anything in the standard so far that clears up "TEST II" so far.
Does anyone else see it?

$ gfortran x-x.f90
$ ./a.out
(100.000000,0.141120002)
(200.000000,0.141120002)

$ ifort x-x.f90
$ ./a.out
(100.0000,0.1411200)
(100.0000,0.1411200)

$ nvfortran x-x.f90
$ ./a.out
(100.0000,0.1411200)
(100.0000,0.1411200)
$ cat x-x.f90

> program testit
> complex :: x
> ! TEST I
> ! x%re|mi can appear on the left-hand side of an assignment
> x%re=100.0
> x%im=sin(3.0)
>
> ! TEST II
> write(*,*)x
> ! it can be passed as a subroutine argument and be changed
> call trivial(x%re)
> write(*,*)x
> contains
> subroutine trivial(r)
> real :: r
> r=r*2
> end subroutine trivial
> end program testit

On Mon, 07 Nov 2022 17:01:12 -0800, John wrote:

> On Monday, November 7, 2022 at 9:14:25 AM UTC-5, Steve Lionel wrote:
>> On 11/6/2022 1:00 PM, Peter Klausler US wrote:
>> > It is not a complex-literal-constant (R718) -- the real and imaginary parts would have to be both signed-int-literal-constant, signed-real-literal-constant, or named constants.
>> Agree - I thought I posted a correction yesterday, but don't see it.
>>
>> NAG Fortran rejects "print *, (3+10*3,0)". Intel Fortran accepts it as
>> it has an extension allowing a parenthesized I/O list - it will complain
>> if you ask for standards checking.
>> --
>> 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
>
> Another thing the vexes me about complex variables is which compilers have it right for passing x%re and x%im as arguments?
> I should probably report this to one or the other, but I cannot find anything in the standard so far that clears up "TEST II" so far.
> Does anyone else see it?
>
>
>
>
> $ gfortran x-x.f90
> $ ./a.out
> (100.000000,0.141120002)
> (200.000000,0.141120002)
>
> $ ifort x-x.f90
> $ ./a.out
> (100.0000,0.1411200)
> (100.0000,0.1411200)
>
> $ nvfortran x-x.f90
> $ ./a.out
> (100.0000,0.1411200)
> (100.0000,0.1411200)
> $ cat x-x.f90
>
> > program testit
> > complex :: x
> > ! TEST I
> > ! x%re|mi can appear on the left-hand side of an assignment
> > x%re=100.0
> > x%im=sin(3.0)
> >
> > ! TEST II
> > write(*,*)x
> > ! it can be passed as a subroutine argument and be changed
> > call trivial(x%re)
> > write(*,*)x
> > contains
> > subroutine trivial(r)
> > real :: r
> > r=r*2

I believe that gfortran is correct.

9.1 Designator

R901 designator is object-name
or array-element
or array-section
or coindexed-named-object
or complex-part-designator
or structure-component
or substring

1 The appearance of a data object designator in a context that requires its value
is termed a reference.

9.2 Variable is designator

R902 variable

There is nothing in

19.6.5 Events that cause variables to become defined

1 Variables become defined by the following events.

the long list that disqualifies a complex-part-designator
from being manipulated through the argument association
with a dummy argument.

On Tuesday, November 8, 2022 at 8:19:58 PM UTC-5, Steven G. Kargl wrote:
> On Mon, 07 Nov 2022 17:01:12 -0800, John wrote:
>
> > On Monday, November 7, 2022 at 9:14:25 AM UTC-5, Steve Lionel wrote:
> >> On 11/6/2022 1:00 PM, Peter Klausler US wrote:
> >> > It is not a complex-literal-constant (R718) -- the real and imaginary parts would have to be both signed-int-literal-constant, signed-real-literal-constant, or named constants.
> >> Agree - I thought I posted a correction yesterday, but don't see it.
> >>
> >> NAG Fortran rejects "print *, (3+10*3,0)". Intel Fortran accepts it as
> >> it has an extension allowing a parenthesized I/O list - it will complain
> >> if you ask for standards checking.
> >> --
> >> 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
> >
> > Another thing the vexes me about complex variables is which compilers have it right for passing x%re and x%im as arguments?
> > I should probably report this to one or the other, but I cannot find anything in the standard so far that clears up "TEST II" so far.
> > Does anyone else see it?
> >
> >
> >
> >
> > $ gfortran x-x.f90
> > $ ./a.out
> > (100.000000,0.141120002)
> > (200.000000,0.141120002)
> >
> > $ ifort x-x.f90
> > $ ./a.out
> > (100.0000,0.1411200)
> > (100.0000,0.1411200)
> >
> > $ nvfortran x-x.f90
> > $ ./a.out
> > (100.0000,0.1411200)
> > (100.0000,0.1411200)
> > $ cat x-x.f90
> >
> > > program testit
> > > complex :: x
> > > ! TEST I
> > > ! x%re|mi can appear on the left-hand side of an assignment
> > > x%re=100.0
> > > x%im=sin(3.0)
> > >
> > > ! TEST II
> > > write(*,*)x
> > > ! it can be passed as a subroutine argument and be changed
> > > call trivial(x%re)
> > > write(*,*)x
> > > contains
> > > subroutine trivial(r)
> > > real :: r
> > > r=r*2
> I believe that gfortran is correct.
>
>
> 9.1 Designator
>
> R901 designator is object-name
> or array-element
> or array-section
> or coindexed-named-object
> or complex-part-designator
> or structure-component
> or substring
>
> 1 The appearance of a data object designator in a context that requires its value
> is termed a reference.
>
> 9.2 Variable is designator
>
> R902 variable
>
> There is nothing in
>
> 19.6.5 Events that cause variables to become defined
>
> 1 Variables become defined by the following events.
>
> the long list that disqualifies a complex-part-designator
> from being manipulated through the argument association
> with a dummy argument.
Exactly what I was looking for. Two out of three compilers I tried did not agree with what I expected, and I did not see what, when you extract and present it as you did, suddenly looks (relatively) clear. I will report to Intel and Nvidia. Curious if anyone has results for NAG/Cray/IBM/...

On 11/9/2022 9:24 AM, John wrote:
> Curious if anyone has results for NAG/Cray/IBM/...
D:\Projects>nagfor -o t.exe t.f90
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7114
[NAG Fortran Compiler normal termination]

D:\Projects>t.exe
(1.0000000E+02,0.1411200)
(2.0000000E+02,0.1411200)

--
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

On Thursday, November 10, 2022 at 4:39:49 AM UTC+13, Steve Lionel wrote:
> On 11/9/2022 9:24 AM, John wrote:
> > Curious if anyone has results for NAG/Cray/IBM/...
> D:\Projects>nagfor -o t.exe t.f90
> NAG Fortran Compiler Release 7.1(Hanzomon) Build 7114
> [NAG Fortran Compiler normal termination]
>
> D:\Projects>t.exe
> (1.0000000E+02,0.1411200)
> (2.0000000E+02,0.1411200)

> --
> 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

On renaming the program xreim.f90 and making the dummy argument r of subroutine trivial intent(inout) ifort gave this compile-time error message:

xreim.f90(11): error #6638: An actual argument is an expression or constant; this is not valid since the associated dummy argument has the explicit INTENT(OUT) or INTENT(INOUT) attribute. [REAL]
call trivial(x%re)
^ compilation aborted for xreim.f90 (code 1)

That made it clearer why ifort did what it did. Whether it was standard-conforming is a more subtle question.

FYI: Reported issues with complex designators on Intel Forum ...

https://community.intel.com/t5/Intel-Fortran-Compiler/Issues-with-complex-part-designators/m-p/1429557#M163510

Did anyone ask J3 for clarification on original issue?

On 11/11/2022 9:02 PM, John wrote:
> FYI: Reported issues with complex designators on Intel Forum ...
>
> https://community.intel.com/t5/Intel-Fortran-Compiler/Issues-with-complex-part-designators/m-p/1429557#M163510
>
> Did anyone ask J3 for clarification on original issue?
>
>
Unnecessary - the standard is quite clear that a complex-part-designator
is a variable. That ifort doesn't treat it that way is a bug.
--
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

On Saturday, November 12, 2022 at 2:19:01 PM UTC-5, Steve Lionel wrote:
> On 11/11/2022 9:02 PM, John wrote:
> > FYI: Reported issues with complex designators on Intel Forum ...
> >
> > https://community.intel.com/t5/Intel-Fortran-Compiler/Issues-with-complex-part-designators/m-p/1429557#M163510
> >
> > Did anyone ask J3 for clarification on original issue?
> >
> >
> Unnecessary - the standard is quite clear that a complex-part-designator
> is a variable. That ifort doesn't treat it that way is a bug.
> --
> 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

FYI: Intel and the Intel forum were very responsive and Intel has opened 2 bug reports on the complex designator issues

CMLRLLVM-41931 for passing z%re to a subroutine that updates the value of the arg, but actual arg is unchanged after return.

CMLRIL0-35035 for the -check uninit that erroneously flags the assignment as illegal use of uninit variable.
> WG5: https://wg5-fortran.org