This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Still bugs in Fortran -fno-emulate-complex


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

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

>However, there's another oddity:  a DCmode copy is carried out with
>pairs of DFmode move insns, and an SCmode copy with pairs of SFmode
>move insns.  I'm guessing this is because there's no such thing as a
>complex-mode reg.  But I wonder, for code like this, would it make
>sense to invent one?

I don't know.  Perhaps, for an SCmode copy, the x86 could use DFmode
copies....

(I believe I patched g77 to default to -fno-emulate-complex a week or
so ago -- you might want to look up the g77 docs, and maybe some g77 code,
on that option, to learn a bit about some related issues.)

        tq vm, (burley)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]