From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23925 invoked by alias); 11 Nov 2014 12:54:47 -0000 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 Received: (qmail 23914 invoked by uid 89); 11 Nov 2014 12:54:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f54.google.com Received: from mail-oi0-f54.google.com (HELO mail-oi0-f54.google.com) (209.85.218.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 11 Nov 2014 12:54:45 +0000 Received: by mail-oi0-f54.google.com with SMTP id a141so6954577oig.13 for ; Tue, 11 Nov 2014 04:54:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.52.3 with SMTP id p3mr219090oeo.82.1415710483788; Tue, 11 Nov 2014 04:54:43 -0800 (PST) Received: by 10.76.101.132 with HTTP; Tue, 11 Nov 2014 04:54:43 -0800 (PST) In-Reply-To: References: <20141111081157.GY5026@tucnak.redhat.com> Date: Tue, 11 Nov 2014 12:56:00 -0000 Message-ID: Subject: Re: [PATCH] c++ify sreal From: Richard Biener To: Andrew Pinski Cc: GCC Patches , Jakub Jelinek , Uros Bizjak , Trevor Saunders Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00966.txt.bz2 On Tue, Nov 11, 2014 at 1:08 PM, Andrew Pinski wrote: > On Tue, Nov 11, 2014 at 1:23 AM, Marc Glisse wrote: >> On Tue, 11 Nov 2014, Jakub Jelinek wrote: >> >>> On Tue, Nov 11, 2014 at 08:51:41AM +0100, Uros Bizjak wrote: >>>> >>>> Hello! >>>> >>>>>>> do $subject, and cleanup for always 64 bit hwi. >>>>>>> >>>>>>> >>>>>>> bootstrapped + regtested x86_64-unknown-linux-gnu, ok? >>>>>> >>>>>> >>>>>> Ok. Can you please replace remaining HOST_WIDE_INT >>>>>> vestiges in there with [u]int64_t please? >>>>> >>>>> >>>>> >>>>> This patch breaks the build on debian 6.0: >>>>> >>>>> ../../gcc/sreal.c: In member function =C4=81int64_t sreal::to_int() c= onst=C4=81: >>>>> ../../gcc/sreal.c:159: error: =C4=81INT64_MAX=C4=81 was not declared = in this scope >>>> >>>> >>>> Index: system.h >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- system.h (revision 217338) >>>> +++ system.h (working copy) >>>> @@ -27,6 +27,7 @@ >>>> event inttypes.h gets pulled in by another header it is already >>>> defined. */ >>>> #define __STDC_FORMAT_MACROS >>>> +#define __STDC_LIMIT_MACROS >>>> >>>> /* We must include stdarg.h before stdio.h. */ >>>> #include >>> >>> >>> Still, I don't believe it will be portable everywhere. >>> Can't you use >>> INTTYPE_MAXIMUM (int64_t) instead of INT64_MAX? We already use that >>> in GCC... >> >> >> We could also start using the standard C++ mechanism (numeric_limits). > > Except int64_t does not have to be defined for a C++ implementation. Also not through stdint.h / cstdint? Note that we should only care for what happens in practice here. I hope that at least for more recent standards than C++04 (which is what we require IIRC) they are on parity with C99. Richard. > Thanks, > Andrew > >> >> (nothing wrong with INTTYPE_MAXIMUM, just an alternative) >> >> -- >> Marc Glisse