It turns out that bug #31994
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994) has not been fully
resolved!
I found another testcase that would fail gcc 4.2.1, namely if the destination
of the expression is an allocatable array. Use the following testcase:
program testcase
complex(kind=8), allocatable :: a(:,:), b(:,:)
allocate(a(2,2))
allocate(b(2,2))
a(1,1) = 2
a(2,1) = 3
a(1,2) = 7
a(2,2) = 11
b = conjg(transpose(a)) ! This does NOT work with gcc 4.2.1
print *, 'original = ', a
print *, 'WRONG conjg(transpose(a)) = ', b
end program
OBSERVATIONS:
* The bug appears regardless whether a is allocatable or not.
* The bug does not appear if b is NOT an allocatable array, e.g. a
complex(kind=8),dimension(2,2) in the testcase above.
* The bug does not appear if we reverse the order of expression to: b =
transpose(conjg(a)) .
--
Summary: b = conjg(transpose(a)) is erroneous if b is an
allocatable array
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wirawan0 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
