This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PowerPC build breakage caused by 8/25/98 loop.c change
- To: dje at watson dot ibm dot com
- Subject: Re: PowerPC build breakage caused by 8/25/98 loop.c change
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Fri, 18 Sep 1998 14:41:51 -0700
- CC: davem at pierdol dot cobaltmicro dot com, law at cygnus dot com, meissner at cygnus dot com, egcs at cygnus dot com
- References: <9809182120.AA35006@marc.watson.ibm.com>
- Reply-to: mark at markmitchell dot com
>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:
David> I don't know enough about these changes to determine
David> what is wrong. Mark, I would appreciate if you could find
David> time to look into this. I can try to provide some help and
David> dump traces, if you want to see intermediate output.
I'd like to help. Unfortunately, I've not got access to a PowerPC
platform. Can you isolate which function is being miscompiled?
I doubt the AVOID_CCMODE_COPIES bit is to blame; if anything went
wrong with that code it would probably a trigger an immediate crash as
load_mems_and_recount_loop_regs_set runs. It sounds like you're
seeing a failure further down the line, right? But, you can easily
test that hypothesis; take your working version, and substitute just
the AVOID_CCMODE_COPIES in load_mems_and_recount_loop_regs_set.
You'll have to change `VARRAY_CHAR (may_not_optimize, i)' to
`may_not_optimize[i] = 1' since you'll not have the VARRAY stuff. If
the resulting compiler doesn't bootstrap, then we'll know that's the
problem; otherwise, it's elsewhere.
I'll take a look at the rest, but you can too: it was a
straightforward replacement of `x[i] = j' with `VARRAY_TYPE (x, i) =
j'. One possibility is that TYPE (which should be CHAR if the thing
was an array of chars, INT if ints, etc.) is wrong somewhere.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com