Sounds good.
2011/9/21 Gang Yu <yugang...@gmail.com>
> Jianxin:
>
> How about this?
>
>
> --- a/osprey/common/util/options_stack.h
> +++ b/osprey/common/util/options_stack.h
> @@ -56,7 +56,7 @@
>
> // number of bytes needed to store all options
> // as we save them, we count them, but if we are over we need to recompile
> -#define OPTIONS_SIZE 2720
> +#define OPTIONS_SIZE 4080
>
> class OPTIONS_STACK {
> private:
>
>
> Regards
> Gang
>
>
>
> On Wed, Sep 21, 2011 at 9:20 AM, Jian-Xin Lai <laij...@gmail.com> wrote:
>
>> It looks like we don't need to double the buffer size since it's not very
>> often to add new options. I guess 1.2x or 1.5x is enough.
>>
>> 2011/9/20 Gang Yu <yugang...@gmail.com>
>>
>>> Hi,
>>>
>>> Could a gatekeeper help review the fix for bug 875, itanium debug
>>> compiler build broken?
>>>
>>> ### Assertion failure at line 1339 of
>>> /fc/proj/ctires/open64/o64guru/src/Fri/trunk/osprey/common/util/flags.c:
>>> ### Compiler Error in file
>>> /fc/proj/ctires/open64/o64guru/src/Fri/trunk/osprey/libm/vacos.c during Back
>>> End Driver phase:
>>> ### OPTIONS_SIZE in options_stack.h needs to be bigger
>>>
>>> This bug is due to check-in r3735, which introduce additional 4 options:
>>>
>>> WOPT_Enable_ZDL...
>>>
>>> This makes the option space overflow, so the assertion throws out:
>>> Is_True(offset < size,
>>> ("OPTIONS_SIZE in options_stack.h needs to be bigger\n"));
>>>
>>> Investigation shows that the required bytes for current options:
>>> ia64 2728
>>> x86 2620
>>>
>>> The suggested patch:
>>> --- a/osprey/common/util/options_stack.h
>>> +++ b/osprey/common/util/options_stack.h
>>> @@ -56,7 +56,7 @@
>>>
>>> // number of bytes needed to store all options
>>> // as we save them, we count them, but if we are over we need to recompile
>>> -#define OPTIONS_SIZE 2720
>>> +#define OPTIONS_SIZE 5440
>>>
>>> class OPTIONS_STACK {
>>> private:
>>>
>>>
>>>
>>> Thanks
>>>
>>> Regards
>>> Gang
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> Open64-devel mailing list
>>> Open64-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>
>>>
>>
>>
>> --
>> Regards,
>> Lai Jian-Xin
>>
>
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
