I think its fine. I suspect there are currently no other target
(besides x86 and Itanium) that will produce these types. May be
nvidia?
Sun
On Tue, Sep 7, 2010 at 1:08 AM, Jian-Xin Lai <laij...@gmail.com> wrote:
> This patch looks fine to me.
> But since it involves several components, maybe it's better to get global
> keepet's approval?
>
> 2010/9/6 Wu Yongchong <wuyongch...@gmail.com>
>>
>> Here is the new patch
>>
>> On Mon, Sep 6, 2010 at 12:47 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
>> > Yes. Two examples:
>> > +#ifdef TARG_X8664
>> > if (!MTYPE_is_complex(ctype) && !(ctype == MTYPE_V16C8))
>> > +#else
>> > + if (!MTYPE_is_complex(ctype))
>> > +#endif
>> >
>> > We can change to
>> > if (!MTYPE_is_complex(ctype))
>> >
>> > +#ifdef TARG_X8664
>> > if (ltype == MTYPE_V16C8 || MTYPE_is_complex(ltype))
>> > +#else
>> > + if (MTYPE_is_complex(ltype))
>> > +#endif
>> >
>> > We can change to
>> > if (MTYPE_is_complex(ltype))
>> >
>> > 2010/9/5 Wu Yongchong <wuyongch...@gmail.com>
>> >>
>> >> These two lines are still inside the #ifdef TARG_X8664 in the original
>> >> code. Do you mean I move them out of the #ifdef condition?
>> >> By doing this , I'm not only get ride of the #ifdef TARG_X8664, but
>> >> also delete some #ifdef TARG_X8664 in the previous revision.
>> >>
>> >> 2010/9/5 Jian-Xin Lai <laij...@gmail.com>:
>> >> > Another issue (sorry for not pointing it out in the previous mail):
>> >> > MTYPE_V16C4/MTYPE_V16C8 should be also complex data type.
>> >> > I think we should change the mtype.cxx:
>> >> > 116 { MTYPE_V16C4, 128,128,128,16, 16,16, 0, 1, 0,
>> >> > "V16C4",MTYPE_CLASS_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C4 },
>> >> > 117 { MTYPE_V16C8, 128,128,128,16, 16,16, 0, 1, 0,
>> >> > "V16C8",MTYPE_CLASS_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C8 },
>> >> >
>> >> > into
>> >> > 116 { MTYPE_V16C4, 128,128,128,16, 16,16, 0, 1, 0,
>> >> > "V16C4",MTYPE_CLASS_COMPLEX_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C4
>> >> > },
>> >> > 117 { MTYPE_V16C8, 128,128,128,16, 16,16, 0, 1, 0,
>> >> > "V16C8",MTYPE_CLASS_COMPLEX_FLOAT|MTYPE_CLASS_VECTOR,16, MTYPE_V16C8
>> >> > },
>> >> >
>> >> > So that we can get rid of most of the #ifdef TARG_X8664 in the patch.
>> >> > But,
>> >> > since we change the mtypes.cxx, we need more testing on this change.
>> >> >
>> >> > 2010/9/4 Wu Yongchong <wuyongch...@gmail.com>
>> >> >>
>> >> >> sorry, the last email has no attachment, here is the new patch
>> >> >> 2010/9/5 Wu Yongchong <wuyongch...@gmail.com>:
>> >> >> > here is the new patch
>> >> >> > 2010/9/5 Wu Yongchong <wuyongch...@gmail.com>:
>> >> >> >> Hi
>> >> >> >> in ieee_module_support.c function _Ieee_get_underflow_mode_()
>> >> >> >> does
>> >> >> >> not support on IA64.
>> >> >> >> Indeed, I set tow much #ifdef in
>> >> >> >> osprey/libfi/mathlb/mathlb.gmakeinclude. There is just 1 file get
>> >> >> >> compile error.
>> >> >> >>
>> >> >> >> 2010/9/4 Jian-Xin Lai <laij...@gmail.com>:
>> >> >> >>> One comment:
>> >> >> >>> in osprey/libfi/mathlb/mathlb.gmakeinclude
>> >> >> >>> We can enable the module/c binding support/ieee/iso c/etc on
>> >> >> >>> IA-64.
>> >> >> >>> What's
>> >> >> >>> the problem if we compile these files on IA-64?
>> >> >> >>>
>> >> >> >>> 2010/9/2 Wu Yongchong <wuyongch...@gmail.com>
>> >> >> >>>>
>> >> >> >>>> Hi,
>> >> >> >>>> Can gatekeeper help review this patch.
>> >> >> >>>> Revision 3314 break the compiler in IA64 system, this patch
>> >> >> >>>> enclose
>> >> >> >>>> some of the change with #ifdef Macros .
>> >> >> >>>>
>> >> >> >>>> --
>> >> >> >>>> yongchong
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> ------------------------------------------------------------------------------
>> >> >> >>>> This SF.net Dev2Dev email is sponsored by:
>> >> >> >>>>
>> >> >> >>>> Show off your parallel programming skills.
>> >> >> >>>> Enter the Intel(R) Threading Challenge 2010.
>> >> >> >>>> http://p.sf.net/sfu/intel-thread-sfd
>> >> >> >>>> _______________________________________________
>> >> >> >>>> Open64-devel mailing list
>> >> >> >>>> Open64-devel@lists.sourceforge.net
>> >> >> >>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> Regards,
>> >> >> >>> Lai Jian-Xin
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> yongchong
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > yongchong
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> yongchong
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Lai Jian-Xin
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> yongchong
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Lai Jian-Xin
>> >
>>
>>
>>
>> --
>> yongchong
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
