This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] UNKNOWN comparison codes don't match
On Tuesday 16 January 2001 15:59, Jan Hubicka wrote:
> > Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
> > > --------------Boundary-00=_ZVE6M1O7TZJWIEUS8KW6
> > > Content-Type: text/plain;
> > > charset="iso-8859-1"
> > > Content-Transfer-Encoding: 8bit
> > >
> > > Hi,
> > >
> > > compiling glibc-2.2.1 with current CVS on powerpc-linux-gnu produced
> > > broken code with this testcase:
> >
> > I think this is a bug somewhere else. Where did the UNKNOWN condition
> > codes come from? I think comparison_dominates_p should abort if it
> > gets them.
>
> It is quite common to call comparison_dominates_p w/o verifying that our
> code is reversible (i.ie possibly with UNKNOWN) and I think
> comparison_dominates_p is expected to return 0 in case one of cases is
> UNKNOWN.
>
> In that way most optimizations work - note that before my patch, the
> situation was pretty much same - the can_reverse_p predicate can return
> TRUE for unordered comparisons under some cases reverse should not handle.
>
> So when I was rewriting I was keeping in the mind the behaviour of
> comparison_dominates_p to handle UNKNOWNs in sane way.
Any other opinions? If not, OK to apply the patch?
Franz.