On Tue, Nov 11, 2014 at 1:08 PM, Andrew Pinski <pins...@gmail.com> wrote: > On Tue, Nov 11, 2014 at 1:23 AM, Marc Glisse <marc.gli...@inria.fr> 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 āint64_t sreal::to_int() constā: >>>>> ../../gcc/sreal.c:159: error: āINT64_MAXā was not declared in this scope >>>> >>>> >>>> Index: system.h >>>> =================================================================== >>>> --- 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 <stdarg.h> >>> >>> >>> 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