From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
 by sourceware.org (Postfix) with ESMTP id 86FAD383A31F
 for <gcc-patches@gcc.gnu.org>; Wed,  1 Jun 2022 22:06:16 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 86FAD383A31F
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=kernel.crashing.org
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=kernel.crashing.org
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])
 by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 251M5Fnq031682;
 Wed, 1 Jun 2022 17:05:15 -0500
Received: (from segher@localhost)
 by gate.crashing.org (8.14.1/8.14.1/Submit) id 251M5FSO031681;
 Wed, 1 Jun 2022 17:05:15 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to
 segher@kernel.crashing.org using -f
Date: Wed, 1 Jun 2022 17:05:14 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
 Peter Bergner <bergner@linux.ibm.com>, David <dje.gcc@gmail.com>
Subject: Re: [PATCH v2,
 rs6000] Fix ICE on expand bcd<bcd_add_sub>_<code>_<mode> [PR100736]
Message-ID: <20220601220514.GY25951@gate.crashing.org>
References: <41da7001-549d-c7ae-fa6b-534a8faf673e@linux.ibm.com>
 <d0245c0d-a971-549b-b341-8ea085cd067e@linux.ibm.com>
 <20220531235600.GU25951@gate.crashing.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220531235600.GU25951@gate.crashing.org>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL,
 KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2022 22:06:18 -0000

Hi!

On Tue, May 31, 2022 at 06:56:00PM -0500, Segher Boessenkool wrote:
> It's not clear to me how this can ever happen without finite_math_only?
> The patch is safe, sure, but it may the real problem is elsewhere.

So, it is incorrect the RTL for our bcd{add,sub} insns uses CCFP at all.

CCFP stands for the result of a 4-way comparison, regular float
comparison: lt gt eq un.  But bcdadd does not have an unordered at all.
Instead, it has the result of a 3-way comparison (lt gt eq), and bit 3
is set if an overflow happened -- but still exactly one of bits 0..2 is
set then!  (If one of the inputs is an invalid number it sets bits 0..3
to 0001 though.)

So it would be much more correct and sensible to use regular integer
comparison results here, so, CC.

Does that fix the problem?


Segher