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