| Message ID | BLU436-SMTP176E775F706A8F10E34D44B97CB0@phx.gbl |
|---|---|
| State | New |
| Headers | show |
On Sun, Sep 14, 2014 at 9:04 PM, John David Anglin <dave.anglin@bell.net> wrote: > On 8-Sep-14, at 5:21 AM, Richard Biener wrote: > >> On Sun, Sep 7, 2014 at 7:36 PM, John David Anglin <dave.anglin@bell.net> >> wrote: >>> >>> The attached patch fixes bootstrap on hpux which doesn't have the atoll >>> function. >>> >>> Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. >>> >>> OK for trunk? >> >> >> "ll" is not portable (it's GNU), I think BSD uses "q" and windows may >> use sth else. I think the code shouldn't use 'long long' but int64_t >> and the appropriate SCNd64 macros for the sscanf format specifier. > > > Attached is an updated version using the SCNd64 macro. It works fine > on hpux. The PRI/SCN macrocs are available back to at least hpux10.20. Ok, I'd be happy to require all hosts having "proper" inttypes.h. So if it works this way for SCNd64 maybe we can remove the "hand-crafting" of PRId64 stuff in hwint.h ... (or we have to hand-craft SCNd64 as well...). After all atoll is C99 as well... > The other alternative is to use the atoll implementation in read-rtl.c. Also a possibility. Which would ask for a libiberty implementation I suppose. > Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. > > OK for trunk? Let's wait for other opinions. Thanks, Richard. > Dave > -- > John David Anglin dave.anglin@bell.net > >
On 15-Sep-14, at 5:40 AM, Richard Biener wrote:
> Let's wait for other opinions.
We now have implementations of strtol and strtoll in libiberty. So,
it's better to use
these than atoll. As suggested by Jakub, the patch now falls back to
int64_t if the
host doesn't have long long.
Tested on hppa2.0w-hpux11.11 and hppa64-hp-hpux11.11.
Okay for trunk?
Dave
--
John David Anglin dave.anglin@bell.net
Ping. On 24-Nov-14, at 7:38 PM, John David Anglin wrote: > On 15-Sep-14, at 5:40 AM, Richard Biener wrote: > >> Let's wait for other opinions. > > We now have implementations of strtol and strtoll in libiberty. So, > it's better to use > these than atoll. As suggested by Jakub, the patch now falls back > to int64_t if the > host doesn't have long long. > > Tested on hppa2.0w-hpux11.11 and hppa64-hp-hpux11.11. > > Okay for trunk? > > Dave > -- > John David Anglin dave.anglin@bell.net > > > <gcov-tool.c.d.3> Dave -- John David Anglin dave.anglin@bell.net
On Sat, Dec 20, 2014 at 11:51 PM, John David Anglin <dave.anglin@bell.net> wrote: > Ping. Ok. Thanks, Richard. > > On 24-Nov-14, at 7:38 PM, John David Anglin wrote: > >> On 15-Sep-14, at 5:40 AM, Richard Biener wrote: >> >>> Let's wait for other opinions. >> >> >> We now have implementations of strtol and strtoll in libiberty. So, it's >> better to use >> these than atoll. As suggested by Jakub, the patch now falls back to >> int64_t if the >> host doesn't have long long. >> >> Tested on hppa2.0w-hpux11.11 and hppa64-hp-hpux11.11. >> >> Okay for trunk? >> >> Dave >> -- >> John David Anglin dave.anglin@bell.net >> >> >> <gcov-tool.c.d.3> > > > > Dave > -- > John David Anglin dave.anglin@bell.net > > >
Index: gcov-tool.c =================================================================== --- gcov-tool.c (revision 215242) +++ gcov-tool.c (working copy) @@ -288,7 +288,7 @@ int opt; int ret; const char *output_dir = 0; - long long normalize_val = 0; + int64_t normalize_val = 0; float scale = 0.0; int numerator = 1; int denominator = 1; @@ -308,7 +308,7 @@ break; case 'n': if (!do_scaling) - normalize_val = atoll (optarg); + sscanf (optarg, "%" SCNd64, &normalize_val); else fnotice (stderr, "scaling cannot co-exist with normalization," " skipping\n");