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: craig at jcb-sc dot com
- Subject: Re: Still bugs in Fortran -fno-emulate-complex
- From: Zack Weinberg <zack at rabi dot columbia dot edu>
- Date: Mon, 12 Apr 1999 22:34:32 -0400
- 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
On 13 Apr 1999 02:27:20 -0000, craig@jcb-sc.com wrote:
>>I decided to poke at the 19990325-x.f test failures, which looked like
>>library issues at first glance - but they're not; with one exception,
>>they are aliasing issues with the backend complex arith support.
>
>Yes, I wrote the tests, intended to show bugs in libf2c (vs. libg2c),
>discovered the assignment-overlap problem, and (IIRC) posted about
>them here.
>
>The actual bug is that the gcc back end's MODIFY_EXPR does not handle
>partial overlap between src and dest, yet it's documented as if
>it does. We had some discussions (on egcs, I think) about that a
>few weeks back. I suspect the consensus is, or was, to fix the docs
>for MODIFY_EXPR, which means fixing each front end (like g77's), as
>necessary, to make use of temps anytime a partial overlap is possible
>for a MODIFY_EXPR.
[...]
Oh, was that what that was about? The whole discussion went right
over my head :)
>>I'm going to look at the single failure with optimization a bit more
>>closely.
>
>If you mean the ICE, that'd be great, thanks!
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...
zw