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
- To: Geoff Keating <geoffk at geoffk dot org>
- Subject: Re: [PATCH] UNKNOWN comparison codes don't match
- From: Jan Hubicka <jh at suse dot cz>
- Date: Tue, 16 Jan 2001 15:59:05 +0100
- Cc: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>, gcc-patches at gcc dot gnu dot org, Jan Hubicka <jh at suse dot cz>
- References: <01011500355900.03943@enzo.bigblue.local> <jmd7dp4r4g.fsf@geoffk.org>
> 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.
Honza