This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes


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.
>>
> 


-- 
Chen Gang

Open share and attitude like air water and life which God blessed


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]