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 <[email protected]>
* 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 <[email protected]> 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
