From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28])
 by sourceware.org (Postfix) with ESMTPS id 9CF063858C2C
 for <gcc-patches@gcc.gnu.org>; Thu,  3 Feb 2022 12:13:30 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9CF063858C2C
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
 by smtp-out1.suse.de (Postfix) with ESMTP id 4CFDC210F8;
 Thu,  3 Feb 2022 12:13:29 +0000 (UTC)
Received: from murzim.suse.de (murzim.suse.de [10.160.4.192])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by relay2.suse.de (Postfix) with ESMTPS id 18899A3B88;
 Thu,  3 Feb 2022 12:13:29 +0000 (UTC)
Date: Thu, 3 Feb 2022 13:13:29 +0100 (CET)
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
cc: Eric Botcazou <botcazou@adacore.com>, gcc-patches@gcc.gnu.org, 
 Zhao Wei Liew <zhaoweiliew@gmail.com>
Subject: Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization
 [PR104280]
In-Reply-To: <20220203111810.GL2646553@tucnak>
Message-ID: <12oonr96-382n-6s3-58so-o165n768228@fhfr.qr>
References: <CALHvHFUuCO13CFatCQdJArg9j7fhSpjGp8Yvx2ws3bPb+d8Teg@mail.gmail.com>
 <2228044.ElGaqSPkdT@fomalhaut> <612pq5qr-38s3-2767-9os8-q334254n8p5r@fhfr.qr>
 <11915893.O9o76ZdvQC@fomalhaut> <20220203093334.GJ2646553@tucnak>
 <rr74r6no-91q0-568-r023-5074s151n6o7@fhfr.qr>
 <20220203095526.GK2646553@tucnak>
 <6r4nor91-9n33-82ro-q939-1p7542q4240@fhfr.qr>
 <20220203111810.GL2646553@tucnak>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,
 SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 03 Feb 2022 12:13:32 -0000

On Thu, 3 Feb 2022, Jakub Jelinek wrote:

> On Thu, Feb 03, 2022 at 12:03:15PM +0100, Richard Biener wrote:
> > But as said, for the libgcc2.c case I'd simply remove all of it.
> 
> I can't read RMS' mind, it is indeed UB, so we can do anything, but I bet
> it was just a QoI attempt, when (most of the time) normal single-word
> or smaller division for / 0 behaves certain way (SIGFPE with FPE_INTDIV,
> or being ignored, or whatever else) that it would be nice if the multi-word
> division behaved likewise.
> On the platforms where it is SIGFPE with FPE_INTDIV, raising that would
> help people figure out what's going on.

Yes, I think the intent is clear.  The question is whether we should
re-instantiate the clear intent of preserving a literal / 0 as well
(for C, without -fnon-call-exceptions).

That said, I'm fine with the asms but they are ugly ;)

Richard.