The patch has no effect with other target, I have no problem with this patch .
On Wed, Aug 17, 2011 at 12:09 PM, ruifen Shen <shenr...@gmail.com> wrote:
> There is no change for x86 target in my patch in fact.
> yongchong:
> Could you please double check that? thx very much.
>
> 2011/8/17 Sun Chan <sun.c...@gmail.com>
>>
>> Looks fine to me now. Except your change is not a few lines and could
>> affect x86 side, can someone with x86 machine double test this patch?
>> Sun
>>
>> On Wed, Aug 17, 2011 at 11:34 AM, ruifen Shen <shenr...@gmail.com> wrote:
>> > a ,sorry, an error patch.
>> > Please forgot that. So sorry.
>> > A new patch is attached.
>> >
>> > 2011/8/17 Sun Chan <sun.c...@gmail.com>
>> >>
>> >> why don't you use function overload for Build_TN_Of_Mtype
>> >> this will make the code cleaner and more uniform. The implementation
>> >> is hidden in the actual call (with different parameter) and the
>> >> implementation of the function. The caller does not need to know
>> >> whether it is emulated or what.
>> >> Sun
>> >>
>> >> On Tue, Aug 16, 2011 at 6:28 PM, ruifen Shen <shenr...@gmail.com>
>> >> wrote:
>> >> > hi, sun & yongchong.
>> >> > Another patch has been attached for emulate longlong and float-point.
>> >> > Please give a review.
>> >> > This patch has been gone through SL's regression tests.
>> >> > Thanks very much.
>> >> >
>> >> > 2011/8/11 Sun Chan <sun.c...@gmail.com>
>> >> >>
>> >> >> why are you adding EMULATE in the function name? The function name
>> >> >> should not review the implementation inside.
>> >> >> Sun
>> >> >>
>> >> >> On Thu, Aug 11, 2011 at 6:11 PM, ruifen Shen <shenr...@gmail.com>
>> >> >> wrote:
>> >> >> > hi.
>> >> >> > Could you please give a review about another patch for this
>> >> >> > bug?
>> >> >> > The last patch can not work for SL-target as long long and
>> >> >> > float
>> >> >> > point
>> >> >> > are emulated by INT for SL.
>> >> >> >
>> >> >> > Thx very much.
>> >> >> >
>> >> >> >>>>
>> >> >> >>>> HI,
>> >> >> >>>> Could a gatekeeper review the attached patch for a compiler
>> >> >> >>>> assertion
>> >> >> >>>> in the EBO phase of CG when -O1 is given?
>> >> >> >>>> To see the assertion, DBG build compiler should be used.
>> >> >> >>>>
>> >> >> > 2011/8/10 ruifen Shen <shenr...@gmail.com>
>> >> >> >>
>> >> >> >> hah, Welcome!
>> >> >> >>
>> >> >> >> 2011/8/10 Wu Yongchong <wuyongch...@gmail.com>
>> >> >> >>>
>> >> >> >>> Hi, ruifen
>> >> >> >>> I have changed the patch as your suggestion, no need to call the
>> >> >> >>> Allocate_Result_TN for result and field_tn in then-clause.
>> >> >> >>> Thanks
>> >> >> >>> very much.
>> >> >> >>>
>> >> >> >>> On Tue, Aug 9, 2011 at 2:42 PM, ruifen Shen <shenr...@gmail.com>
>> >> >> >>> wrote:
>> >> >> >>> > Is the following code better in the last part of the patch?
>> >> >> >>> >
>> >> >> >>> > TN *field_tn;
>> >> >> >>> > TN *result;
>> >> >> >>> > TYPE_ID desc = Mtype_TransferSign(MTYPE_U4,
>> >> >> >>> > WN_desc(istbits));
>> >> >> >>> > TYPE_ID rtype = desc;
>> >> >> >>> > // U4CONSTANT 1
>> >> >> >>> > // Addr
>> >> >> >>> > // for U8ISTBITS
>> >> >> >>> > // allocate larger TNs if bit deposit may run out of range
>> >> >> >>> > if(MTYPE_byte_size(rtype) > MTYPE_byte_size(WN_rtype(kid0)))
>> >> >> >>> > {
>> >> >> >>> > field_tn = Build_TN_Of_Mtype (rtype);
>> >> >> >>> > result = Build_TN_Of_Mtype (rtype);
>> >> >> >>> > } else { // guard against U1MPY or U2MPY
>> >> >> >>> > field_tn = Allocate_Result_TN (kid0, NULL);
>> >> >> >>> > result = Allocate_Result_TN (kid0, NULL);
>> >> >> >>> > }
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > 2011/8/9 Jian-Xin Lai <laij...@gmail.com>
>> >> >> >>> >>
>> >> >> >>> >> Looks fine to me.
>> >> >> >>> >>
>> >> >> >>> >> 2011/8/8 Wu Yongchong <wuyongch...@gmail.com>
>> >> >> >>> >>>
>> >> >> >>> >>> HI,
>> >> >> >>> >>> Could a gatekeeper review the attached patch for a compiler
>> >> >> >>> >>> assertion
>> >> >> >>> >>> in the EBO phase of CG when -O1 is given?
>> >> >> >>> >>> To see the assertion, DBG build compiler should be used.
>> >> >> >>> >>>
>> >> >> >>> >>> Bug description:
>> >> >> >>> >>> ----------------
>> >> >> >>> >>>
>> >> >> >>> >>> test case:
>> >> >> >>> >>> #pragma pack (2)
>> >> >> >>> >>>
>> >> >> >>> >>> struct S4
>> >> >> >>> >>> {
>> >> >> >>> >>> short a;
>> >> >> >>> >>> short b : 11;
>> >> >> >>> >>> int e : 18;
>> >> >> >>> >>> };
>> >> >> >>> >>> #pragma pack (0)
>> >> >> >>> >>>
>> >> >> >>> >>> void test_4(void)
>> >> >> >>> >>> {
>> >> >> >>> >>> struct S4 s;
>> >> >> >>> >>>
>> >> >> >>> >>> s.e = -6619;
>> >> >> >>> >>> vfy_S4(&s);
>> >> >> >>> >>> }
>> >> >> >>> >>>
>> >> >> >>> >>> When the above test case is compiled with the following
>> >> >> >>> >>> command,
>> >> >> >>> >>> $ opencc min.c -c -O1
>> >> >> >>> >>>
>> >> >> >>> >>> the following assertion is hit:
>> >> >> >>> >>> ### Gen_Literal_TN: 4-byte literal 0xf989400000000000 is
>> >> >> >>> >>> out-of-range
>> >> >> >>> >>>
>> >> >> >>> >>> This assertion failure is within a routine called
>> >> >> >>> >>> Gen_Literal_TN,
>> >> >> >>> >>> which is given a size of 4 and a constant value of
>> >> >> >>> >>> -465770717711958016, which is outside the value range of 4
>> >> >> >>> >>> bytes.
>> >> >> >>> >>> Gen_Literal_TN makes a constant TN with the given size and
>> >> >> >>> >>> value.
>> >> >> >>> >>> The
>> >> >> >>> >>> routine is called from inside Fold_Constant_Expression for
>> >> >> >>> >>> the
>> >> >> >>> >>> following OP.
>> >> >> >>> >>> TN149 :- ldc32 (0xffffffffffffe625) ;
>> >> >> >>> >>> TN153 :- shli64 TN149 (0x2e) ;
>> >> >> >>> >>> Here, TN149 has -6619 in 4 byte storage and it is shifted to
>> >> >> >>> >>> the
>> >> >> >>> >>> left
>> >> >> >>> >>> by 46 bits (0x2e). Thus the resulting value of this shift
>> >> >> >>> >>> left
>> >> >> >>> >>> operation is outside the range of the 4 byte storage of
>> >> >> >>> >>> TN153.
>> >> >> >>> >>>
>> >> >> >>> >>> The source code for the above CG IR is as follows.
>> >> >> >>> >>> struct S4 s;
>> >> >> >>> >>> s.e = -6619;
>> >> >> >>> >>>
>> >> >> >>> >>> And the above CG IR is generated from the following WHIRL.
>> >> >> >>> >>> I4INTCONST -6619 (0xffffffffffffe625)
>> >> >> >>> >>> I8STBITS 0 <bofst:27 bsize:18> <2,1,s> T<5,.predef_I8,8>
>> >> >> >>> >>> {line:
>> >> >> >>> >>> 18}
>> >> >> >>> >>>
>> >> >> >>> >>> The problem is that the size of TN153 is generated from the
>> >> >> >>> >>> kid
>> >> >> >>> >>> of
>> >> >> >>> >>> STBITS, which is I4. As can be seen from the above WHIRL IR,
>> >> >> >>> >>> the
>> >> >> >>> >>> result type of the kid (I4) does not match the descriptor
>> >> >> >>> >>> type
>> >> >> >>> >>> of
>> >> >> >>> >>> the
>> >> >> >>> >>> parent(I8).
>> >> >> >>> >>>
>> >> >> >>> >>> This problem does not occur with -O0 because constant
>> >> >> >>> >>> folding
>> >> >> >>> >>> is
>> >> >> >>> >>> not
>> >> >> >>> >>> invoked. Also, it does not occur with -O2 and above because
>> >> >> >>> >>> the
>> >> >> >>> >>> WOPT
>> >> >> >>> >>> converts the above WHIRL into the following.
>> >> >> >>> >>> I8I8LDID 0 <2,1,s> T<5,.predef_I8,8>
>> >> >> >>> >>> I8INTCONST -6619 (0xffffffffffffe625)
>> >> >> >>> >>> I8COMPOSE_BITS <bofst:27 bsize:18>
>> >> >> >>> >>> I8STID 0 <2,1,s> T<5,.predef_I8,8> {line: 1/18}
>> >> >> >>> >>> So, this is a problem only at -O1 level.
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>> --
>> >> >> >>> >>> yongchong
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>>
>> >> >> >>> >>> ------------------------------------------------------------------------------
>> >> >> >>> >>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco,
>> >> >> >>> >>> CA
>> >> >> >>> >>> The must-attend event for mobile developers. Connect with
>> >> >> >>> >>> experts.
>> >> >> >>> >>> Get tools for creating Super Apps. See the latest
>> >> >> >>> >>> technologies.
>> >> >> >>> >>> Sessions, hands-on labs, demos & much more. Register early &
>> >> >> >>> >>> save!
>> >> >> >>> >>> http://p.sf.net/sfu/rim-blackberry-1
>> >> >> >>> >>> _______________________________________________
>> >> >> >>> >>> Open64-devel mailing list
>> >> >> >>> >>> Open64-devel@lists.sourceforge.net
>> >> >> >>> >>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >> >>> >>>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> --
>> >> >> >>> >> Regards,
>> >> >> >>> >> Lai Jian-Xin
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> ------------------------------------------------------------------------------
>> >> >> >>> >> uberSVN's rich system and user administration capabilities
>> >> >> >>> >> and
>> >> >> >>> >> model
>> >> >> >>> >> configuration take the hassle out of deploying and managing
>> >> >> >>> >> Subversion
>> >> >> >>> >> and
>> >> >> >>> >> the tools developers use with it. Learn more about uberSVN
>> >> >> >>> >> and
>> >> >> >>> >> get
>> >> >> >>> >> a
>> >> >> >>> >> free
>> >> >> >>> >> download at: http://p.sf.net/sfu/wandisco-dev2dev
>> >> >> >>> >>
>> >> >> >>> >> _______________________________________________
>> >> >> >>> >> Open64-devel mailing list
>> >> >> >>> >> Open64-devel@lists.sourceforge.net
>> >> >> >>> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >> >>> >>
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > --
>> >> >> >>> > Best Regards.
>> >> >> >>> >
>> >> >> >>> > Shen Ruifen
>> >> >> >>> >
>> >> >> >>> > tel: 010-51266989-226
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> yongchong
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Best Regards.
>> >> >> >>
>> >> >> >> Shen Ruifen
>> >> >> >>
>> >> >> >> tel: 010-51266989-226
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Best Regards.
>> >> >> >
>> >> >> > Shen Ruifen
>> >> >> >
>> >> >> > tel: 010-51266989-226
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ------------------------------------------------------------------------------
>> >> >> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> >> >> > user administration capabilities and model configuration. Take
>> >> >> > the hassle out of deploying and managing Subversion and the
>> >> >> > tools developers use with it.
>> >> >> > http://p.sf.net/sfu/wandisco-dev2dev
>> >> >> > _______________________________________________
>> >> >> > Open64-devel mailing list
>> >> >> > Open64-devel@lists.sourceforge.net
>> >> >> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Best Regards.
>> >> >
>> >> > Shen Ruifen
>> >> >
>> >> > tel: 010-51266989-226
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > Best Regards.
>> >
>> > Shen Ruifen
>> >
>> > tel: 010-51266989-226
>> >
>> >
>
>
>
> --
> Best Regards.
>
> Shen Ruifen
>
> tel: 010-51266989-226
>
>
--
yongchong
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
