And sorry, I did not finish "make check" at the time point. I wasted my time resources (of my free time) on constructing PC environments and my x86_64 laptop environments.
- x86_64 laptop under ubuntu: try to update 'libc6' package to install 'autogen'. At last, I succeed: overwrite libc6 package files under individual living system, and then modify dpkg config file manually. - PC environments: I failed, the reason is my PC hardware is not stable enough (low quality). After building several hours, the machine will reboot automatically (tried several times, each needs several hours). And I shall try to finish as soon as possible (may tomorrow or the day after tomorrow, under Mac book; and within a week under x86_64 laptop). At present, the related patch v2 is below, if possible, please check. Thanks. -------------------------patch begin------------------------------------ gcc/c/c-aux-info.c: Resize 'buff' from 10 to 23 bytes int_size_in_bytes() returns HOST_WIDE_INT (64-bit), theoretically, the maximized size is 23 -- it is sizeof("[-9223372036854775808]") for 0x8000000000000000LL. It may not cause real world issue, but if another issues occur, it may lead things worse. 2014-08-17 Chen Gang <gang.chen.5...@gmail.com> * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes. --- gcc/c/c-aux-info.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gcc/c/c-aux-info.c b/gcc/c/c-aux-info.c index 4b6b2d0..878807b 100644 --- a/gcc/c/c-aux-info.c +++ b/gcc/c/c-aux-info.c @@ -310,9 +310,10 @@ gen_type (const char *ret_val, tree t, formals_style style) TREE_TYPE (t), style); else { - int size = (int_size_in_bytes (t) / int_size_in_bytes (TREE_TYPE (t))); - char buff[10]; - sprintf (buff, "[%d]", size); + char buff[23]; + sprintf (buff, "["HOST_WIDE_INT_PRINT_DEC"]", + int_size_in_bytes (t) + / int_size_in_bytes (TREE_TYPE (t))); ret_val = gen_type (concat (ret_val, buff, NULL), TREE_TYPE (t), style); } -------------------------patch end-------------------------------------- On 8/12/14 11:41, Chen Gang wrote: > > > On 8/12/14 7:38, Mike Stump wrote: >> On Aug 11, 2014, at 2:27 PM, Chen Gang <gang.chen.5...@gmail.com> wrote: >>> Welcome additional disccusions or completions, and if no any additional >>> reply within 1 week, I shall send patch v2 for it (still use sprintf). >> >> So, my take is it is easier for a maintainer to re-review if you do it >> without additional delay. I’d recommend addressing the review points and >> posting without waiting a week in this case. Waiting is useful if a review >> point is contentious. >> > > OK, thanks. What you said sounds reasonable to me. > > But excuse me, I have no enough time resource on it, and also, I am > still not quite familiar with building and checking (especially it needs > a long time to build and check which has negative effect for analyzing). > > So, excuse me again, I have to need more time period on it. But I should > try send patch v2 for it within this week (2014-08-17). > > > And still welcome additional ideas, suggestions or completions. > > Thanks. > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed