Fortran vector math header
Martin Liška
mliska@suse.cz
Mon Jan 21 07:47:00 GMT 2019
On 1/18/19 9:39 AM, Jakub Jelinek wrote:
> On Fri, Jan 18, 2019 at 09:18:33AM +0100, Martin Liška wrote:
>> What about something as simple as this:
>>
>> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
>> index 3314e176881..2f2b965f97d 100644
>> --- a/gcc/fortran/decl.c
>> +++ b/gcc/fortran/decl.c
>> @@ -11361,6 +11361,11 @@ gfc_match_gcc_builtin (void)
>> else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
>> clause = SIMD_INBRANCH;
>>
>> + /* Filter builtins defined only for 64-bit compilation mode. */
>> + if (gfc_match (" ( 64bit ) ") == MATCH_YES
>> + && tree_to_uhwi (TYPE_SIZE_UNIT (long_integer_type_node)) != 64)
>> + return MATCH_YES;
>> +
>> if (gfc_vectorized_builtins == NULL)
>> gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> ();
>>
>> That would allow to write:
>> !GCC$ builtin (cos) attributes simd (notinbranch) (64bit)
>
> That feels too hacky to me.
> We could have
> !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64-linux-gnu')
> or similar if we can agree and get somehow canonical names of the multilib
> targets based on options, or just if('lp64'), if('ilp32'), or whatever other
> identifiers. The multiarch-style strings I'm afraid we have no way to
> propagate to f951 even on multiarch targets, if I understand it right, it is
> present there just in the form of substrings in the multi os directories.
> For some other strings, we'd need to come up with something that generates
> the strings for us, e.g. like config/*/*-d.c does for D have something
> similar for Fortran, and then we could use just x86_64, x32 and x86 or
> whatever else we choose (I guess the OS isn't that important, different OSes
> would have different headers). Even x86_64 vs. x32 vs. x86 shows that it
> isn't possible to differentiate multilibs just based on sizes (kinds) of C
> types, and even querying those is complicated because one needs to use the
> use iso_c_binding, only: c_ptr etc. to get those into the scope, which isn't
> something we want in these headers.
> In any case, glibc would need to agree with gfortran on these identifiers.
>
> Jakub
>
Hello.
I like the if('lp64'), if('ilp32') approach and I'm sending patch candidate for that.
Would it be accepted by glibc folks?
Thanks,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-if-statement-in-GCC-builtin-directive.patch
Type: text/x-patch
Size: 1352 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190121/dc098d31/attachment.bin>
More information about the Gcc-patches
mailing list