From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18952 invoked by alias); 30 Nov 2004 03:12:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18861 invoked from network); 30 Nov 2004 03:12:09 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 30 Nov 2004 03:12:09 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (sccrmhc11) with SMTP id <20041130031208011005oql2e>; Tue, 30 Nov 2004 03:12:08 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 30 Nov 2004 04:25:00 -0000 Subject: Re: INT_MIN % -1 From: Paul Schlie To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2004-11/txt/msg01188.txt.bz2 > Andreas wrote: >> terra@gnome.org (Morten Welinder) writes: >> >> gcc 3.4 on solaris/sparc seems to get zero; gcc 3.3.1 on linux gives me a >> crash at runtime. (Because the signed integer division instruction traps > as documented.) > > FWIW, on m68k you'll get -1 (because the divs insn does not modify the > operands on overflow and doesn't trap either). Then would guess divs shouldn't be used with operands which may yield needlessly incorrect results, and would guess it should likely be considered a code-generator bug if it is; as a compiler which produces code which may generate needlessly incorrect results (even if misguidedly allowed by the standard), isn't truly as useful as one which reliably produces reasonably correct results. (where I'm assuming: (-INT_MIN / -1) => -1 isn't reasonably correct or necessary, nor is a run-time exception/trap) Although possibly naive, I'd like to think that the C standard won't be used as a crutch, but that GCC may rise above many of the unspecified behaviors, and establish instead, well defined logically consistent useful ones, which others may aspire to emulate.