| Message ID | 53F08C26.7000801@gmail.com |
|---|---|
| State | New |
| Headers | show |
Excuse me, I did not finish in time. At present, I shall be mainly focus on testsuite. Before I finish it, I can do nothing (I should do nothing) for this patch. Originally: - I get a PC (not buy), it is low quality which cause reboot after run several hours with full cpu used, I wasted much free time resources on it. - And I also run testsuite under my mac book, but related configuration is always incorrect (although can pass building). - And I also run under my x86_64 ubuntu 12 laptop, it is very slow, and it is also my work machine, so can not build during my working time, or it has much negative effect with my work. Tomorrow I will get a new PC (buy myself) with enough quality (buy from Lenovo speciality stores), and will install fedora 19 or 20 on it. Then hope I can finish testsuite within this month (2014-08-31). By the way, also sorry for another patch which related with microblaze, I have to delay, too. Hope I can finish within next month (2014-09-30). Welcome any ideas, suggestions, or completions. Thanks. On 08/17/2014 07:04 PM, Chen Gang wrote: > > 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.5i5j@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.5i5j@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. >> >
On Sun, 17 Aug 2014, Chen Gang wrote: > 2014-08-17 Chen Gang <gang.chen.5i5j@gmail.com> > > * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes. This patch is OK, subject to testing, though the ChangeLog entry needs to reflect the change to using HOST_WIDE_INT without truncation to int.
On 08/21/2014 02:06 AM, Joseph S. Myers wrote: > On Sun, 17 Aug 2014, Chen Gang wrote: > >> 2014-08-17 Chen Gang <gang.chen.5i5j@gmail.com> >> >> * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes. > > This patch is OK, subject to testing, though the ChangeLog entry needs to > reflect the change to using HOST_WIDE_INT without truncation to int. > OK, thanks, I shall notice about it when send patch v2. I have finished testsuit with "--disable-multilibs", successfully, and all 11 "*.sum" files are the 'same'. I am just running with normal configuration (without "--disable-multilibs"). Hope I can send patch v2 tomorrow. Thanks.
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); }
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.5i5j@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(-) -------------------------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.5i5j@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. >