This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Still bugs in Fortran -fno-emulate-complex
- To: zack at rabi dot columbia dot edu
- Subject: Re: Still bugs in Fortran -fno-emulate-complex
- From: craig at jcb-sc dot com
- Date: 13 Apr 1999 11:18:12 -0000
- Cc: d dot love at dl dot ac dot uk, egcs-bugs at egcs dot cygnus dot com, toon at moene dot indiv dot nluug dot nl
- Cc: craig at jcb-sc dot com
- References: <199904130259.WAA22538@blastula.phys.columbia.edu>
>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)