This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: loop.c:get_condition broken
- To: Jim Wilson <wilson at cygnus dot com>
- Subject: Re: loop.c:get_condition broken
- From: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Date: Wed, 07 Oct 1998 08:07:47 +1300 (NZDT)
- Cc: David Edelsohn <dje at watson dot ibm dot com>, Jeffrey Law <law at cygnus dot com>, Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, egcs at cygnus dot com
- References: <9810060153.AA51382@marc.watson.ibm.com><199810061931.MAA03573@rtl.cygnus.com>
Jim Wilson writes:
> I'd suspect the problem might be an interaction problem between the rs6000
> port and how loop/combine handle mixed mode comparison operations, but I'd
> apprepreciate having an actual testcase to look at.
I am having similar problems with the C4x.
> The intent of the patch is that if you have one comparison in CCmode, and
> one in some other mode (like DFmode), then loop should not assume that they
> can be simplified. This allows us to indicate, for instance, that some
> compares produce IEEE FP correct results and some do not.
What if the other mode is VOIDmode which I think is where the problem
is?
Shouldn't the alpha be using different CCmodes to handle this problem
in a similar manner to how several targets handle the behaviour of CC
setting when some insns overflow?