From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6677 invoked by alias); 15 Jun 2012 18:07:07 -0000 Received: (qmail 6668 invoked by uid 22791); 15 Jun 2012 18:07:06 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jun 2012 18:06:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5FI6OHn008557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jun 2012 14:06:24 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q5FI6M6G020215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Jun 2012 14:06:23 -0400 From: Tom Tromey To: Eric Botcazou Cc: Pedro Alves , gcc-patches@gcc.gnu.org, Tristan Gingold , Richard Henderson , "Joseph S. Myers" , Mike Stump , Jay K Subject: Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c) References: <201206151012.32792.ebotcazou@adacore.com> <4FDAFEEF.5030903@redhat.com> <201206151148.50360.ebotcazou@adacore.com> Date: Fri, 15 Jun 2012 18:08:00 -0000 In-Reply-To: <201206151148.50360.ebotcazou@adacore.com> (Eric Botcazou's message of "Fri, 15 Jun 2012 11:48:49 +0200") Message-ID: <87lijosb4x.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-06/txt/msg01061.txt.bz2 >>>>> "Eric" == Eric Botcazou writes: Pedro> It's not about example, but the fact that host compilers have been Pedro> compiling that code as part of building gcc for years, without anyone Pedro> complaining, afaik. It doesn't matter whether the code pointed at Pedro> is the ugliest or most beautiful code on earth. What matters is whether Pedro> it uses long long unconditionally on all hosts or not. Pedro> IOW, what are the still supported hosts/compilers that don't Pedro> support "long long"? If there are any, it appears none has been used Pedro> in at least the past 5 years, IIU the code correctly. Eric> OK, but GCC still officially requires only an ISO C90 compiler Eric> http://gcc.gnu.org/install/prerequisites.html Eric> so the usage of 'long long' in libdecnumber is a bug that could be Eric> fixed at some point. That's why using it as a precedent isn't the Eric> best thing to do. It's true that this is a pedantic violation; but the point here is that there is no practical barrier to using 'long long'. This code has been in the tree since 2007; so if there is some issue with it, it ought to have surfaced by now. Tom