From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-42556-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 19188 invoked by alias); 10 Dec 2001 14:21:01 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 19010 invoked from network); 10 Dec 2001 14:19:44 -0000
Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123)
  by sources.redhat.com with SMTP; 10 Dec 2001 14:19:44 -0000
Received: (from hubicka@localhost)
	by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id PAA17324;
	Mon, 10 Dec 2001 15:19:41 +0100
Date: Mon, 10 Dec 2001 06:34:00 -0000
From: Jan Hubicka <jh@suse.cz>
To: law@redhat.com
Cc: jh@suse.cz, gcc@gcc.gnu.org
Subject: Re: your mail
Message-ID: <20011210151941.B13396@atrey.karlin.mff.cuni.cz>
References: <16942.1007983414@porcupine.cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16942.1007983414@porcupine.cygnus.com>
User-Agent: Mutt/1.3.20i
X-SW-Source: 2001-12/txt/msg00492.txt.bz2

> 
> Boy, this was loads of fun to track down...
> 
> This code has a thinko.
> 
> 
> revision 1.173
> date: 2001/01/07 13:37:32;  author: hubicka;  state: Exp;  lines: +27 -9
> 
>         * combine.c (combine_simplify_rtx): Recognize the unordered compares.
>         (nonzero_bits): Likewise.
>         (simplify_comparison): Likewise.
>         (num_sign_bit_copies): Likewise; return more sane value depending
>         on STORE_FLAG_VALUE.
>         (known_cond): Do not assume EQ to be always true for equivalent
>         operands.
> 
> 
> It introduced the !FLOAT_MODE_P part of the conditional below in 
> combine.c::known_cond.
> 
>   if (cond == EQ && rtx_equal_p (x, reg) && !FLOAT_MODE_P (cond))
>     return val;
> 
> Applying FLOAT_MODE_P to an RTX_CODE doesn't produce a particularly useful
> or predictable value :(  Depending on precisely where things land in memory
> the condition above can give different results for the same values of COND,
> X & REG.  Not good.
> 
> Presumably you wanted to check that neither operand of COND is a floating
> point type.  Right?
Yes, thats precisely what I was shooting for.  It is amazing that such a bug
survived so long time in the compiler.

Should I prepare patch to fix the condtiional?

Thanks for letting me know!
Honza
> 
> The net result was that I was getting different code for the following
> function between a stage1 and stage2 compiler on the PA...
> 
> int optind = 0;
> static enum
> {
>   REQUIRE_ORDER, PERMUTE, RETURN_IN_ORDER
> } ordering;
> static int first_nonopt;
> static int last_nonopt;
> int
> _getopt_internal (argc, argv, optstring, longopts, longind, long_only)
>      int argc;
>      char *const *argv;
>      const char *optstring;
>      const struct option *longopts;
>      int *longind;
>      int long_only;
> {
>           if (first_nonopt != last_nonopt && last_nonopt != optind)
>             exchange ((char **) argv);
>           else if (last_nonopt != optind)
>             first_nonopt = optind;
> }
> 
> [ Note this code is from getopt.c which is not bootstrapped when we
>   do a make bootstrap which is why it went undiscovered for so long. ]
> 
> jeff