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
emulate_type.patch
Description: Binary data
------------------------------------------------------------------------------ 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
