Still bugs in Fortran -fno-emulate-complex

[Zack Weinberg]

On 13 Apr 1999 11:18:12 -0000, craig@jcb-sc.com wrote:
>>On Mon, 12 Apr 1999 22:34:32 -0400, Zack Weinberg wrote:
>>>
>>>ICE?  I don't get an ICE.  I get one partial-overlap bug in the
>>>generated code when optimization is on, and it appears at first glance
>>>to be x86 specific - it's got the order of stack pushes and pops mixed
>>>up.  But I Could Be Wrong.  Give me another hour or so...
>
>Okay, I was referring to the wrong test...the other one that had
>been failing, for just one optimization level, on x86, due to a
>crash (I *think* you were the one who tracked this down as far
>as some jump-target fix-up that didn't trigger a re-run of loop
>optimization).

Yeah, that was me.  But Jeff already squashed that one.

>>Well, I was wrong.  The problem exists from the initial RTL, and looks
>>exactly like what you described with MODIFY_EXPR not understanding
>>overlap.  We clobber the target while the overlapping part of the
>>source is still live, then copy mindlessly assuming no overlap.
>
>Right.  In essence, MODIFY_EXPR implements ISO C's `=' operator,
>which is undefined when there's partial overlap.  I didn't realize
>that when writing the g77 front end (I think only complex assignment
>is affected, though)...but then there were *many* things I didn't
>realize, either.  (And I don't recall knowing about C's `=' restriction
>until I looked it up a few weeks ago.  I had gone to the trouble of
>writing a test case in C to show the problem, using a struct/union
>combo that produced unevenly aligned arrays, when it finally occurred
>to me to verify that it was standard-conforming...it wasn't.  So I
>dropped the C test case.  But the equivalent Fortran assignment *is*
>standard-conforming.)

I looked up the archives, it doesn't look to me like there was much
discussion of MODIFY_EXPR at all.  You said there was a problem with
Fortran, Mark M said he thought C++ and other front ends might be
relying on memcpy-like behavior, end of conversation.

I'd personally vote for adding both MOVE_EXPR and COPY_EXPR, since
it's not clear which behavior people are relying on.  Then we can
start migrating the front ends over, slowly.  The whole thing is an
1.3 project unless it's possible to add tree codes without breaking
anything - in that case the new codes could go in now.  (Trees aren't
documented at all; how involved is it to add codes?)

zw