| Message ID | CAFULd4YfYZSNpwXjAD-e5Z+p-yMvO0Msji36X3nWsjdzdwMDkQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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... Jakub
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). (nothing wrong with INTTYPE_MAXIMUM, just an alternative)
On Tue, Nov 11, 2014 at 1:23 AM, Marc Glisse <marc.glisse@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. Thanks, Andrew > > (nothing wrong with INTTYPE_MAXIMUM, just an alternative) > > -- > Marc Glisse
On Tue, Nov 11, 2014 at 1:08 PM, Andrew Pinski <pinskia@gmail.com> wrote: > On Tue, Nov 11, 2014 at 1:23 AM, Marc Glisse <marc.glisse@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
On Tue, Nov 11, 2014 at 4:54 AM, Richard Biener <richard.guenther@gmail.com> wrote: > On Tue, Nov 11, 2014 at 1:08 PM, Andrew Pinski <pinskia@gmail.com> wrote: >> On Tue, Nov 11, 2014 at 1:23 AM, Marc Glisse <marc.glisse@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. C++03 did not add long long, only C++11 did. Thanks, Andrew Pinski > > Richard. > >> Thanks, >> Andrew >> >>> >>> (nothing wrong with INTTYPE_MAXIMUM, just an alternative) >>> >>> -- >>> Marc Glisse
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>