On Thursday, November 3, 2022 at 8:32:26 AM UTC+13, Peter Klausler US wrote:others do not. For example:
C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear,
real, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.It seems that it can be an array but not a coarray. In the F2018 standard, R719 and R720 say the real-part and imag-part
may be named constants, and 8.5.13 allows named constants that are arrays but not coarrays.
C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear, othersdo not. For example:
real, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.
Does any compiler print the hoped-for (1.000000,3.000000) and (2.000000,3.000000) ?
..
Does any compiler print the hoped-for (1.000000,3.000000) and (2.000000,3.000000) ?
On Thursday, November 3, 2022 at 9:32:39 AM UTC+13, jfh wrote:others do not. For example:
On Thursday, November 3, 2022 at 8:32:26 AM UTC+13, Peter Klausler US wrote: >> > C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear,
It seems that it can be an array but not a coarray. In the F2018 standard, R719 and R720 say the real-part and imag-part
real, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.
may be named constants, and 8.5.13 allows named constants that are arrays but not coarrays.
But the gfortran developers know Fortran better than I do and gfortran gives the error message
3 | print *, (arr2, 3.)
| 1
Error: Scalar PARAMETER required in complex constant at (1)
Rather than the "hoped for", chances are high the Fortran committee will think the standard needs a quick fix here.
f18 prints " (1.,3.) (2.,3.)".What happens if you do
program foo
real, parameter :: a(2) = [1,2], b(3) = [1,2,3]
print *, (a,b)
end program foo
C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear, othersdo not. For example:
real, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.
On Wednesday, November 2, 2022 at 1:55:33 PM UTC-7, jfh wrote:
Does any compiler print the hoped-for (1.000000,3.000000) and (2.000000,3.000000) ?
f18 prints " (1.,3.) (2.,3.)".
Another possibility, which I don't like but Peter seems to want, is that
if both are arrays that they be the same shape and if only one is scalar
that it gets duplicated to the shape of the other. This feels messy to me.
On 11/2/2022 3:32 PM, Peter Klausler US wrote:others do not. For example:
C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear,
real, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.(I realize I meant to do a follow-up to the group and instead sent an
email to Peter...)
NAG Fortran does not accept this code. I can't find words in the
standard that either prohibit it, or assign it an interpretation.
Malcolm would say that means it's not allowed. I have asked him for his thoughts, and suggested that a constraint should be added to require
that both parts be scalar (which NAG evidently believes is the rule.)
Another possibility, which I don't like but Peter seems to want, is that
if both are arrays that they be the same shape and if only one is scalar that it gets duplicated to the shape of the other. This feels messy to me. --
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 3, 2022 at 1:42:48 PM UTC+13, Steve Lionel wrote:others do not. For example:
On 11/2/2022 3:32 PM, Peter Klausler US wrote:
C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear,
real, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.(I realize I meant to do a follow-up to the group and instead sent an email to Peter...)
NAG Fortran does not accept this code. I can't find words in the
standard that either prohibit it, or assign it an interpretation.
Malcolm would say that means it's not allowed. I have asked him for his thoughts, and suggested that a constraint should be added to require
that both parts be scalar (which NAG evidently believes is the rule.)
Another possibility, which I don't like but Peter seems to want, is that if both are arrays that they be the same shape and if only one is scalar that it gets duplicated to the shape of the other. This feels messy to me. --The possibility that Peter wants and Steve thinks is messy is exactly what the cmplx intrinsic allows. Both the compilers I can use, ifort and gfortran, are happy with this program.
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
complex,parameter:: c(2) = cmplx([1.0,2.0], 3.0)
print *, c
end program
Of course both those compilers object, in different ways, if the word cmplx is removed from the above program.
On Saturday, November 5, 2022 at 4:10:57 AM UTC-4, jfh wrote:others do not. For example:
On Thursday, November 3, 2022 at 1:42:48 PM UTC+13, Steve Lionel wrote:
On 11/2/2022 3:32 PM, Peter Klausler US wrote:
C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear,
the two, personally. I also found it confusing in the past I could doreal, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.(I realize I meant to do a follow-up to the group and instead sent an email to Peter...)
NAG Fortran does not accept this code. I can't find words in the standard that either prohibit it, or assign it an interpretation. Malcolm would say that means it's not allowed. I have asked him for his thoughts, and suggested that a constraint should be added to require that both parts be scalar (which NAG evidently believes is the rule.)
Another possibility, which I don't like but Peter seems to want, is that if both are arrays that they be the same shape and if only one is scalar that it gets duplicated to the shape of the other. This feels messy to me.The possibility that Peter wants and Steve thinks is messy is exactly what the cmplx intrinsic allows. Both the compilers I can use, ifort and gfortran, are happy with this program.
--
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
complex,parameter:: c(2) = cmplx([1.0,2.0], 3.0)
print *, c
end program
Of course both those compilers object, in different ways, if the word cmplx is removed from the above program.I have generally thought of (x,y) as equivalent to cmplx(x,y) without the issues with kind that cmplx() has with the restriction that the values are constant; and being that CMPLX is an elemental function I would have expected the same behavior between
real,parameter :: x=3.0*3.0, y=sin(10.0)
complex :: z=(x,y)
complex :: zz=cmplx(3.0*3.0,sin(10.0))
but not
complex,parameter :: zzz=(3.0*3.0,sin(10.0))
as well, so I as a rule just use cmplx and always specify the kind anyway, even though it gets pretty verbose. Probably why the COMPLEX function is a common extension!
On Saturday, November 5, 2022 at 4:10:57 AM UTC-4, jfh wrote:others do not. For example:
On Thursday, November 3, 2022 at 1:42:48 PM UTC+13, Steve Lionel wrote:
On 11/2/2022 3:32 PM, Peter Klausler US wrote:
C718 requires that a named-constant that is used as the real-part or imag-part of a complex-literal-constant have a real or integer type, but it doesn't say anything about its rank. Some compilers allow an array-valued named constant to appear,
the two, personally. I also found it confusing in the past I could doreal, parameter :: arr2(2) = [1., 2.]
print *, (arr2, 3.)
Is there language anywhere else in the standard that requires such a named-constant to be scalar, or that implies such a constraint because a complex-literal-constant is assumed to be scalar? I can't find anything definitive one way or another.(I realize I meant to do a follow-up to the group and instead sent an email to Peter...)
NAG Fortran does not accept this code. I can't find words in the standard that either prohibit it, or assign it an interpretation. Malcolm would say that means it's not allowed. I have asked him for his thoughts, and suggested that a constraint should be added to require that both parts be scalar (which NAG evidently believes is the rule.)
Another possibility, which I don't like but Peter seems to want, is that if both are arrays that they be the same shape and if only one is scalar that it gets duplicated to the shape of the other. This feels messy to me.The possibility that Peter wants and Steve thinks is messy is exactly what the cmplx intrinsic allows. Both the compilers I can use, ifort and gfortran, are happy with this program.
--
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
complex,parameter:: c(2) = cmplx([1.0,2.0], 3.0)
print *, c
end program
Of course both those compilers object, in different ways, if the word cmplx is removed from the above program.I have generally thought of (x,y) as equivalent to cmplx(x,y) without the issues with kind that cmplx() has with the restriction that the values are constant; and being that CMPLX is an elemental function I would have expected the same behavior between
real,parameter :: x=3.0*3.0, y=sin(10.0)
complex :: z=(x,y)
complex :: zz=cmplx(3.0*3.0,sin(10.0))
but not
complex,parameter :: zzz=(3.0*3.0,sin(10.0))
as well, so I as a rule just use cmplx and always specify the kind anyway, even though it gets pretty verbose. Probably why the COMPLEX function is a common extension!
I just remembered an old argument about how some compilers allowed redundant parenthesis around expressions and how allowing anything but constants would break that, but just tried three compilers and none of them did so maybe that is a moot point.Does anyone know of a compiler that still allows something like "print *, (3+10*3)" printing a scalar integer, for example?
On 11/5/2022 4:52 PM, John wrote:Does anyone know of a compiler that still allows something like "print *, (3+10*3)" printing a scalar integer, for example?
I just remembered an old argument about how some compilers allowed redundant parenthesis around expressions and how allowing anything but constants would break that, but just tried three compilers and none of them did so maybe that is a moot point.
D:\Projects>type t.f90
print *, (3+10*3)
end
D:\Projects>ifort t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running
on Intel(R) 64, Version 2021.7.0 Build 20220726_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
Microsoft (R) Incremental Linker Version 14.33.31630.0
Copyright (C) Microsoft Corporation. All rights reserved.
-out:t.exe
-subsystem:console
t.obj
D:\Projects>t.exe
33
D:\Projects>
I recognize the similarity to CMPLX, but am not sure the standard wants
to make complex constants elemental. I'm intending to write a paper and
see what the sense of the committee is on this. For F2023, which is in
the DIS stage, it would be simple to require the real and imaginary
parts to be scalar. Trying to do more at this point would risk
complications that often happen with last-minute expansions of semantics
- and it could be considered for F202Y.
--
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 11/5/2022 4:52 PM, John wrote:Does anyone know of a compiler that still allows something like "print *, (3+10*3)" printing a scalar integer, for example?
I just remembered an old argument about how some compilers allowed redundant parenthesis around expressions and how allowing anything but constants would break that, but just tried three compilers and none of them did so maybe that is a moot point.
D:\Projects>type t.f90implicit none
print *, (3+10*3)
end
D:\Projects>ifort t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running
on Intel(R) 64, Version 2021.7.0 Build 20220726_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
Microsoft (R) Incremental Linker Version 14.33.31630.0
Copyright (C) Microsoft Corporation. All rights reserved.
-out:t.exe
-subsystem:console
t.obj
D:\Projects>t.exe
33
D:\Projects>
I recognize the similarity to CMPLX, but am not sure the standard wants
to make complex constants elemental. I'm intending to write a paper and
see what the sense of the committee is on this. For F2023, which is in
the DIS stage, it would be simple to require the real and imaginary
parts to be scalar. Trying to do more at this point would risk
complications that often happen with last-minute expansions of semantics
- and it could be considered for F202Y.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com program main
implicit noneWhy? That's clearly a complex literal.
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
implicit none
print *, (3+10*3,0)
print *, (3+10*3)
print *, (3,0)
end program main
On 11/5/2022 7:43 PM, John wrote:with list-directed output a complex value would appear at "(33.0,0.0)"; it printed as two integers. Being two (constant) expressions I actually expected an error. maybe that it would be an acceptable complex value, as it would have generated with CMPLX()
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 0Why? That's clearly a complex literal.
--
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 5, 2022 at 4:45:29 PM UTC-7, John wrote:
(snip)
implicit noneThe third is a complex constant.
print *, (3+10*3,0)
print *, (3+10*3)
print *, (3,0)
end program main
The second is an expression in parens.
And the form that is supposed to not be allowed, in implied-DO without the implied-DO.
On Saturday, November 5, 2022 at 8:50:44 PM UTC-4, Steve Lionel wrote:); being in parenthesis I did not expect it to treat it at "print *, 3+10*3, 0".
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
with list-directed output a complex value would appear at "(33.0,0.0)"; it printed as two integers. Being two (constant) expressions I actually expected an error. maybe that it would be an acceptable complex value, as it would have generated with CMPLX(33 0Why? That's clearly a complex literal.
--
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
or maybe it treated it as "print *,(3+10*3,0,i=1,1)"
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 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 0Why? 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.
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
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
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)
I believe that gfortran is correct.! 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
9.1 DesignatorExactly 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
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.
Curious if anyone has results for NAG/Cray/IBM/...D:\Projects>nagfor -o t.exe t.f90
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
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 98:31:56 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,579 |