Results for egcs-2.93.13 19990326 (gcc2 ss-980929 experimental) testsuite on i686-pc-linux-gnulibc1

[craig@jcb-sc.com]

>FAIL: g77.f-torture/execute/19990325-1.f execution,  -O0 
>FAIL: g77.f-torture/execute/19990325-1.f execution,  -O1 
>FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 
>FAIL: g77.f-torture/execute/19990325-1.f execution,  -O2 -fomit-frame-pointer -finline-functions 
>FAIL: g77.f-torture/execute/19990325-1.f execution,  -Os 

The above are new failures, from a new test (one of two) I added within
the past 12 hours or so.

I haven't investigated far enough to find the precise culprit, but what
is happening is that the generated code fails to account for the possibility
that a structure (aka record) assignment might involve a partial overlap
of the rhs and lhs.

The possible overlap (alias) is *not* the product of the sorts of argument
(and/or global) association that the FORTRAN 77 and subsequent language
standards forbid.  It results from copying among entirely local
variables.

So, I believe the source code for the test itself is standard-compliant
(wrt this issue, anyway).

What I don't know is whether the gcc back end is not adequately defined
for this case, is adequately defined but not implemented correctly, or
is adequately defined and the g77 front end not implemented correctly
vis-a-vis that definition.

In any case, the problem exists for g77 0.5.23 (based on gcc 2.8.1), as
well as egcs 1.0.3a and 1.1.2.

So, in that sense, it isn't a new problem.  And, it isn't likely to
be triggered by production Fortran code (since forcing a partial overlap
of complex operands, especially without violating the language prohibitions
against argument/COMMON aliasing, is painful, right off the bat).

But, it is, AFAIK, a bug somewhere in the g77 front end or gcc back end.

(BTW, I wrote the new tests, originally, to catch bugs in the combination
of g77+libf2c, as vs. g77+libg2c.  Both versions of libf2c's libF77 have
run-time routines to do various complex-arithmetic stuff.  Long ago,
they didn't cope with aliased operands at all.  Since the result (lhs)
is returned via an argument (pointer to complex), that meant the compiler
(f2c or g77) had to employ a temporary if aliasing was possible.  I
persuaded -- perhaps mistakenly, given the performance implications --
the maintainer of libf2c to make the routines accommodate aliasing, so
the temporaries would no longer be necessary.  However, I took one
approach, which I think I submitted to him as a patch, but he took another,
the main semantic difference being his didn't accommodate *partial*
aliasing.  I'm not sure what the right resolution to this split is,
but have had, on my to-do list for some time, to make sure he knew
the differences and had the pertinent libf2c->libg2c patch, and *also*
had test cases that exhibited the problem when running the g77+libf2c
combination.  I've now taken care of that.  But I'm glad I put in those
extra tests, even though it seemed "obvious" they'd not fail -- because
one of them, the straight assignment, *does* fail for some combinations
of partial overlap, type, and, perhaps, target machine, as the above
test results show.)

(Oh, yes, and I'm not writing all the above because I think anybody
really cares right now, but because of the fact that this list is
archived, and, someday, somebody *might* want to know what was going
on in my head right around this time.)

>FAIL: g77.f-torture/execute/970625-2.f compilation,  -O1 

The above failure is still definitely a relatively new one, but I haven't
spent any further time on it (as it's not as high priority for me
as these other longstanding g77 issues).

        tq vm, (burley)