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