This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: how to enable vector intrinsic functions in fortran frontend

Tobias Burnus <> wrote on 17.10.2007 19:25:26:
> This has two disadvantage, a small one and a large one. The small one
> is: xlf does not require the user to insert "use ..." before (s)he can
> use VECTOR/VEC_*. And there is a large disadvantage: VECTOR(...) is not
> a user-defined TYPE (= struct, or approx. class), procedure or a module
> variable. It is a new syntax and can therefore not be represented as
> module. Thus you need in any case a flag for VECTOR(...).
> For theVEC_* you can use an intrinsic module, but I actually do not see
> any advantage of doing so as one needs the flag in any case.
> Tobias

Thank you a lot for the explanation and I agree that we perhaps should use 
flags to avoid the incompatibility with XLF. But I still don't think we 
can control both the generic vector type and the target specific 
intrinsics by one flag. Would it be reasonable to have an option 
-fvector-type to allow declaration of vector types, and a target option 
-maltivec to enable the VMX intrinsics, as well as another one, say 
-mspu-intrinsics for those on SPU?

Another question is, if no intrinsic module is used, where should the 
VEC_* functions go? I thought of adding them to the gfc namespace by a 
function, say add_vmx_intrinsics, which does the similar work as 
add_functions does in intrinsic.c. Is this somthing that Fortran frontend 
would accept? Any better ideas to avoid mixing up Fortran generic stuff 
and target specific functions?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]