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
>From d21476c2223e6e5d12a949b4e2ba26417e37852b Mon Sep 17 00:00:00 2001
From: marxin <mli...@suse.cz>
Date: Mon, 21 Jan 2019 08:46:06 +0100
Subject: [PATCH] Support if statement in !GCC$ builtin directive.

---
 gcc/fortran/decl.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 3314e176881..5c7c062574b 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -11351,6 +11351,7 @@ match
 gfc_match_gcc_builtin (void)
 {
   char builtin[GFC_MAX_SYMBOL_LEN + 1];
+  char target[GFC_MAX_SYMBOL_LEN + 1];
 
   if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
     return MATCH_ERROR;
@@ -11361,6 +11362,24 @@ gfc_match_gcc_builtin (void)
   else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
     clause = SIMD_INBRANCH;
 
+  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
+    {
+      unsigned HOST_WIDE_INT size_of_long
+	= tree_to_uhwi (TYPE_SIZE_UNIT (long_integer_type_node));
+      if (strcmp (target, "lp64") == 0)
+	{
+	  if (size_of_long != 8)
+	    return MATCH_YES;
+	}
+      else if (strcmp (target, "ilp32") == 0)
+	{
+	  if (size_of_long != 4)
+	    return MATCH_YES;
+	}
+      else
+	return MATCH_ERROR;
+    }
+
   if (gfc_vectorized_builtins == NULL)
     gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> ();
 
-- 
2.20.1

Reply via email to