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