* [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) [not found] ` <CAFiYyc1cczXvCf1v4PPhHVmuvT_W8RuU+8R05vjuJ=_c_nP-6w@mail.gmail.com> @ 2018-11-14 10:06 ` Martin Liška 2018-11-14 11:35 ` Jakub Jelinek 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-14 10:06 UTC (permalink / raw) To: Richard Biener, Bernhard Fischer Cc: fortran, Thomas Koenig, Toon Moene, Jakub Jelinek, GCC Patches [-- Attachment #1: Type: text/plain, Size: 3793 bytes --] Hi. I'm CCing gcc-patches ML and Jakub, who significantly helped me yesterday. The idea now is to have a driver search for the math header file. When it exists, Fortran FE loads the file (via new -fpre-include option). I can confirm that e.g. roms_r CPU2017 benchmark utilizes couple of simd clones: $ grep simd *.optimized analytical.fppized.f90.229t.optimized: vect__77.555_90 = exp.simdclone.12 (vect__76.554_94); analytical.fppized.f90.229t.optimized: vect__322.866_1061 = sin.simdclone.4 (vect__321.865_1062); bulk_flux.fppized.f90.229t.optimized: vect__506.784_1887 = pow.simdclone.2 (vect__1057.783_1889, { 1.939999999999999946709294817992486059665679931640625e+0, 1.939999999999999946709294817992486059665679931640625e+0 }); gasdev.fppized.f90.229t.optimized: vect__66.139_93 = log.simdclone.0 (vect__65.138_94); lmd_swfrac.fppized.f90.229t.optimized: vect__84.60_182 = exp.simdclone.0 (vect__83.59_183); lmd_swfrac.fppized.f90.229t.optimized: vect__89.69_161 = exp.simdclone.0 (vect__88.68_162); marxin@marxinbox:~/Programming/cpu2017/benchspec/CPU/554.roms_r/build/build_peak_gcc7-m64.0000> grep simd *.optimized analytical.fppized.f90.229t.optimized: vect__77.555_90 = exp.simdclone.12 (vect__76.554_94); analytical.fppized.f90.229t.optimized: vect__322.866_1061 = sin.simdclone.4 (vect__321.865_1062); bulk_flux.fppized.f90.229t.optimized: vect__506.784_1887 = pow.simdclone.2 (vect__1057.783_1889, { 1.939999999999999946709294817992486059665679931640625e+0, 1.939999999999999946709294817992486059665679931640625e+0 }); gasdev.fppized.f90.229t.optimized: vect__66.139_93 = log.simdclone.0 (vect__65.138_94); lmd_swfrac.fppized.f90.229t.optimized: vect__84.60_182 = exp.simdclone.0 (vect__83.59_183); lmd_swfrac.fppized.f90.229t.optimized: vect__89.69_161 = exp.simdclone.0 (vect__88.68_162); and it also finishes successfully. Question I have is about default search locations for the header file. On my machine I can see: access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) Aren't these locations desired for libraries, instead of include locations? Thoughts? Thanks, Martin [-- Attachment #2: 0001-Support-simd-function-declarations-via-a-pre-include.patch --] [-- Type: text/x-patch, Size: 10976 bytes --] From 53579915be2f2566d2bbf8ba52175762b8cea7ec Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Wed, 7 Nov 2018 12:41:19 +0100 Subject: [PATCH] Support simd function declarations via a pre-include. gcc/ChangeLog: 2018-11-14 Martin Liska <mliska@suse.cz> Jakub Jelinek <jakub@redhat.com> * config/gnu-user.h (TARGET_F951_NOSTDINC_OPTIONS): Define new macro. * gcc.c (find_fortran_header_file): New function. gcc/fortran/ChangeLog: 2018-11-14 Martin Liska <mliska@suse.cz> Jakub Jelinek <jakub@redhat.com> * decl.c (gfc_match_gcc_builtin): New function to find new !GCC attribute directive. * gfortran.h (gfc_adjust_builtins): Declre. * match.h (gfc_match_gcc_builtin): New function. * parse.c (decode_gcc_attribute): Parse "builtin" in GCC attributes. (parse_progunit): Modify builtins based on result of GCC builtin parsing. * scanner.c (load_file): Preinclude header if set by the flag_pre_include flag. * trans-intrinsic.c (add_simd_flag_for_built_in): New. (gfc_adjust_builtins): New. --- gcc/config/gnu-user.h | 3 +++ gcc/fortran/decl.c | 33 +++++++++++++++++++++++++ gcc/fortran/gfortran.h | 2 ++ gcc/fortran/lang-specs.h | 8 +++++- gcc/fortran/lang.opt | 4 +++ gcc/fortran/match.h | 1 + gcc/fortran/parse.c | 3 +++ gcc/fortran/scanner.c | 10 ++++++++ gcc/fortran/trans-intrinsic.c | 46 +++++++++++++++++++++++++++++++++++ gcc/gcc.c | 19 +++++++++++++++ 10 files changed, 128 insertions(+), 1 deletion(-) diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index 5b48fb21514..f3ad7cf05fd 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -170,3 +170,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" #endif + +#undef TARGET_F951_NOSTDINC_OPTIONS +#define TARGET_F951_NOSTDINC_OPTIONS "%:fortran-header-file(-fpre-include= math-vector-fortran.h)" diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 2b77d950abb..938c35c508f 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -98,6 +98,9 @@ bool gfc_matching_function; /* Set upon parsing a !GCC$ unroll n directive for use in the next loop. */ int directive_unroll = -1; +/* List middle-end built-ins that should be vectorized. */ +vec<const char *> vectorized_builtins; + /* If a kind expression of a component of a parameterized derived type is parameterized, temporarily store the expression here. */ static gfc_expr *saved_kind_expr = NULL; @@ -11243,3 +11246,33 @@ gfc_match_gcc_unroll (void) gfc_error ("Syntax error in !GCC$ UNROLL directive at %C"); return MATCH_ERROR; } + +/* Match a !GCC$ builtin b attributes flags form: + + The parameter b is name of a middle-end built-in. + Flags are one of: + - omp-simd-notinbranch. + + When we come here, we have already matched the !GCC$ builtin string. */ +match +gfc_match_gcc_builtin (void) +{ + char builtin[GFC_MAX_SYMBOL_LEN + 1]; + + if (gfc_match_name (builtin) != MATCH_YES) + return MATCH_ERROR; + + gfc_gobble_whitespace (); + if (gfc_match ("attributes") != MATCH_YES) + return MATCH_ERROR; + + gfc_gobble_whitespace (); + if (gfc_match ("omp_simd_notinbranch") != MATCH_YES) + return MATCH_ERROR; + + char *r = XNEWVEC (char, strlen (builtin) + 32); + sprintf (r, "__builtin_%s", builtin); + vectorized_builtins.safe_push (r); + + return MATCH_YES; +} diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index d8ef35d9d6c..bb7f4dd0c4b 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -2763,6 +2763,7 @@ gfc_finalizer; bool gfc_in_match_data (void); match gfc_match_char_spec (gfc_typespec *); extern int directive_unroll; +extern vec<const char *> vectorized_builtins; /* Handling Parameterized Derived Types */ bool gfc_insert_kind_parameter_exprs (gfc_expr *); @@ -3501,5 +3502,6 @@ bool gfc_is_reallocatable_lhs (gfc_expr *); /* trans-decl.c */ void finish_oacc_declare (gfc_namespace *, gfc_symbol *, bool); +void gfc_adjust_builtins (void); #endif /* GCC_GFORTRAN_H */ diff --git a/gcc/fortran/lang-specs.h b/gcc/fortran/lang-specs.h index c3ab9700ea7..6f940755801 100644 --- a/gcc/fortran/lang-specs.h +++ b/gcc/fortran/lang-specs.h @@ -32,8 +32,14 @@ #define F951_CPP_OPTIONS "%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \ %{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \ " -fsyntax-only};: " CPP_FORWARD_OPTIONS "}" + +#ifndef TARGET_F951_NOSTDINC_OPTIONS +#define TARGET_F951_NOSTDINC_OPTIONS +#endif + #define F951_OPTIONS "%(cc1_options) %{J*} \ - %{!nostdinc:-fintrinsic-modules-path finclude%s}\ + %{!nostdinc:-fintrinsic-modules-path finclude%s " \ + TARGET_F951_NOSTDINC_OPTIONS "}\ %{!fsyntax-only:%(invoke_as)}" #define F951_SOURCE_FORM "%{!ffree-form:-ffixed-form}" diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt index 2b7f2903761..a9eb58cbf23 100644 --- a/gcc/fortran/lang.opt +++ b/gcc/fortran/lang.opt @@ -662,6 +662,10 @@ fprotect-parens Fortran Var(flag_protect_parens) Init(-1) Protect parentheses in expressions. +fpre-include= +Fortran RejectNegative JoinedOrMissing Var(flag_pre_include) Undocumented +Path to header file that should be pre-included before each compilation unit. + frange-check Fortran Var(flag_range_check) Init(1) Enable range checking during compilation. diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h index 418542bd5a6..f25ed860c06 100644 --- a/gcc/fortran/match.h +++ b/gcc/fortran/match.h @@ -247,6 +247,7 @@ match gfc_match_dimension (void); match gfc_match_external (void); match gfc_match_gcc_attributes (void); match gfc_match_gcc_unroll (void); +match gfc_match_gcc_builtin (void); match gfc_match_import (void); match gfc_match_intent (void); match gfc_match_intrinsic (void); diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c index 13cc6f5fccd..56d0d050bc3 100644 --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -1072,6 +1072,7 @@ decode_gcc_attribute (void) match ("attributes", gfc_match_gcc_attributes, ST_ATTR_DECL); match ("unroll", gfc_match_gcc_unroll, ST_NONE); + match ("builtin", gfc_match_gcc_builtin, ST_NONE); /* All else has failed, so give up. See if any of the matchers has stored an error message of some sort. */ @@ -5663,6 +5664,8 @@ parse_progunit (gfc_statement st) gfc_state_data *p; int n; + gfc_adjust_builtins (); + if (gfc_new_block && gfc_new_block->abr_modproc_decl && gfc_new_block->attr.function) diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c index 55d6dafdb5d..cf56a675a08 100644 --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -2365,6 +2365,16 @@ load_file (const char *realfilename, const char *displayedname, bool initial) } } + /* Make a guard to prevent recursive inclusion. */ + static bool preinclude_done = false; + if (!preinclude_done) + { + preinclude_done = true; + if (flag_pre_include != NULL && !load_file (flag_pre_include, NULL, + false)) + exit (FATAL_EXIT_CODE); + } + /* Preprocessed files have preprocessor lines added before the byte order mark, so first_line is not about the first line of the file but the first line that's not a preprocessor line. */ diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index 4ae2b3252b5..40ff66663eb 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -597,7 +597,53 @@ define_quad_builtin (const char *name, tree type, bool is_const) return fndecl; } +/* Add SIMD attribute for FNDECL built-in if the built-in + name is in VECTORIZED_BUILTINS. */ +static void +add_simd_flag_for_built_in (tree fndecl) +{ + if (fndecl == NULL_TREE) + return; + + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); + for (unsigned i = 0; i < vectorized_builtins.length (); i++) + if (strcmp (vectorized_builtins[i], name) == 0) + { + tree omp_clause = build_omp_clause (UNKNOWN_LOCATION, + OMP_CLAUSE_NOTINBRANCH); + DECL_ATTRIBUTES (fndecl) + = tree_cons (get_identifier ("omp declare simd"), + build_tree_list (NULL_TREE, omp_clause), + DECL_ATTRIBUTES (fndecl)); + return; + } +} + +/* Set SIMD attribute to all built-in functions that are mentioned + in vectorized_builtins vector. */ + +void +gfc_adjust_builtins (void) +{ + gfc_intrinsic_map_t *m; + for (m = gfc_intrinsic_map; + m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++) + { + add_simd_flag_for_built_in (m->real4_decl); + add_simd_flag_for_built_in (m->complex4_decl); + add_simd_flag_for_built_in (m->real8_decl); + add_simd_flag_for_built_in (m->complex8_decl); + add_simd_flag_for_built_in (m->real10_decl); + add_simd_flag_for_built_in (m->complex10_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + } + + vectorized_builtins.truncate (0); +} /* Initialize function decls for library functions. The external functions are created as required. Builtin functions are added here. */ diff --git a/gcc/gcc.c b/gcc/gcc.c index c0d17eb4f1b..1b9370be1d4 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -408,6 +408,7 @@ static const char *pass_through_libs_spec_func (int, const char **); static const char *replace_extension_spec_func (int, const char **); static const char *greater_than_spec_func (int, const char **); static const char *debug_level_greater_than_spec_func (int, const char **); +static const char *find_fortran_header_file (int, const char **); static char *convert_white_space (char *); \f /* The Specs Language @@ -1647,6 +1648,7 @@ static const struct spec_function static_spec_functions[] = { "replace-extension", replace_extension_spec_func }, { "gt", greater_than_spec_func }, { "debug-level-gt", debug_level_greater_than_spec_func }, + { "fortran-header-file", find_fortran_header_file}, #ifdef EXTRA_SPEC_FUNCTIONS EXTRA_SPEC_FUNCTIONS #endif @@ -9889,6 +9891,23 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } +/* The function takes 2 arguments: OPTION name and file name. + When the FILE is found by find_file, return OPTION=path_to_file. */ + +static const char * +find_fortran_header_file (int argc, const char **argv) +{ + if (argc != 2) + return NULL; + + const char *path = find_file (argv[1]); + if (path != argv[1]) + return concat (argv[0], path, NULL); + + return NULL; +} + + /* Insert backslash before spaces in ORIG (usually a file path), to avoid being broken by spec parser. -- 2.19.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) 2018-11-14 10:06 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Martin Liška @ 2018-11-14 11:35 ` Jakub Jelinek 2018-11-14 11:56 ` Jakub Jelinek ` (2 more replies) 0 siblings, 3 replies; 94+ messages in thread From: Jakub Jelinek @ 2018-11-14 11:35 UTC (permalink / raw) To: Martin Liška Cc: Richard Biener, Bernhard Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, Nov 14, 2018 at 11:06:04AM +0100, Martin LiÅ¡ka wrote: > Question I have is about default search locations for the header file. On my machine I can > see: > access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/usr/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/usr/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/usr/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > > Aren't these locations desired for libraries, instead of include locations? That isn't correct indeed. What about find_a_file (&include_prefixes, ... )? Though, in the design where to put the file we really need to have multilib (and multiarch on Debian/Ubuntu) in mind, because e.g. on x86_64-linux you want to find a m64 version of the header for -m64, but a different for -m32 and there is always the possibility somebody installs a 32-bit gfortran on x86_64. > --- a/gcc/config/gnu-user.h > +++ b/gcc/config/gnu-user.h > @@ -170,3 +170,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see > LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ > LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" > #endif > + > +#undef TARGET_F951_NOSTDINC_OPTIONS > +#define TARGET_F951_NOSTDINC_OPTIONS "%:fortran-header-file(-fpre-include= math-vector-fortran.h)" Too long line, use some \s to split it up. > + Flags are one of: > + - omp-simd-notinbranch. So omp-simd-notinbranch or omp_simd_notinbranch? Any particular reason for this weird syntax and for not also supporting inbranch or just simd? > + > + When we come here, we have already matched the !GCC$ builtin string. */ > +match > +gfc_match_gcc_builtin (void) > +{ > + char builtin[GFC_MAX_SYMBOL_LEN + 1]; > + > + if (gfc_match_name (builtin) != MATCH_YES) > + return MATCH_ERROR; > + > + gfc_gobble_whitespace (); > + if (gfc_match ("attributes") != MATCH_YES) > + return MATCH_ERROR; > + > + gfc_gobble_whitespace (); > + if (gfc_match ("omp_simd_notinbranch") != MATCH_YES) > + return MATCH_ERROR; Why so many gfc_match calls? Can't you e.g. just do if (gfc_match ("%n attributes simd", builtin) != MATCH_YES) return MATCH_ERROR; int builtin_kind = 0; /* Or whatever, just want to show the parsing here. */ if (gfc_match ("(notinbranch)") == MATCH_YES) builtin_kind = -1; else if (gfc_match ("(inbranch)") == MATCH_YES) builtin_kind = 1; The space in gfc_match indicates gfc_gobble_whitespace (), i.e. optionally eating whitespace (note, in fixed form white space is optionally eaten pretty much always). If you want a mandatory space, there is "% ". So it depends in if in fixed form we want to support e.g. !GCC$ BUI L TIN SINf ATTRI BUT ESSIMD(NOT IN BRANCH) and in free form e.g. !gcc$ builtin sinf attributessimd (notinbranch) I wouldn't use omp_simd because in C/C++ the attribute is called simd. > + > + char *r = XNEWVEC (char, strlen (builtin) + 32); > + sprintf (r, "__builtin_%s", builtin); > + vectorized_builtins.safe_push (r); Perhaps make it vector of const char *, int pairs, so that you can encode no argument (aka inbranch + notinbranch) vs. inbranch vs. notinbranch? > #define F951_OPTIONS "%(cc1_options) %{J*} \ > - %{!nostdinc:-fintrinsic-modules-path finclude%s}\ > + %{!nostdinc:-fintrinsic-modules-path finclude%s " \ > + TARGET_F951_NOSTDINC_OPTIONS "}\ I wouldn't stick it inside of %{!nostdinc:, but let config/gnu-user.h decide about that (i.e. wrap it into %{!nostdinc: ... } there). > --- a/gcc/fortran/lang.opt > +++ b/gcc/fortran/lang.opt > @@ -662,6 +662,10 @@ fprotect-parens > Fortran Var(flag_protect_parens) Init(-1) > Protect parentheses in expressions. > > +fpre-include= > +Fortran RejectNegative JoinedOrMissing Var(flag_pre_include) Undocumented > +Path to header file that should be pre-included before each compilation unit. Why OrMissing? If the argument is missing, that should be an error, you can't load "". > --- a/gcc/fortran/scanner.c > +++ b/gcc/fortran/scanner.c > @@ -2365,6 +2365,16 @@ load_file (const char *realfilename, const char *displayedname, bool initial) > } > } > > + /* Make a guard to prevent recursive inclusion. */ > + static bool preinclude_done = false; > + if (!preinclude_done) > + { > + preinclude_done = true; > + if (flag_pre_include != NULL && !load_file (flag_pre_include, NULL, > + false)) > + exit (FATAL_EXIT_CODE); > + } Why in load_file? I'd handle this in gfc_new_file, where it is called just once. Formatting - would be nicer to put && on the next line and not wrap load_file args. > +static const char * > +find_fortran_header_file (int argc, const char **argv) > +{ > + if (argc != 2) > + return NULL; > + > + const char *path = find_file (argv[1]); > + if (path != argv[1]) > + return concat (argv[0], path, NULL); I wouldn't call it fortran_header_file but fortran_preinclude_file (both in what appears in spec and the name of the callback). Plus, the patch lacks testcases. I'd use dg-options "-nostdinc" so that in that testcase it isn't preincluded, and have one free form and one fixed form testcase that has various forms of the !gcc$ builtin for a couple of builtins + some calls to them and check how they are handled (perhaps limited to the one or two ABIs that support those)? Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) 2018-11-14 11:35 ` Jakub Jelinek @ 2018-11-14 11:56 ` Jakub Jelinek 2018-11-14 11:57 ` Jakub Jelinek 2018-11-14 14:09 ` [PATCH] Support simd function declarations via a pre-include Martin Liška 2018-11-15 19:40 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Bernhard Reutner-Fischer 2 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2018-11-14 11:56 UTC (permalink / raw) To: Martin Liška Cc: Richard Biener, Bernhard Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, Nov 14, 2018 at 12:35:27PM +0100, Jakub Jelinek wrote: > > + > > + When we come here, we have already matched the !GCC$ builtin string. */ > > +match > > +gfc_match_gcc_builtin (void) > > +{ > > + char builtin[GFC_MAX_SYMBOL_LEN + 1]; > > + > > + if (gfc_match_name (builtin) != MATCH_YES) > > + return MATCH_ERROR; > > + > > + gfc_gobble_whitespace (); > > + if (gfc_match ("attributes") != MATCH_YES) > > + return MATCH_ERROR; > > + > > + gfc_gobble_whitespace (); > > + if (gfc_match ("omp_simd_notinbranch") != MATCH_YES) > > + return MATCH_ERROR; > > Why so many gfc_match calls? Can't you e.g. just do > if (gfc_match ("%n attributes simd", builtin) != MATCH_YES) > return MATCH_ERROR; > > int builtin_kind = 0; /* Or whatever, just want to show the parsing here. */ > if (gfc_match ("(notinbranch)") == MATCH_YES) > builtin_kind = -1; > else if (gfc_match ("(inbranch)") == MATCH_YES) > builtin_kind = 1; > > The space in gfc_match indicates gfc_gobble_whitespace (), i.e. optionally > eating whitespace (note, in fixed form white space is optionally eaten > pretty much always). If you want a mandatory space, there is "% ". > So it depends in if in fixed form we want to support e.g. > !GCC$ BUI L TIN SINf ATTRI BUT ESSIMD(NOT IN BRANCH) > and in free form e.g. > !gcc$ builtin sinf attributessimd (notinbranch) > I wouldn't use omp_simd because in C/C++ the attribute is called simd. One more thing, for fixed form spaces are insignificant generally, gfc_next_char has: do { c = gfc_next_char_literal (NONSTRING); } while (gfc_current_form == FORM_FIXED && gfc_is_whitespace (c)); so a gfc_name in fixed form needs to be separated by something different from whitespace I'd say. Because in !gcc$ builtin sinf attribute simd or !GCC$ BUILTINSINFATTRIBUTESIMD you'd get in both cases sinfattributesimd as the builtin's name and nothing afterwards (so gfc_match would fail). One possibility is if (gfc_match ("(%n) attributes simd", name) == MATCH_YES) where you'd require parens around the builtin's name. Or it could go last in the syntax, i.e. !gcc$ builtin attributes simd sinf !gcc$ builtin attributes simd (notinbranch) sinf But I think ()s are better. Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) 2018-11-14 11:56 ` Jakub Jelinek @ 2018-11-14 11:57 ` Jakub Jelinek 0 siblings, 0 replies; 94+ messages in thread From: Jakub Jelinek @ 2018-11-14 11:57 UTC (permalink / raw) To: Martin Liška Cc: Richard Biener, Bernhard Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, Nov 14, 2018 at 12:56:26PM +0100, Jakub Jelinek wrote: > One possibility is > if (gfc_match ("(%n) attributes simd", name) == MATCH_YES) " (%n) attributes simd" to be precise, so that whitespace is allowed in free form between builtin and (. And the following parsing might be " ( notinbranch )" etc. Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-14 11:35 ` Jakub Jelinek 2018-11-14 11:56 ` Jakub Jelinek @ 2018-11-14 14:09 ` Martin Liška 2018-11-14 14:14 ` Jakub Jelinek 2018-11-15 19:40 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Bernhard Reutner-Fischer 2 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-14 14:09 UTC (permalink / raw) To: Jakub Jelinek Cc: Richard Biener, Bernhard Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/14/18 12:35 PM, Jakub Jelinek wrote: > On Wed, Nov 14, 2018 at 11:06:04AM +0100, Martin LiÅ¡ka wrote: >> Question I have is about default search locations for the header file. On my machine I can >> see: >> access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/usr/lib/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/usr/lib/../lib64/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/../../../math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> access("/usr/lib/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) >> >> Aren't these locations desired for libraries, instead of include locations? > > That isn't correct indeed. > What about find_a_file (&include_prefixes, ... )? Thanks, so setting last argument to true should handle here the multilib support. > Though, in the design where to put the file we really need to have multilib > (and multiarch on Debian/Ubuntu) in mind, because e.g. on x86_64-linux you > want to find a m64 version of the header for -m64, but a different for -m32 > and there is always the possibility somebody installs a 32-bit gfortran on x86_64. > >> --- a/gcc/config/gnu-user.h >> +++ b/gcc/config/gnu-user.h >> @@ -170,3 +170,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see >> LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ >> LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" >> #endif >> + >> +#undef TARGET_F951_NOSTDINC_OPTIONS >> +#define TARGET_F951_NOSTDINC_OPTIONS "%:fortran-header-file(-fpre-include= math-vector-fortran.h)" > > Too long line, use some \s to split it up. > >> + Flags are one of: >> + - omp-simd-notinbranch. > > So omp-simd-notinbranch or omp_simd_notinbranch? > Any particular reason for this weird syntax and for not also > supporting inbranch or just simd? Questionable whether to support as current glibc vector ABI only uses notinbranch? > >> + >> + When we come here, we have already matched the !GCC$ builtin string. */ >> +match >> +gfc_match_gcc_builtin (void) >> +{ >> + char builtin[GFC_MAX_SYMBOL_LEN + 1]; >> + >> + if (gfc_match_name (builtin) != MATCH_YES) >> + return MATCH_ERROR; >> + >> + gfc_gobble_whitespace (); >> + if (gfc_match ("attributes") != MATCH_YES) >> + return MATCH_ERROR; >> + >> + gfc_gobble_whitespace (); >> + if (gfc_match ("omp_simd_notinbranch") != MATCH_YES) >> + return MATCH_ERROR; > > Why so many gfc_match calls? Can't you e.g. just do > if (gfc_match ("%n attributes simd", builtin) != MATCH_YES) > return MATCH_ERROR; > > int builtin_kind = 0; /* Or whatever, just want to show the parsing here. */ > if (gfc_match ("(notinbranch)") == MATCH_YES) > builtin_kind = -1; > else if (gfc_match ("(inbranch)") == MATCH_YES) > builtin_kind = 1; > > The space in gfc_match indicates gfc_gobble_whitespace (), i.e. optionally > eating whitespace (note, in fixed form white space is optionally eaten > pretty much always). If you want a mandatory space, there is "% ". > So it depends in if in fixed form we want to support e.g. > !GCC$ BUI L TIN SINf ATTRI BUT ESSIMD(NOT IN BRANCH) > and in free form e.g. > !gcc$ builtin sinf attributessimd (notinbranch) > I wouldn't use omp_simd because in C/C++ the attribute is called simd. >> + >> + char *r = XNEWVEC (char, strlen (builtin) + 32); >> + sprintf (r, "__builtin_%s", builtin); >> + vectorized_builtins.safe_push (r); > > Perhaps make it vector of const char *, int pairs, so that you can > encode no argument (aka inbranch + notinbranch) vs. inbranch vs. notinbranch? If we want to support the variants, then yes. > >> #define F951_OPTIONS "%(cc1_options) %{J*} \ >> - %{!nostdinc:-fintrinsic-modules-path finclude%s}\ >> + %{!nostdinc:-fintrinsic-modules-path finclude%s " \ >> + TARGET_F951_NOSTDINC_OPTIONS "}\ > > I wouldn't stick it inside of %{!nostdinc:, but let config/gnu-user.h decide > about that (i.e. wrap it into %{!nostdinc: ... } there). Sure, works for me now. > >> --- a/gcc/fortran/lang.opt >> +++ b/gcc/fortran/lang.opt >> @@ -662,6 +662,10 @@ fprotect-parens >> Fortran Var(flag_protect_parens) Init(-1) >> Protect parentheses in expressions. >> >> +fpre-include= >> +Fortran RejectNegative JoinedOrMissing Var(flag_pre_include) Undocumented >> +Path to header file that should be pre-included before each compilation unit. > > Why OrMissing? If the argument is missing, that should be an error, you > can't load "". Ok. > >> --- a/gcc/fortran/scanner.c >> +++ b/gcc/fortran/scanner.c >> @@ -2365,6 +2365,16 @@ load_file (const char *realfilename, const char *displayedname, bool initial) >> } >> } >> >> + /* Make a guard to prevent recursive inclusion. */ >> + static bool preinclude_done = false; >> + if (!preinclude_done) >> + { >> + preinclude_done = true; >> + if (flag_pre_include != NULL && !load_file (flag_pre_include, NULL, >> + false)) >> + exit (FATAL_EXIT_CODE); >> + } > > Why in load_file? I'd handle this in gfc_new_file, where it is called just > once. Formatting - would be nicer to put && on the next line and not wrap > load_file args. Works for me. > >> +static const char * >> +find_fortran_header_file (int argc, const char **argv) >> +{ >> + if (argc != 2) >> + return NULL; >> + >> + const char *path = find_file (argv[1]); >> + if (path != argv[1]) >> + return concat (argv[0], path, NULL); > > I wouldn't call it fortran_header_file but fortran_preinclude_file > (both in what appears in spec and the name of the callback). Done. > > Plus, the patch lacks testcases. I'd use dg-options "-nostdinc" > so that in that testcase it isn't preincluded, and have one free form and > one fixed form testcase that has various forms of the !gcc$ builtin > for a couple of builtins + some calls to them and check how they are handled > (perhaps limited to the one or two ABIs that support those)? Sure, will do as soon as final version of the patch will be done. Thanks, Martin > > Jakub > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-14 14:09 ` [PATCH] Support simd function declarations via a pre-include Martin Liška @ 2018-11-14 14:14 ` Jakub Jelinek 0 siblings, 0 replies; 94+ messages in thread From: Jakub Jelinek @ 2018-11-14 14:14 UTC (permalink / raw) To: Martin Liška Cc: Richard Biener, Bernhard Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, Nov 14, 2018 at 03:09:49PM +0100, Martin LiÅ¡ka wrote: > > So omp-simd-notinbranch or omp_simd_notinbranch? > > Any particular reason for this weird syntax and for not also > > supporting inbranch or just simd? > > Questionable whether to support as current glibc vector ABI only uses notinbranch? simd attribute supports all those three cases, i.e. __attribute__((simd)), __attribute__((simd ("notinbranch"))) and __attribute__((simd ("inbranch"))). So at least for consistency it would be nice to support the same thing. Some users could e.g. provide a vectorized definition for other builtins and have e.g. inbranch support there only (the vectorizer can use those by providing all ones masks). Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) 2018-11-14 11:35 ` Jakub Jelinek 2018-11-14 11:56 ` Jakub Jelinek 2018-11-14 14:09 ` [PATCH] Support simd function declarations via a pre-include Martin Liška @ 2018-11-15 19:40 ` Bernhard Reutner-Fischer 2018-11-15 20:54 ` Jakub Jelinek 2 siblings, 1 reply; 94+ messages in thread From: Bernhard Reutner-Fischer @ 2018-11-15 19:40 UTC (permalink / raw) To: Jakub Jelinek, Martin Liška Cc: Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 14 November 2018 12:35:27 CET, Jakub Jelinek <jakub@redhat.com> wrote: >> --- a/gcc/config/gnu-user.h >> +++ b/gcc/config/gnu-user.h >> @@ -170,3 +170,6 @@ see the files COPYING3 and COPYING.RUNTIME >respectively. If not, see >> LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ >> LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" >> #endif >> + >> +#undef TARGET_F951_NOSTDINC_OPTIONS >> +#define TARGET_F951_NOSTDINC_OPTIONS >"%:fortran-header-file(-fpre-include= math-vector-fortran.h)" > >Too long line, use some \s to split it up. > Can we use plain -include like in C? This has an established meaning and is already documented. Thanks, ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) 2018-11-15 19:40 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Bernhard Reutner-Fischer @ 2018-11-15 20:54 ` Jakub Jelinek 2018-11-16 13:25 ` [PATCH] Support simd function declarations via a pre-include Martin Liška 2018-11-17 21:13 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Bernhard Reutner-Fischer 0 siblings, 2 replies; 94+ messages in thread From: Jakub Jelinek @ 2018-11-15 20:54 UTC (permalink / raw) To: Bernhard Reutner-Fischer Cc: Martin Liška, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Thu, Nov 15, 2018 at 08:40:13PM +0100, Bernhard Reutner-Fischer wrote: > On 14 November 2018 12:35:27 CET, Jakub Jelinek <jakub@redhat.com> wrote: > > >> --- a/gcc/config/gnu-user.h > >> +++ b/gcc/config/gnu-user.h > >> @@ -170,3 +170,6 @@ see the files COPYING3 and COPYING.RUNTIME > >respectively. If not, see > >> LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ > >> LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" > >> #endif > >> + > >> +#undef TARGET_F951_NOSTDINC_OPTIONS > >> +#define TARGET_F951_NOSTDINC_OPTIONS > >"%:fortran-header-file(-fpre-include= math-vector-fortran.h)" > > > >Too long line, use some \s to split it up. > > > > Can we use plain -include like in C? Wouldn't that be confusing whether it is included in preprocessor only or if it is included as a magic fortran include line at the beginning? Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-15 20:54 ` Jakub Jelinek @ 2018-11-16 13:25 ` Martin Liška 2018-11-16 13:50 ` Jakub Jelinek 2018-11-17 21:13 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Bernhard Reutner-Fischer 1 sibling, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-16 13:25 UTC (permalink / raw) To: Jakub Jelinek, Bernhard Reutner-Fischer Cc: Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1136 bytes --] On 11/15/18 9:54 PM, Jakub Jelinek wrote: > On Thu, Nov 15, 2018 at 08:40:13PM +0100, Bernhard Reutner-Fischer wrote: >> On 14 November 2018 12:35:27 CET, Jakub Jelinek <jakub@redhat.com> wrote: >> >>>> --- a/gcc/config/gnu-user.h >>>> +++ b/gcc/config/gnu-user.h >>>> @@ -170,3 +170,6 @@ see the files COPYING3 and COPYING.RUNTIME >>> respectively. If not, see >>>> LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ >>>> LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" >>>> #endif >>>> + >>>> +#undef TARGET_F951_NOSTDINC_OPTIONS >>>> +#define TARGET_F951_NOSTDINC_OPTIONS >>> "%:fortran-header-file(-fpre-include= math-vector-fortran.h)" >>> >>> Too long line, use some \s to split it up. >>> >> >> Can we use plain -include like in C? > > Wouldn't that be confusing whether it is included in preprocessor only or if > it is included as a magic fortran include line at the beginning? > > Jakub > Agree with that, I'm sending updated version of the patch. It's tested on x86_64-linux-gnu, where it survives regression tests and bootstraps. I hope I addressed all notes that Jakub provided. Thanks, Martin [-- Attachment #2: 0001-Support-simd-function-declarations-via-a-pre-include.patch --] [-- Type: text/x-patch, Size: 14097 bytes --] From 958b29507153e923e08f79e754ed3e2e95bbec91 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Wed, 7 Nov 2018 12:41:19 +0100 Subject: [PATCH] Support simd function declarations via a pre-include. gcc/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * config/gnu-user.h (TARGET_F951_OPTIONS): New. * gcc.c (find_fortran_preinclude_file): New function to handle Fortran pre-include. gcc/fortran/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): New function. * gfortran.h (struct vect_builtin_tuple): New. (gfc_adjust_builtins): Likewise. * lang-specs.h (TARGET_F951_OPTIONS): New. (F951_OPTIONS): Use it. * lang.opt: Add new option -fpre-include. * match.h (gfc_match_gcc_builtin): Declare new function. * parse.c (decode_gcc_attribute): Handle builtin. (parse_progunit): Call gfc_adjust_builtins. * scanner.c (gfc_new_file): Load pre-included header file when provided. * trans-intrinsic.c (add_simd_flag_for_built_in): New. (gfc_adjust_builtins): Likewise. gcc/testsuite/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-1.f90: New test. * gfortran.dg/simd-builtins-1.h: New test. * gfortran.dg/simd-builtins-2.f90: New test. --- gcc/config/gnu-user.h | 4 ++ gcc/fortran/decl.c | 33 ++++++++++++ gcc/fortran/gfortran.h | 13 +++++ gcc/fortran/lang-specs.h | 10 +++- gcc/fortran/lang.opt | 4 ++ gcc/fortran/match.h | 1 + gcc/fortran/parse.c | 3 ++ gcc/fortran/scanner.c | 4 ++ gcc/fortran/trans-intrinsic.c | 54 +++++++++++++++++++ gcc/gcc.c | 19 +++++++ gcc/testsuite/gfortran.dg/simd-builtins-1.f90 | 19 +++++++ gcc/testsuite/gfortran.dg/simd-builtins-1.h | 4 ++ gcc/testsuite/gfortran.dg/simd-builtins-2.f90 | 20 +++++++ 13 files changed, 186 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-1.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-1.h create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-2.f90 diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index 5b48fb21514..d0acfed5116 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -170,3 +170,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" #endif + +#undef TARGET_F951_OPTIONS +#define TARGET_F951_OPTIONS "%{!nostdinc:\ + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 2b77d950abb..caac9d65b9f 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -98,6 +98,9 @@ bool gfc_matching_function; /* Set upon parsing a !GCC$ unroll n directive for use in the next loop. */ int directive_unroll = -1; +/* List middle-end built-ins that should be vectorized. */ +vec<vect_builtin_tuple> vectorized_builtins; + /* If a kind expression of a component of a parameterized derived type is parameterized, temporarily store the expression here. */ static gfc_expr *saved_kind_expr = NULL; @@ -11243,3 +11246,33 @@ gfc_match_gcc_unroll (void) gfc_error ("Syntax error in !GCC$ UNROLL directive at %C"); return MATCH_ERROR; } + +/* Match a !GCC$ builtin (b) attributes simd flags form: + + The parameter b is name of a middle-end built-in. + Flags are one of: + - (empty) + - inbranch + - notinbranch + + When we come here, we have already matched the !GCC$ builtin string. */ +match +gfc_match_gcc_builtin (void) +{ + char builtin[GFC_MAX_SYMBOL_LEN + 1]; + + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES) + return MATCH_ERROR; + + int builtin_kind = 0; + if (gfc_match (" (notinbranch)") == MATCH_YES) + builtin_kind = -1; + else if (gfc_match (" (inbranch)") == MATCH_YES) + builtin_kind = 1; + + char *r = XNEWVEC (char, strlen (builtin) + 32); + sprintf (r, "__builtin_%s", builtin); + vectorized_builtins.safe_push (vect_builtin_tuple (r, builtin_kind)); + + return MATCH_YES; +} diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index d8ef35d9d6c..093bb6d1a64 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -2764,6 +2764,18 @@ bool gfc_in_match_data (void); match gfc_match_char_spec (gfc_typespec *); extern int directive_unroll; +/* Tuple for parsing of vectorized built-ins. */ +struct vect_builtin_tuple +{ + vect_builtin_tuple (const char *n, int t): name (n), simd_type (t) + {} + + const char *name; + int simd_type; +}; + +extern vec<vect_builtin_tuple> vectorized_builtins; + /* Handling Parameterized Derived Types */ bool gfc_insert_kind_parameter_exprs (gfc_expr *); bool gfc_insert_parameter_exprs (gfc_expr *, gfc_actual_arglist *); @@ -3501,5 +3513,6 @@ bool gfc_is_reallocatable_lhs (gfc_expr *); /* trans-decl.c */ void finish_oacc_declare (gfc_namespace *, gfc_symbol *, bool); +void gfc_adjust_builtins (void); #endif /* GCC_GFORTRAN_H */ diff --git a/gcc/fortran/lang-specs.h b/gcc/fortran/lang-specs.h index c3ab9700ea7..61a9118d531 100644 --- a/gcc/fortran/lang-specs.h +++ b/gcc/fortran/lang-specs.h @@ -32,9 +32,15 @@ #define F951_CPP_OPTIONS "%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \ %{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \ " -fsyntax-only};: " CPP_FORWARD_OPTIONS "}" + +#ifndef TARGET_F951_OPTIONS +#define TARGET_F951_OPTIONS +#endif + #define F951_OPTIONS "%(cc1_options) %{J*} \ - %{!nostdinc:-fintrinsic-modules-path finclude%s}\ - %{!fsyntax-only:%(invoke_as)}" + %{!nostdinc:-fintrinsic-modules-path finclude%s}" \ + TARGET_F951_OPTIONS \ + "%{!fsyntax-only:%(invoke_as)}" #define F951_SOURCE_FORM "%{!ffree-form:-ffixed-form}" diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt index 2b7f2903761..c86b2623fac 100644 --- a/gcc/fortran/lang.opt +++ b/gcc/fortran/lang.opt @@ -662,6 +662,10 @@ fprotect-parens Fortran Var(flag_protect_parens) Init(-1) Protect parentheses in expressions. +fpre-include= +Fortran RejectNegative Joined Var(flag_pre_include) Undocumented +Path to header file that should be pre-included before each compilation unit. + frange-check Fortran Var(flag_range_check) Init(1) Enable range checking during compilation. diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h index 418542bd5a6..f25ed860c06 100644 --- a/gcc/fortran/match.h +++ b/gcc/fortran/match.h @@ -247,6 +247,7 @@ match gfc_match_dimension (void); match gfc_match_external (void); match gfc_match_gcc_attributes (void); match gfc_match_gcc_unroll (void); +match gfc_match_gcc_builtin (void); match gfc_match_import (void); match gfc_match_intent (void); match gfc_match_intrinsic (void); diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c index 13cc6f5fccd..56d0d050bc3 100644 --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -1072,6 +1072,7 @@ decode_gcc_attribute (void) match ("attributes", gfc_match_gcc_attributes, ST_ATTR_DECL); match ("unroll", gfc_match_gcc_unroll, ST_NONE); + match ("builtin", gfc_match_gcc_builtin, ST_NONE); /* All else has failed, so give up. See if any of the matchers has stored an error message of some sort. */ @@ -5663,6 +5664,8 @@ parse_progunit (gfc_statement st) gfc_state_data *p; int n; + gfc_adjust_builtins (); + if (gfc_new_block && gfc_new_block->abr_modproc_decl && gfc_new_block->attr.function) diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c index 55d6dafdb5d..4e500f88174 100644 --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -2428,6 +2428,10 @@ gfc_new_file (void) { bool result; + if (flag_pre_include != NULL + && !load_file (flag_pre_include, NULL, false)) + exit (FATAL_EXIT_CODE); + if (gfc_cpp_enabled ()) { result = gfc_cpp_preprocess (gfc_source_file); diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index 4ae2b3252b5..b307a7db1ed 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -597,7 +597,61 @@ define_quad_builtin (const char *name, tree type, bool is_const) return fndecl; } +/* Add SIMD attribute for FNDECL built-in if the built-in + name is in VECTORIZED_BUILTINS. */ +#include "print-tree.h" +static void +add_simd_flag_for_built_in (tree fndecl) +{ + if (fndecl == NULL_TREE) + return; + + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); + for (unsigned i = 0; i < vectorized_builtins.length (); i++) + if (strcmp (vectorized_builtins[i].name, name) == 0) + { + int simd_type = vectorized_builtins[i].simd_type; + tree omp_clause = NULL_TREE; + if (simd_type == 0) + ; /* No SIMD clause. */ + else + { + omp_clause_code code + = (simd_type == 1 ? OMP_CLAUSE_INBRANCH : OMP_CLAUSE_NOTINBRANCH); + omp_clause = build_omp_clause (UNKNOWN_LOCATION, code); + omp_clause = build_tree_list (NULL_TREE, omp_clause); + } + + DECL_ATTRIBUTES (fndecl) + = tree_cons (get_identifier ("omp declare simd"), omp_clause, + DECL_ATTRIBUTES (fndecl)); + } +} +/* Set SIMD attribute to all built-in functions that are mentioned + in vectorized_builtins vector. */ + +void +gfc_adjust_builtins (void) +{ + gfc_intrinsic_map_t *m; + for (m = gfc_intrinsic_map; + m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++) + { + add_simd_flag_for_built_in (m->real4_decl); + add_simd_flag_for_built_in (m->complex4_decl); + add_simd_flag_for_built_in (m->real8_decl); + add_simd_flag_for_built_in (m->complex8_decl); + add_simd_flag_for_built_in (m->real10_decl); + add_simd_flag_for_built_in (m->complex10_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + } + + vectorized_builtins.truncate (0); +} /* Initialize function decls for library functions. The external functions are created as required. Builtin functions are added here. */ diff --git a/gcc/gcc.c b/gcc/gcc.c index c0d17eb4f1b..911dc49cdd2 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -408,6 +408,7 @@ static const char *pass_through_libs_spec_func (int, const char **); static const char *replace_extension_spec_func (int, const char **); static const char *greater_than_spec_func (int, const char **); static const char *debug_level_greater_than_spec_func (int, const char **); +static const char *find_fortran_preinclude_file (int, const char **); static char *convert_white_space (char *); \f /* The Specs Language @@ -1647,6 +1648,7 @@ static const struct spec_function static_spec_functions[] = { "replace-extension", replace_extension_spec_func }, { "gt", greater_than_spec_func }, { "debug-level-gt", debug_level_greater_than_spec_func }, + { "fortran-preinclude-file", find_fortran_preinclude_file}, #ifdef EXTRA_SPEC_FUNCTIONS EXTRA_SPEC_FUNCTIONS #endif @@ -9889,6 +9891,23 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } +/* The function takes 2 arguments: OPTION name and file name. + When the FILE is found by find_file, return OPTION=path_to_file. */ + +static const char * +find_fortran_preinclude_file (int argc, const char **argv) +{ + if (argc != 2) + return NULL; + + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); + if (path != NULL) + return concat (argv[0], path, NULL); + + return NULL; +} + + /* Insert backslash before spaces in ORIG (usually a file path), to avoid being broken by spec parser. diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 new file mode 100644 index 00000000000..e52f8a2db1a --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target x86_64-*-linux* } } +! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.h b/gcc/testsuite/gfortran.dg/simd-builtins-1.h new file mode 100644 index 00000000000..c1b9f46b9ba --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h @@ -0,0 +1,4 @@ +!GCC$ builtin (sinf) attributes simd +!GCC$ builtin (sinf) attributes simd (inbranch) +!GCC$ builtin (sinf) attributes simd (notinbranch) +!GCC$ builtin (cosf) attributes simd (notinbranch) diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 new file mode 100644 index 00000000000..bca0ce4be94 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 @@ -0,0 +1,20 @@ +! { dg-do compile { target x86_64-*-linux* } } +! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "__builtin_sinf" "optimized" } } */ +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ +! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */ +! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } } -- 2.19.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-16 13:25 ` [PATCH] Support simd function declarations via a pre-include Martin Liška @ 2018-11-16 13:50 ` Jakub Jelinek 2018-11-16 15:12 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2018-11-16 13:50 UTC (permalink / raw) To: Martin Liška Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Fri, Nov 16, 2018 at 02:24:42PM +0100, Martin LiÅ¡ka wrote: > + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES) > + return MATCH_ERROR; > + > + int builtin_kind = 0; > + if (gfc_match (" (notinbranch)") == MATCH_YES) I think you need " ( notinbranch )" here. > + builtin_kind = -1; > + else if (gfc_match (" (inbranch)") == MATCH_YES) > + builtin_kind = 1; And similarly here (+ testsuite coverage for whether you can in free form insert spaces in all the spots that should be allowed). !gcc$ builtin ( sinf ) attributes simd ( notinbranch ) ! comment e.g. should be valid in free form (and fixed form too). > --- a/gcc/fortran/gfortran.h > +++ b/gcc/fortran/gfortran.h > @@ -2764,6 +2764,18 @@ bool gfc_in_match_data (void); > match gfc_match_char_spec (gfc_typespec *); > extern int directive_unroll; > > +/* Tuple for parsing of vectorized built-ins. */ > +struct vect_builtin_tuple > +{ > + vect_builtin_tuple (const char *n, int t): name (n), simd_type (t) gfc_vect_builtin_tuple ? + document what the simd_type is (or make it enum or whatever). One option would be enum omp_clause_code and use OMP_CLAUSE_ERROR for the case where the argument isn't specified, but I think generally gfortran.h doesn't depend on tree* stuff and wants to have its own enums etc. > +extern vec<vect_builtin_tuple> vectorized_builtins; gfc_vectorized_builtins ? > --- a/gcc/fortran/trans-intrinsic.c > +++ b/gcc/fortran/trans-intrinsic.c > @@ -597,7 +597,61 @@ define_quad_builtin (const char *name, tree type, bool is_const) > return fndecl; > } > > +/* Add SIMD attribute for FNDECL built-in if the built-in > + name is in VECTORIZED_BUILTINS. */ > +#include "print-tree.h" If you need to include a header, include it at the start of the file. > +static void > +add_simd_flag_for_built_in (tree fndecl) > +{ > + if (fndecl == NULL_TREE) > + return; > + > + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); > + for (unsigned i = 0; i < vectorized_builtins.length (); i++) > + if (strcmp (vectorized_builtins[i].name, name) == 0) How many add_simd_flag_for_built_in calls are we expecting and how many vectorized_builtins.length ()? If it is too much, perhaps e.g. sort the vector by name and do a binary search. At least if it turns out to be non-trivial compile time. > + > + vectorized_builtins.truncate (0); That is a memory leak, right? The names are malloced. And why truncate rather than release? > + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); > + if (path != NULL) > + return concat (argv[0], path, NULL); Formatting. > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h > @@ -0,0 +1,4 @@ > +!GCC$ builtin (sinf) attributes simd > +!GCC$ builtin (sinf) attributes simd (inbranch) > +!GCC$ builtin (sinf) attributes simd (notinbranch) > +!GCC$ builtin (cosf) attributes simd (notinbranch) Are you sure it is a good idea to have the 3 first lines for the same builtin, rather than different? It should be testsuite covered what we do in that case, but with the above you don't cover what happens e.g. with notinbranch alone, or no argument. Plus, as I said, I think you should have one *.f and one *.f90 test where you just use many of those !gcc$ builtin lines with spaces in various spots to verify it is parsed properly. Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-16 13:50 ` Jakub Jelinek @ 2018-11-16 15:12 ` Martin Liška 2018-11-17 13:30 ` Paul Richard Thomas ` (2 more replies) 0 siblings, 3 replies; 94+ messages in thread From: Martin Liška @ 2018-11-16 15:12 UTC (permalink / raw) To: Jakub Jelinek Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 3697 bytes --] On 11/16/18 2:49 PM, Jakub Jelinek wrote: > On Fri, Nov 16, 2018 at 02:24:42PM +0100, Martin LiÅ¡ka wrote: >> + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES) >> + return MATCH_ERROR; >> + >> + int builtin_kind = 0; >> + if (gfc_match (" (notinbranch)") == MATCH_YES) > > I think you need " ( notinbranch )" here. > >> + builtin_kind = -1; >> + else if (gfc_match (" (inbranch)") == MATCH_YES) >> + builtin_kind = 1; > > And similarly here (+ testsuite coverage for whether you can in free form > insert spaces in all the spots that should be allowed). > !gcc$ builtin ( sinf ) attributes simd ( notinbranch ) ! comment > e.g. should be valid in free form (and fixed form too). > >> --- a/gcc/fortran/gfortran.h >> +++ b/gcc/fortran/gfortran.h >> @@ -2764,6 +2764,18 @@ bool gfc_in_match_data (void); >> match gfc_match_char_spec (gfc_typespec *); >> extern int directive_unroll; >> >> +/* Tuple for parsing of vectorized built-ins. */ >> +struct vect_builtin_tuple >> +{ >> + vect_builtin_tuple (const char *n, int t): name (n), simd_type (t) > > gfc_vect_builtin_tuple ? > + document what the simd_type is (or make it enum or whatever). > One option would be enum omp_clause_code and use OMP_CLAUSE_ERROR for > the case where the argument isn't specified, but I think generally > gfortran.h doesn't depend on tree* stuff and wants to have its own > enums etc. > >> +extern vec<vect_builtin_tuple> vectorized_builtins; > > gfc_vectorized_builtins ? > >> --- a/gcc/fortran/trans-intrinsic.c >> +++ b/gcc/fortran/trans-intrinsic.c >> @@ -597,7 +597,61 @@ define_quad_builtin (const char *name, tree type, bool is_const) >> return fndecl; >> } >> >> +/* Add SIMD attribute for FNDECL built-in if the built-in >> + name is in VECTORIZED_BUILTINS. */ >> +#include "print-tree.h" > > If you need to include a header, include it at the start of the file. > >> +static void >> +add_simd_flag_for_built_in (tree fndecl) >> +{ >> + if (fndecl == NULL_TREE) >> + return; >> + >> + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); >> + for (unsigned i = 0; i < vectorized_builtins.length (); i++) >> + if (strcmp (vectorized_builtins[i].name, name) == 0) > > How many add_simd_flag_for_built_in calls are we expecting and how many > vectorized_builtins.length ()? If it is too much, perhaps e.g. sort > the vector by name and do a binary search. At least if it turns out to be > non-trivial compile time. >> + >> + vectorized_builtins.truncate (0); > > That is a memory leak, right? The names are malloced. > And why truncate rather than release? >> + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); >> + if (path != NULL) >> + return concat (argv[0], path, NULL); > > Formatting. >> --- /dev/null >> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h >> @@ -0,0 +1,4 @@ >> +!GCC$ builtin (sinf) attributes simd >> +!GCC$ builtin (sinf) attributes simd (inbranch) >> +!GCC$ builtin (sinf) attributes simd (notinbranch) >> +!GCC$ builtin (cosf) attributes simd (notinbranch) > > Are you sure it is a good idea to have the 3 first lines for the same > builtin, rather than different? > > It should be testsuite covered what we do in that case, but with the above > you don't cover what happens e.g. with notinbranch alone, or no argument. > > Plus, as I said, I think you should have one *.f and one *.f90 test where > you just use many of those !gcc$ builtin lines with spaces in various spots > to verify it is parsed properly. > > Jakub > Hi. I'm sending version, I changed the container to hash_map that should provide faster look up. I've been testing the patch right now. Martin [-- Attachment #2: 0001-Support-simd-function-declarations-via-a-pre-include.patch --] [-- Type: text/x-patch, Size: 17692 bytes --] From bb6061254e8071b0d208c5a2025aeed968dcdefb Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Wed, 7 Nov 2018 12:41:19 +0100 Subject: [PATCH] Support simd function declarations via a pre-include. gcc/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * config/gnu-user.h (TARGET_F951_OPTIONS): New. * gcc.c (find_fortran_preinclude_file): New function to handle Fortran pre-include. gcc/fortran/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): New function. * gfortran.h (struct vect_builtin_tuple): New. (gfc_adjust_builtins): Likewise. * lang-specs.h (TARGET_F951_OPTIONS): New. (F951_OPTIONS): Use it. * lang.opt: Add new option -fpre-include. * match.h (gfc_match_gcc_builtin): Declare new function. * parse.c (decode_gcc_attribute): Handle builtin. (parse_progunit): Call gfc_adjust_builtins. * scanner.c (gfc_new_file): Load pre-included header file when provided. * trans-intrinsic.c (add_simd_flag_for_built_in): New. (gfc_adjust_builtins): Likewise. gcc/testsuite/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-1.f90: New test. * gfortran.dg/simd-builtins-1.h: New test. * gfortran.dg/simd-builtins-2.f90: New test. * gfortran.dg/simd-builtins-3.f90: New test. * gfortran.dg/simd-builtins-3.h: New test. * gfortran.dg/simd-builtins-4.f: New test. * gfortran.dg/simd-builtins-4.h: New test. --- gcc/config/gnu-user.h | 4 ++ gcc/fortran/decl.c | 41 +++++++++++ gcc/fortran/gfortran.h | 22 ++++++ gcc/fortran/lang-specs.h | 10 ++- gcc/fortran/lang.opt | 4 ++ gcc/fortran/match.h | 1 + gcc/fortran/parse.c | 3 + gcc/fortran/scanner.c | 4 ++ gcc/fortran/trans-intrinsic.c | 70 +++++++++++++++++++ gcc/gcc.c | 19 +++++ gcc/testsuite/gfortran.dg/simd-builtins-1.f90 | 19 +++++ gcc/testsuite/gfortran.dg/simd-builtins-1.h | 4 ++ gcc/testsuite/gfortran.dg/simd-builtins-2.f90 | 20 ++++++ gcc/testsuite/gfortran.dg/simd-builtins-3.f90 | 1 + gcc/testsuite/gfortran.dg/simd-builtins-3.h | 8 +++ gcc/testsuite/gfortran.dg/simd-builtins-4.f | 1 + gcc/testsuite/gfortran.dg/simd-builtins-4.h | 8 +++ 17 files changed, 237 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-1.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-1.h create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-2.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-3.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-3.h create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-4.f create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-4.h diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index 5b48fb21514..d0acfed5116 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -170,3 +170,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" #endif + +#undef TARGET_F951_OPTIONS +#define TARGET_F951_OPTIONS "%{!nostdinc:\ + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 2b77d950abb..ac8679886af 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -98,6 +98,9 @@ bool gfc_matching_function; /* Set upon parsing a !GCC$ unroll n directive for use in the next loop. */ int directive_unroll = -1; +/* Map of middle-end built-ins that should be vectorized. */ +hash_map<nofree_string_hash, int> *gfc_vectorized_builtins; + /* If a kind expression of a component of a parameterized derived type is parameterized, temporarily store the expression here. */ static gfc_expr *saved_kind_expr = NULL; @@ -11243,3 +11246,41 @@ gfc_match_gcc_unroll (void) gfc_error ("Syntax error in !GCC$ UNROLL directive at %C"); return MATCH_ERROR; } + +/* Match a !GCC$ builtin (b) attributes simd flags form: + + The parameter b is name of a middle-end built-in. + Flags are one of: + - (empty) + - inbranch + - notinbranch + + When we come here, we have already matched the !GCC$ builtin string. */ +match +gfc_match_gcc_builtin (void) +{ + char builtin[GFC_MAX_SYMBOL_LEN + 1]; + + if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES) + return MATCH_ERROR; + + gfc_simd_clause clause = SIMD_NONE; + if (gfc_match (" ( notinbranch ) ") == MATCH_YES) + clause = SIMD_NOTINBRANCH; + else if (gfc_match (" ( inbranch ) ") == MATCH_YES) + clause = SIMD_INBRANCH; + + if (gfc_vectorized_builtins == NULL) + gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); + + char *r = XNEWVEC (char, strlen (builtin) + 32); + sprintf (r, "__builtin_%s", builtin); + + bool existed; + int &value = gfc_vectorized_builtins->get_or_insert (r, &existed); + value |= clause; + if (existed) + free (r); + + return MATCH_YES; +} diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index d8ef35d9d6c..9248685a271 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -2764,6 +2764,27 @@ bool gfc_in_match_data (void); match gfc_match_char_spec (gfc_typespec *); extern int directive_unroll; +/* SIMD clause enum. */ +enum gfc_simd_clause +{ + SIMD_NONE = (1 << 0), + SIMD_INBRANCH = (1 << 1), + SIMD_NOTINBRANCH = (1 << 2) +}; + +/* Tuple for parsing of vectorized built-ins. */ +struct gfc_vect_builtin_tuple +{ + gfc_vect_builtin_tuple (const char *n, gfc_simd_clause t) + : name (n), simd_type (t) {} + + const char *name; + gfc_simd_clause simd_type; +}; + +/* Map of middle-end built-ins that should be vectorized. */ +extern hash_map<nofree_string_hash, int> *gfc_vectorized_builtins; + /* Handling Parameterized Derived Types */ bool gfc_insert_kind_parameter_exprs (gfc_expr *); bool gfc_insert_parameter_exprs (gfc_expr *, gfc_actual_arglist *); @@ -3501,5 +3522,6 @@ bool gfc_is_reallocatable_lhs (gfc_expr *); /* trans-decl.c */ void finish_oacc_declare (gfc_namespace *, gfc_symbol *, bool); +void gfc_adjust_builtins (void); #endif /* GCC_GFORTRAN_H */ diff --git a/gcc/fortran/lang-specs.h b/gcc/fortran/lang-specs.h index c3ab9700ea7..61a9118d531 100644 --- a/gcc/fortran/lang-specs.h +++ b/gcc/fortran/lang-specs.h @@ -32,9 +32,15 @@ #define F951_CPP_OPTIONS "%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \ %{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \ " -fsyntax-only};: " CPP_FORWARD_OPTIONS "}" + +#ifndef TARGET_F951_OPTIONS +#define TARGET_F951_OPTIONS +#endif + #define F951_OPTIONS "%(cc1_options) %{J*} \ - %{!nostdinc:-fintrinsic-modules-path finclude%s}\ - %{!fsyntax-only:%(invoke_as)}" + %{!nostdinc:-fintrinsic-modules-path finclude%s}" \ + TARGET_F951_OPTIONS \ + "%{!fsyntax-only:%(invoke_as)}" #define F951_SOURCE_FORM "%{!ffree-form:-ffixed-form}" diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt index 2b7f2903761..c86b2623fac 100644 --- a/gcc/fortran/lang.opt +++ b/gcc/fortran/lang.opt @@ -662,6 +662,10 @@ fprotect-parens Fortran Var(flag_protect_parens) Init(-1) Protect parentheses in expressions. +fpre-include= +Fortran RejectNegative Joined Var(flag_pre_include) Undocumented +Path to header file that should be pre-included before each compilation unit. + frange-check Fortran Var(flag_range_check) Init(1) Enable range checking during compilation. diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h index 418542bd5a6..f25ed860c06 100644 --- a/gcc/fortran/match.h +++ b/gcc/fortran/match.h @@ -247,6 +247,7 @@ match gfc_match_dimension (void); match gfc_match_external (void); match gfc_match_gcc_attributes (void); match gfc_match_gcc_unroll (void); +match gfc_match_gcc_builtin (void); match gfc_match_import (void); match gfc_match_intent (void); match gfc_match_intrinsic (void); diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c index 13cc6f5fccd..56d0d050bc3 100644 --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -1072,6 +1072,7 @@ decode_gcc_attribute (void) match ("attributes", gfc_match_gcc_attributes, ST_ATTR_DECL); match ("unroll", gfc_match_gcc_unroll, ST_NONE); + match ("builtin", gfc_match_gcc_builtin, ST_NONE); /* All else has failed, so give up. See if any of the matchers has stored an error message of some sort. */ @@ -5663,6 +5664,8 @@ parse_progunit (gfc_statement st) gfc_state_data *p; int n; + gfc_adjust_builtins (); + if (gfc_new_block && gfc_new_block->abr_modproc_decl && gfc_new_block->attr.function) diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c index 55d6dafdb5d..4e500f88174 100644 --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -2428,6 +2428,10 @@ gfc_new_file (void) { bool result; + if (flag_pre_include != NULL + && !load_file (flag_pre_include, NULL, false)) + exit (FATAL_EXIT_CODE); + if (gfc_cpp_enabled ()) { result = gfc_cpp_preprocess (gfc_source_file); diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index 4ae2b3252b5..ffdf5c9fe32 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -597,7 +597,77 @@ define_quad_builtin (const char *name, tree type, bool is_const) return fndecl; } +/* Add SIMD attribute for FNDECL built-in if the built-in + name is in VECTORIZED_BUILTINS. */ +static void +add_simd_flag_for_built_in (tree fndecl) +{ + if (gfc_vectorized_builtins == NULL + || fndecl == NULL_TREE) + return; + + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); + for (hash_map<nofree_string_hash, int>::iterator it + = gfc_vectorized_builtins->begin (); + it != gfc_vectorized_builtins->end (); ++it) + for (unsigned i = 0; i < 3; i++) + if ((gfc_simd_clause)((*it).second) & (1 << i) + && strcmp ((*it).first, name) == 0) + { + gfc_simd_clause simd_type = (gfc_simd_clause)(*it).second; + tree omp_clause = NULL_TREE; + if (simd_type == SIMD_NONE) + ; /* No SIMD clause. */ + else + { + omp_clause_code code + = (simd_type == SIMD_INBRANCH + ? OMP_CLAUSE_INBRANCH : OMP_CLAUSE_NOTINBRANCH); + omp_clause = build_omp_clause (UNKNOWN_LOCATION, code); + omp_clause = build_tree_list (NULL_TREE, omp_clause); + } + + DECL_ATTRIBUTES (fndecl) + = tree_cons (get_identifier ("omp declare simd"), omp_clause, + DECL_ATTRIBUTES (fndecl)); + } +} + +/* Set SIMD attribute to all built-in functions that are mentioned + in gfc_vectorized_builtins vector. */ + +void +gfc_adjust_builtins (void) +{ + gfc_intrinsic_map_t *m; + for (m = gfc_intrinsic_map; + m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++) + { + add_simd_flag_for_built_in (m->real4_decl); + add_simd_flag_for_built_in (m->complex4_decl); + add_simd_flag_for_built_in (m->real8_decl); + add_simd_flag_for_built_in (m->complex8_decl); + add_simd_flag_for_built_in (m->real10_decl); + add_simd_flag_for_built_in (m->complex10_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + } + + /* Release all strings. */ + if (gfc_vectorized_builtins != NULL) + { + for (hash_map<nofree_string_hash, int>::iterator it + = gfc_vectorized_builtins->begin (); + it != gfc_vectorized_builtins->end (); ++it) + free (CONST_CAST (char *, (*it).first)); + + delete gfc_vectorized_builtins; + gfc_vectorized_builtins = NULL; + } +} /* Initialize function decls for library functions. The external functions are created as required. Builtin functions are added here. */ diff --git a/gcc/gcc.c b/gcc/gcc.c index c0d17eb4f1b..4d01e1e2f3b 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -408,6 +408,7 @@ static const char *pass_through_libs_spec_func (int, const char **); static const char *replace_extension_spec_func (int, const char **); static const char *greater_than_spec_func (int, const char **); static const char *debug_level_greater_than_spec_func (int, const char **); +static const char *find_fortran_preinclude_file (int, const char **); static char *convert_white_space (char *); \f /* The Specs Language @@ -1647,6 +1648,7 @@ static const struct spec_function static_spec_functions[] = { "replace-extension", replace_extension_spec_func }, { "gt", greater_than_spec_func }, { "debug-level-gt", debug_level_greater_than_spec_func }, + { "fortran-preinclude-file", find_fortran_preinclude_file}, #ifdef EXTRA_SPEC_FUNCTIONS EXTRA_SPEC_FUNCTIONS #endif @@ -9889,6 +9891,23 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } +/* The function takes 2 arguments: OPTION name and file name. + When the FILE is found by find_file, return OPTION=path_to_file. */ + +static const char * +find_fortran_preinclude_file (int argc, const char **argv) +{ + if (argc != 2) + return NULL; + + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); + if (path != NULL) + return concat (argv[0], path, NULL); + + return NULL; +} + + /* Insert backslash before spaces in ORIG (usually a file path), to avoid being broken by spec parser. diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 new file mode 100644 index 00000000000..e52f8a2db1a --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target x86_64-*-linux* } } +! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.h b/gcc/testsuite/gfortran.dg/simd-builtins-1.h new file mode 100644 index 00000000000..88d555cf41a --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h @@ -0,0 +1,4 @@ +!GCC$ builtin (sin) attributes simd (inbranch) +!GCC$ builtin (sinf) attributes simd (notinbranch) +!GCC$ builtin (cosf) attributes simd +!GCC$ builtin (cosf) attributes simd (notinbranch) diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 new file mode 100644 index 00000000000..bca0ce4be94 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 @@ -0,0 +1,20 @@ +! { dg-do compile { target x86_64-*-linux* } } +! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "__builtin_sinf" "optimized" } } */ +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ +! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */ +! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-3.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-3.f90 new file mode 100644 index 00000000000..949209bcf60 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-3.f90 @@ -0,0 +1 @@ +! { dg-additional-options "-nostdinc -fpre-include=simd-builtins-3.h" } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-3.h b/gcc/testsuite/gfortran.dg/simd-builtins-3.h new file mode 100644 index 00000000000..9707ef0a628 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-3.h @@ -0,0 +1,8 @@ +!GCC$ builtin (sin) attributes simd (inbranch) +!GCC$ builtin ( sin) attributes simd (inbranch) +!GCC$ builtin (sin ) attributes simd (inbranch) +!GCC$ builtin (sin) attributes simd ( inbranch) +!GCC$ builtin (sin) attributes simd (inbranch ) +!GCC$ builtin(sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-4.f b/gcc/testsuite/gfortran.dg/simd-builtins-4.f new file mode 100644 index 00000000000..48947b6f951 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-4.f @@ -0,0 +1 @@ +! { dg-additional-options "-nostdinc -fpre-include=simd-builtins-4.h" } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-4.h b/gcc/testsuite/gfortran.dg/simd-builtins-4.h new file mode 100644 index 00000000000..9707ef0a628 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-4.h @@ -0,0 +1,8 @@ +!GCC$ builtin (sin) attributes simd (inbranch) +!GCC$ builtin ( sin) attributes simd (inbranch) +!GCC$ builtin (sin ) attributes simd (inbranch) +!GCC$ builtin (sin) attributes simd ( inbranch) +!GCC$ builtin (sin) attributes simd (inbranch ) +!GCC$ builtin(sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd -- 2.19.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-16 15:12 ` Martin Liška @ 2018-11-17 13:30 ` Paul Richard Thomas 2018-11-17 17:57 ` Paul Richard Thomas 2018-11-17 18:16 ` Bernhard Reutner-Fischer 2018-11-19 12:16 ` Martin Liška 2 siblings, 1 reply; 94+ messages in thread From: Paul Richard Thomas @ 2018-11-17 13:30 UTC (permalink / raw) To: mliska Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Guenther, fortran, Thomas Koenig, Toon Moene, gcc-patches [-- Attachment #1: Type: text/plain, Size: 5349 bytes --] Hi All, I took a few moments away from what I really must be doing to try out an earlier version of the patch. There are quite a few CRs in the patch and the third chunk in gcc.c was rejected, although I cannot see why. I made a change to scanner.c to prevent the segfault that results from not having the pre-include file in the right directory - see attached. Everything works fine with the testcases and a slightly evolved version shows reasonable speed-ups: program test_overloaded_intrinsic real(4) :: x4(3200), y4(3200, 10000) real(8) :: x8(3200), y8(3200) do i = 1,10000 y4(:,i) = cos(x4) y4(:,i) = x4*y4(:,i) y4(:,i) = sqrt(y4(:,i)) end do print *, y4(1,1) end Disappointingly, though, one of the worst cases in https://www.fortran.uk/fortran-compiler-comparisons/ of a big difference between gfortran and ifort with vectorization, mp_prop_design.f90, doesn't seem to pick up any of the vectorization opportunities, even though it is peppered with trig functions. Should I be expecting this? Yes, I did add the other trig functions to the pre-include file :-) Best regards and thanks for taking care of this Paul On Fri, 16 Nov 2018 at 15:13, Martin Liška <mliska@suse.cz> wrote: > > On 11/16/18 2:49 PM, Jakub Jelinek wrote: > > On Fri, Nov 16, 2018 at 02:24:42PM +0100, Martin Liška wrote: > >> + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES) > >> + return MATCH_ERROR; > >> + > >> + int builtin_kind = 0; > >> + if (gfc_match (" (notinbranch)") == MATCH_YES) > > > > I think you need " ( notinbranch )" here. > > > >> + builtin_kind = -1; > >> + else if (gfc_match (" (inbranch)") == MATCH_YES) > >> + builtin_kind = 1; > > > > And similarly here (+ testsuite coverage for whether you can in free form > > insert spaces in all the spots that should be allowed). > > !gcc$ builtin ( sinf ) attributes simd ( notinbranch ) ! comment > > e.g. should be valid in free form (and fixed form too). > > > >> --- a/gcc/fortran/gfortran.h > >> +++ b/gcc/fortran/gfortran.h > >> @@ -2764,6 +2764,18 @@ bool gfc_in_match_data (void); > >> match gfc_match_char_spec (gfc_typespec *); > >> extern int directive_unroll; > >> > >> +/* Tuple for parsing of vectorized built-ins. */ > >> +struct vect_builtin_tuple > >> +{ > >> + vect_builtin_tuple (const char *n, int t): name (n), simd_type (t) > > > > gfc_vect_builtin_tuple ? > > + document what the simd_type is (or make it enum or whatever). > > One option would be enum omp_clause_code and use OMP_CLAUSE_ERROR for > > the case where the argument isn't specified, but I think generally > > gfortran.h doesn't depend on tree* stuff and wants to have its own > > enums etc. > > > >> +extern vec<vect_builtin_tuple> vectorized_builtins; > > > > gfc_vectorized_builtins ? > > > >> --- a/gcc/fortran/trans-intrinsic.c > >> +++ b/gcc/fortran/trans-intrinsic.c > >> @@ -597,7 +597,61 @@ define_quad_builtin (const char *name, tree type, bool is_const) > >> return fndecl; > >> } > >> > >> +/* Add SIMD attribute for FNDECL built-in if the built-in > >> + name is in VECTORIZED_BUILTINS. */ > >> +#include "print-tree.h" > > > > If you need to include a header, include it at the start of the file. > > > >> +static void > >> +add_simd_flag_for_built_in (tree fndecl) > >> +{ > >> + if (fndecl == NULL_TREE) > >> + return; > >> + > >> + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); > >> + for (unsigned i = 0; i < vectorized_builtins.length (); i++) > >> + if (strcmp (vectorized_builtins[i].name, name) == 0) > > > > How many add_simd_flag_for_built_in calls are we expecting and how many > > vectorized_builtins.length ()? If it is too much, perhaps e.g. sort > > the vector by name and do a binary search. At least if it turns out to be > > non-trivial compile time. > >> + > >> + vectorized_builtins.truncate (0); > > > > That is a memory leak, right? The names are malloced. > > And why truncate rather than release? > >> + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); > >> + if (path != NULL) > >> + return concat (argv[0], path, NULL); > > > > Formatting. > >> --- /dev/null > >> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h > >> @@ -0,0 +1,4 @@ > >> +!GCC$ builtin (sinf) attributes simd > >> +!GCC$ builtin (sinf) attributes simd (inbranch) > >> +!GCC$ builtin (sinf) attributes simd (notinbranch) > >> +!GCC$ builtin (cosf) attributes simd (notinbranch) > > > > Are you sure it is a good idea to have the 3 first lines for the same > > builtin, rather than different? > > > > It should be testsuite covered what we do in that case, but with the above > > you don't cover what happens e.g. with notinbranch alone, or no argument. > > > > Plus, as I said, I think you should have one *.f and one *.f90 test where > > you just use many of those !gcc$ builtin lines with spaces in various spots > > to verify it is parsed properly. > > > > Jakub > > > > Hi. > > I'm sending version, I changed the container to hash_map that should provide > faster look up. > > I've been testing the patch right now. > > Martin -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein [-- Attachment #2: simd2.diff --] [-- Type: text/x-patch, Size: 23217 bytes --] Index: gcc/config/gnu-user.h =================================================================== *** gcc/config/gnu-user.h (revision 266027) --- gcc/config/gnu-user.h (working copy) *************** see the files COPYING3 and COPYING.RUNTI *** 170,172 **** --- 170,176 ---- LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" #endif + + #undef TARGET_F951_OPTIONS + #define TARGET_F951_OPTIONS "%{!nostdinc:\ + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" Index: gcc/fortran/decl.c =================================================================== *** gcc/fortran/decl.c (revision 266027) --- gcc/fortran/decl.c (working copy) *************** bool gfc_matching_function; *** 98,103 **** --- 98,106 ---- /* Set upon parsing a !GCC$ unroll n directive for use in the next loop. */ int directive_unroll = -1; + /* List middle-end built-ins that should be vectorized. */ + vec<vect_builtin_tuple> vectorized_builtins; + /* If a kind expression of a component of a parameterized derived type is parameterized, temporarily store the expression here. */ static gfc_expr *saved_kind_expr = NULL; *************** gfc_match_gcc_unroll (void) *** 11243,11245 **** --- 11246,11278 ---- gfc_error ("Syntax error in !GCC$ UNROLL directive at %C"); return MATCH_ERROR; } + + /* Match a !GCC$ builtin (b) attributes simd flags form: + + The parameter b is name of a middle-end built-in. + Flags are one of: + - (empty) + - inbranch + - notinbranch + + When we come here, we have already matched the !GCC$ builtin string. */ + match + gfc_match_gcc_builtin (void) + { + char builtin[GFC_MAX_SYMBOL_LEN + 1]; + + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES) + return MATCH_ERROR; + + int builtin_kind = 0; + if (gfc_match (" (notinbranch)") == MATCH_YES) + builtin_kind = -1; + else if (gfc_match (" (inbranch)") == MATCH_YES) + builtin_kind = 1; + + char *r = XNEWVEC (char, strlen (builtin) + 32); + sprintf (r, "__builtin_%s", builtin); + vectorized_builtins.safe_push (vect_builtin_tuple (r, builtin_kind)); + + return MATCH_YES; + } Index: gcc/fortran/gfortran.h =================================================================== *** gcc/fortran/gfortran.h (revision 266027) --- gcc/fortran/gfortran.h (working copy) *************** bool gfc_in_match_data (void); *** 2764,2769 **** --- 2764,2781 ---- match gfc_match_char_spec (gfc_typespec *); extern int directive_unroll; + /* Tuple for parsing of vectorized built-ins. */ + struct vect_builtin_tuple + { + vect_builtin_tuple (const char *n, int t): name (n), simd_type (t) + {} + + const char *name; + int simd_type; + }; + + extern vec<vect_builtin_tuple> vectorized_builtins; + /* Handling Parameterized Derived Types */ bool gfc_insert_kind_parameter_exprs (gfc_expr *); bool gfc_insert_parameter_exprs (gfc_expr *, gfc_actual_arglist *); *************** bool gfc_is_reallocatable_lhs (gfc_expr *** 3501,3505 **** --- 3513,3518 ---- /* trans-decl.c */ void finish_oacc_declare (gfc_namespace *, gfc_symbol *, bool); + void gfc_adjust_builtins (void); #endif /* GCC_GFORTRAN_H */ Index: gcc/fortran/lang-specs.h =================================================================== *** gcc/fortran/lang-specs.h (revision 266027) --- gcc/fortran/lang-specs.h (working copy) *************** *** 32,40 **** #define F951_CPP_OPTIONS "%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \ %{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \ " -fsyntax-only};: " CPP_FORWARD_OPTIONS "}" #define F951_OPTIONS "%(cc1_options) %{J*} \ ! %{!nostdinc:-fintrinsic-modules-path finclude%s}\ ! %{!fsyntax-only:%(invoke_as)}" #define F951_SOURCE_FORM "%{!ffree-form:-ffixed-form}" --- 32,46 ---- #define F951_CPP_OPTIONS "%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \ %{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \ " -fsyntax-only};: " CPP_FORWARD_OPTIONS "}" + + #ifndef TARGET_F951_OPTIONS + #define TARGET_F951_OPTIONS + #endif + #define F951_OPTIONS "%(cc1_options) %{J*} \ ! %{!nostdinc:-fintrinsic-modules-path finclude%s}" \ ! TARGET_F951_OPTIONS \ ! "%{!fsyntax-only:%(invoke_as)}" #define F951_SOURCE_FORM "%{!ffree-form:-ffixed-form}" Index: gcc/fortran/lang.opt =================================================================== *** gcc/fortran/lang.opt (revision 266027) --- gcc/fortran/lang.opt (working copy) *************** fprotect-parens *** 662,667 **** --- 662,671 ---- Fortran Var(flag_protect_parens) Init(-1) Protect parentheses in expressions. + fpre-include= + Fortran RejectNegative Joined Var(flag_pre_include) Undocumented + Path to header file that should be pre-included before each compilation unit. + frange-check Fortran Var(flag_range_check) Init(1) Enable range checking during compilation. Index: gcc/fortran/match.h =================================================================== *** gcc/fortran/match.h (revision 266027) --- gcc/fortran/match.h (working copy) *************** match gfc_match_dimension (void); *** 247,252 **** --- 247,253 ---- match gfc_match_external (void); match gfc_match_gcc_attributes (void); match gfc_match_gcc_unroll (void); + match gfc_match_gcc_builtin (void); match gfc_match_import (void); match gfc_match_intent (void); match gfc_match_intrinsic (void); Index: gcc/fortran/parse.c =================================================================== *** gcc/fortran/parse.c (revision 266027) --- gcc/fortran/parse.c (working copy) *************** decode_gcc_attribute (void) *** 1072,1077 **** --- 1072,1078 ---- match ("attributes", gfc_match_gcc_attributes, ST_ATTR_DECL); match ("unroll", gfc_match_gcc_unroll, ST_NONE); + match ("builtin", gfc_match_gcc_builtin, ST_NONE); /* All else has failed, so give up. See if any of the matchers has stored an error message of some sort. */ *************** parse_progunit (gfc_statement st) *** 5663,5668 **** --- 5664,5671 ---- gfc_state_data *p; int n; + gfc_adjust_builtins (); + if (gfc_new_block && gfc_new_block->abr_modproc_decl && gfc_new_block->attr.function) Index: gcc/fortran/scanner.c =================================================================== *** gcc/fortran/scanner.c (revision 266027) --- gcc/fortran/scanner.c (working copy) *************** static locus gcc_attribute_locus; *** 65,71 **** gfc_source_form gfc_current_form; static gfc_linebuf *line_head, *line_tail; ! locus gfc_current_locus; const char *gfc_source_file; static FILE *gfc_src_file; --- 65,71 ---- gfc_source_form gfc_current_form; static gfc_linebuf *line_head, *line_tail; ! locus gfc_current_locus; const char *gfc_source_file; static FILE *gfc_src_file; *************** gfc_scanner_done_1 (void) *** 282,300 **** gfc_linebuf *lb; gfc_file *f; ! while(line_head != NULL) { lb = line_head->next; free (line_head); line_head = lb; } ! ! while(file_head != NULL) { f = file_head->next; free (file_head->filename); free (file_head); ! file_head = f; } } --- 282,300 ---- gfc_linebuf *lb; gfc_file *f; ! while(line_head != NULL) { lb = line_head->next; free (line_head); line_head = lb; } ! ! while(file_head != NULL) { f = file_head->next; free (file_head->filename); free (file_head); ! file_head = f; } } *************** add_path_to_list (gfc_directorylist **li *** 311,317 **** struct stat st; size_t len; int i; ! p = path; while (*p == ' ' || *p == '\t') /* someone might do "-I include" */ if (*p++ == '\0') --- 311,317 ---- struct stat st; size_t len; int i; ! p = path; while (*p == ' ' || *p == '\t') /* someone might do "-I include" */ if (*p++ == '\0') *************** gfc_advance_line (void) *** 581,591 **** if (gfc_at_end ()) return; ! if (gfc_current_locus.lb == NULL) { end_flag = 1; return; ! } if (gfc_current_locus.lb->next && !gfc_current_locus.lb->next->dbg_emitted) --- 581,591 ---- if (gfc_at_end ()) return; ! if (gfc_current_locus.lb == NULL) { end_flag = 1; return; ! } if (gfc_current_locus.lb->next && !gfc_current_locus.lb->next->dbg_emitted) *************** gfc_advance_line (void) *** 596,608 **** gfc_current_locus.lb = gfc_current_locus.lb->next; ! if (gfc_current_locus.lb != NULL) gfc_current_locus.nextc = gfc_current_locus.lb->line; ! else { gfc_current_locus.nextc = NULL; end_flag = 1; ! } } --- 596,608 ---- gfc_current_locus.lb = gfc_current_locus.lb->next; ! if (gfc_current_locus.lb != NULL) gfc_current_locus.nextc = gfc_current_locus.lb->line; ! else { gfc_current_locus.nextc = NULL; end_flag = 1; ! } } *************** static gfc_char_t *** 619,625 **** next_char (void) { gfc_char_t c; ! if (gfc_current_locus.nextc == NULL) return '\n'; --- 619,625 ---- next_char (void) { gfc_char_t c; ! if (gfc_current_locus.nextc == NULL) return '\n'; *************** skip_free_oacc_sentinel (locus start, lo *** 736,742 **** openacc_locus = old_loc; gfc_current_locus = start; } ! else r = false; } else --- 736,742 ---- openacc_locus = old_loc; gfc_current_locus = start; } ! else r = false; } else *************** skip_free_omp_sentinel (locus start, loc *** 776,782 **** openmp_locus = old_loc; gfc_current_locus = start; } ! else r = false; } else --- 776,782 ---- openmp_locus = old_loc; gfc_current_locus = start; } ! else r = false; } else *************** skip_fixed_comments (void) *** 1051,1057 **** } /* If -fopenmp/-fopenacc, we need to handle here 2 things: ! 1) don't treat !$omp/!$acc|c$omp/c$acc|*$omp / *$acc as comments, but directives 2) handle OpenMP/OpenACC conditional compilation, where !$|c$|*$ should be treated as 2 spaces if the characters --- 1051,1057 ---- } /* If -fopenmp/-fopenacc, we need to handle here 2 things: ! 1) don't treat !$omp/!$acc|c$omp/c$acc|*$omp / *$acc as comments, but directives 2) handle OpenMP/OpenACC conditional compilation, where !$|c$|*$ should be treated as 2 spaces if the characters *************** restart: *** 1318,1324 **** skip_comment_line (); else gfc_advance_line (); ! if (gfc_at_eof ()) goto not_continuation; --- 1318,1324 ---- skip_comment_line (); else gfc_advance_line (); ! if (gfc_at_eof ()) goto not_continuation; *************** restart: *** 1421,1427 **** { gfc_current_locus.nextc--; if (warn_ampersand && in_string == INSTRING_WARN) ! gfc_warning (OPT_Wampersand, "Missing %<&%> in continued character " "constant at %C"); } --- 1421,1427 ---- { gfc_current_locus.nextc--; if (warn_ampersand && in_string == INSTRING_WARN) ! gfc_warning (OPT_Wampersand, "Missing %<&%> in continued character " "constant at %C"); } *************** gfc_gobble_whitespace (void) *** 1732,1738 **** load_line returns whether the line was truncated. NOTE: The error machinery isn't available at this point, so we can't ! easily report line and column numbers consistent with other parts of gfortran. */ static int --- 1732,1738 ---- load_line returns whether the line was truncated. NOTE: The error machinery isn't available at this point, so we can't ! easily report line and column numbers consistent with other parts of gfortran. */ static int *************** load_line (FILE *input, gfc_char_t **pbu *** 1788,1794 **** if (c == '\n') { /* Check for illegal use of ampersand. See F95 Standard 3.3.1.3. */ ! if (gfc_current_form == FORM_FREE && !seen_printable && seen_ampersand) { if (pedantic) --- 1788,1794 ---- if (c == '\n') { /* Check for illegal use of ampersand. See F95 Standard 3.3.1.3. */ ! if (gfc_current_form == FORM_FREE && !seen_printable && seen_ampersand) { if (pedantic) *************** include_line (gfc_char_t *line) *** 2174,2180 **** c++; /* Find filename between quotes. */ ! quote = *c++; if (quote != '"' && quote != '\'') return false; --- 2174,2180 ---- c++; /* Find filename between quotes. */ ! quote = *c++; if (quote != '"' && quote != '\'') return false; *************** include_line (gfc_char_t *line) *** 2188,2194 **** return false; stop = c++; ! while (*c == ' ' || *c == '\t') c++; --- 2188,2194 ---- return false; stop = c++; ! while (*c == ' ' || *c == '\t') c++; *************** load_file (const char *realfilename, con *** 2261,2268 **** input = gfc_open_included_file (realfilename, false, false); if (input == NULL) { ! fprintf (stderr, "%s:%d: Error: Can't open included file '%s'\n", ! current_file->filename, current_file->line, filename); return false; } stat_result = stat (realfilename, &st); --- 2261,2272 ---- input = gfc_open_included_file (realfilename, false, false); if (input == NULL) { ! if (current_file) ! fprintf (stderr, "%s:%d: Error: Can't open included file '%s'\n", ! current_file->filename, current_file->line, filename); ! else ! fprintf (stderr, "Error: Can't open pre-included file '%s'\n", ! filename); return false; } stat_result = stat (realfilename, &st); *************** gfc_new_file (void) *** 2428,2433 **** --- 2432,2441 ---- { bool result; + if (flag_pre_include != NULL + && !load_file (flag_pre_include, NULL, false)) + exit (FATAL_EXIT_CODE); + if (gfc_cpp_enabled ()) { result = gfc_cpp_preprocess (gfc_source_file); Index: gcc/fortran/trans-intrinsic.c =================================================================== *** gcc/fortran/trans-intrinsic.c (revision 266027) --- gcc/fortran/trans-intrinsic.c (working copy) *************** define_quad_builtin (const char *name, t *** 597,603 **** --- 597,657 ---- return fndecl; } + /* Add SIMD attribute for FNDECL built-in if the built-in + name is in VECTORIZED_BUILTINS. */ + #include "print-tree.h" + static void + add_simd_flag_for_built_in (tree fndecl) + { + if (fndecl == NULL_TREE) + return; + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); + for (unsigned i = 0; i < vectorized_builtins.length (); i++) + if (strcmp (vectorized_builtins[i].name, name) == 0) + { + int simd_type = vectorized_builtins[i].simd_type; + tree omp_clause = NULL_TREE; + if (simd_type == 0) + ; /* No SIMD clause. */ + else + { + omp_clause_code code + = (simd_type == 1 ? OMP_CLAUSE_INBRANCH : OMP_CLAUSE_NOTINBRANCH); + omp_clause = build_omp_clause (UNKNOWN_LOCATION, code); + omp_clause = build_tree_list (NULL_TREE, omp_clause); + } + + DECL_ATTRIBUTES (fndecl) + = tree_cons (get_identifier ("omp declare simd"), omp_clause, + DECL_ATTRIBUTES (fndecl)); + } + } + + /* Set SIMD attribute to all built-in functions that are mentioned + in vectorized_builtins vector. */ + + void + gfc_adjust_builtins (void) + { + gfc_intrinsic_map_t *m; + for (m = gfc_intrinsic_map; + m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++) + { + add_simd_flag_for_built_in (m->real4_decl); + add_simd_flag_for_built_in (m->complex4_decl); + add_simd_flag_for_built_in (m->real8_decl); + add_simd_flag_for_built_in (m->complex8_decl); + add_simd_flag_for_built_in (m->real10_decl); + add_simd_flag_for_built_in (m->complex10_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + } + + vectorized_builtins.truncate (0); + } /* Initialize function decls for library functions. The external functions are created as required. Builtin functions are added here. */ Index: gcc/gcc.c =================================================================== *** gcc/gcc.c (revision 266027) --- gcc/gcc.c (working copy) *************** static const char *pass_through_libs_spe *** 408,413 **** --- 408,414 ---- static const char *replace_extension_spec_func (int, const char **); static const char *greater_than_spec_func (int, const char **); static const char *debug_level_greater_than_spec_func (int, const char **); + static const char *find_fortran_preinclude_file (int, const char **); static char *convert_white_space (char *); \f /* The Specs Language *************** static const struct spec_function static *** 1647,1652 **** --- 1648,1654 ---- { "replace-extension", replace_extension_spec_func }, { "gt", greater_than_spec_func }, { "debug-level-gt", debug_level_greater_than_spec_func }, + { "fortran-preinclude-file", find_fortran_preinclude_file}, #ifdef EXTRA_SPEC_FUNCTIONS EXTRA_SPEC_FUNCTIONS #endif *************** do_spec_1 (const char *spec, int inswitc *** 5948,5954 **** "%{foo=*:bar%*}%{foo=*:one%*two}" matches -foo=hello then it will produce: ! barhello onehellotwo */ if (*p == 0 || *p == '}') --- 5950,5956 ---- "%{foo=*:bar%*}%{foo=*:one%*two}" matches -foo=hello then it will produce: ! barhello onehellotwo */ if (*p == 0 || *p == '}') *************** static unsigned HOST_WIDE_INT *** 9585,9593 **** get_random_number (void) { unsigned HOST_WIDE_INT ret = 0; ! int fd; ! fd = open ("/dev/urandom", O_RDONLY); if (fd >= 0) { read (fd, &ret, sizeof (HOST_WIDE_INT)); --- 9587,9595 ---- get_random_number (void) { unsigned HOST_WIDE_INT ret = 0; ! int fd; ! fd = open ("/dev/urandom", O_RDONLY); if (fd >= 0) { read (fd, &ret, sizeof (HOST_WIDE_INT)); *************** greater_than_spec_func (int argc, const *** 9868,9873 **** --- 9870,9892 ---- return NULL; } + /* The function takes 2 arguments: OPTION name and file name. + When the FILE is found by find_file, return OPTION=path_to_file. */ + + static const char * + find_fortran_preinclude_file (int argc, const char **argv) + { + if (argc != 2) + return NULL; + + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); + if (path != NULL) + return concat (argv[0], path, NULL); + + return NULL; + } + + /* Returns "" if debug_info_level is greater than ARGV[ARGC-1]. Otherwise, return NULL. */ *************** debug_level_greater_than_spec_func (int *** 9889,9904 **** return NULL; } ! /* Insert backslash before spaces in ORIG (usually a file path), to avoid being broken by spec parser. This function is needed as do_spec_1 treats white space (' ' and '\t') as the end of an argument. But in case of -plugin /usr/gcc install/xxx.so, the file name should be treated as a single argument rather than being ! broken into multiple. Solution is to insert '\\' before the space in a file name. ! ! This function converts and only converts all occurrence of ' ' to '\\' + ' ' and '\t' to '\\' + '\t'. For example: "a b" -> "a\\ b" "a b" -> "a\\ \\ b" --- 9908,9923 ---- return NULL; } ! /* Insert backslash before spaces in ORIG (usually a file path), to avoid being broken by spec parser. This function is needed as do_spec_1 treats white space (' ' and '\t') as the end of an argument. But in case of -plugin /usr/gcc install/xxx.so, the file name should be treated as a single argument rather than being ! broken into multiple. Solution is to insert '\\' before the space in a file name. ! ! This function converts and only converts all occurrence of ' ' to '\\' + ' ' and '\t' to '\\' + '\t'. For example: "a b" -> "a\\ b" "a b" -> "a\\ \\ b" Index: gcc/testsuite/gfortran.dg/simd-builtins-1.f90 =================================================================== *** gcc/testsuite/gfortran.dg/simd-builtins-1.f90 (nonexistent) --- gcc/testsuite/gfortran.dg/simd-builtins-1.f90 (working copy) *************** *** 0 **** --- 1,19 ---- + ! { dg-do compile { target x86_64-*-linux* } } + ! { dg-additional-options "-nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } + + program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 + end + + ! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ + ! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ + ! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } Index: gcc/testsuite/gfortran.dg/simd-builtins-1.h =================================================================== *** gcc/testsuite/gfortran.dg/simd-builtins-1.h (nonexistent) --- gcc/testsuite/gfortran.dg/simd-builtins-1.h (working copy) *************** *** 0 **** --- 1,4 ---- + !GCC$ builtin (sinf) attributes simd + !GCC$ builtin (sinf) attributes simd (inbranch) + !GCC$ builtin (sinf) attributes simd (notinbranch) + !GCC$ builtin (cosf) attributes simd (notinbranch) Index: gcc/testsuite/gfortran.dg/simd-builtins-2.f90 =================================================================== *** gcc/testsuite/gfortran.dg/simd-builtins-2.f90 (nonexistent) --- gcc/testsuite/gfortran.dg/simd-builtins-2.f90 (working copy) *************** *** 0 **** --- 1,20 ---- + ! { dg-do compile { target x86_64-*-linux* } } + ! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" } + + program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 + end + + ! { dg-final { scan-tree-dump "__builtin_sinf" "optimized" } } */ + ! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ + ! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */ + ! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } } ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-17 13:30 ` Paul Richard Thomas @ 2018-11-17 17:57 ` Paul Richard Thomas 0 siblings, 0 replies; 94+ messages in thread From: Paul Richard Thomas @ 2018-11-17 17:57 UTC (permalink / raw) To: mliska Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Guenther, fortran, Thomas Koenig, Toon Moene, gcc-patches Hi All, Forget my remark about mp_prop_design.f90. ifort -parallel means just that and has nothing to do with vectorization. Sorry for the noise. Paul On Sat, 17 Nov 2018 at 13:29, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote: > > Hi All, > > I took a few moments away from what I really must be doing to try out > an earlier version of the patch. There are quite a few CRs in the > patch and the third chunk in gcc.c was rejected, although I cannot see > why. I made a change to scanner.c to prevent the segfault that results > from not having the pre-include file in the right directory - see > attached. > > Everything works fine with the testcases and a slightly evolved > version shows reasonable speed-ups: > program test_overloaded_intrinsic > real(4) :: x4(3200), y4(3200, 10000) > real(8) :: x8(3200), y8(3200) > > do i = 1,10000 > y4(:,i) = cos(x4) > y4(:,i) = x4*y4(:,i) > y4(:,i) = sqrt(y4(:,i)) > end do > print *, y4(1,1) > end > > Disappointingly, though, one of the worst cases in > https://www.fortran.uk/fortran-compiler-comparisons/ of a big > difference between gfortran and ifort with vectorization, > mp_prop_design.f90, doesn't seem to pick up any of the vectorization > opportunities, even though it is peppered with trig functions. Should > I be expecting this? Yes, I did add the other trig functions to the > pre-include file :-) > > Best regards and thanks for taking care of this > > Paul > On Fri, 16 Nov 2018 at 15:13, Martin Liška <mliska@suse.cz> wrote: > > > > On 11/16/18 2:49 PM, Jakub Jelinek wrote: > > > On Fri, Nov 16, 2018 at 02:24:42PM +0100, Martin Liška wrote: > > >> + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES) > > >> + return MATCH_ERROR; > > >> + > > >> + int builtin_kind = 0; > > >> + if (gfc_match (" (notinbranch)") == MATCH_YES) > > > > > > I think you need " ( notinbranch )" here. > > > > > >> + builtin_kind = -1; > > >> + else if (gfc_match (" (inbranch)") == MATCH_YES) > > >> + builtin_kind = 1; > > > > > > And similarly here (+ testsuite coverage for whether you can in free form > > > insert spaces in all the spots that should be allowed). > > > !gcc$ builtin ( sinf ) attributes simd ( notinbranch ) ! comment > > > e.g. should be valid in free form (and fixed form too). > > > > > >> --- a/gcc/fortran/gfortran.h > > >> +++ b/gcc/fortran/gfortran.h > > >> @@ -2764,6 +2764,18 @@ bool gfc_in_match_data (void); > > >> match gfc_match_char_spec (gfc_typespec *); > > >> extern int directive_unroll; > > >> > > >> +/* Tuple for parsing of vectorized built-ins. */ > > >> +struct vect_builtin_tuple > > >> +{ > > >> + vect_builtin_tuple (const char *n, int t): name (n), simd_type (t) > > > > > > gfc_vect_builtin_tuple ? > > > + document what the simd_type is (or make it enum or whatever). > > > One option would be enum omp_clause_code and use OMP_CLAUSE_ERROR for > > > the case where the argument isn't specified, but I think generally > > > gfortran.h doesn't depend on tree* stuff and wants to have its own > > > enums etc. > > > > > >> +extern vec<vect_builtin_tuple> vectorized_builtins; > > > > > > gfc_vectorized_builtins ? > > > > > >> --- a/gcc/fortran/trans-intrinsic.c > > >> +++ b/gcc/fortran/trans-intrinsic.c > > >> @@ -597,7 +597,61 @@ define_quad_builtin (const char *name, tree type, bool is_const) > > >> return fndecl; > > >> } > > >> > > >> +/* Add SIMD attribute for FNDECL built-in if the built-in > > >> + name is in VECTORIZED_BUILTINS. */ > > >> +#include "print-tree.h" > > > > > > If you need to include a header, include it at the start of the file. > > > > > >> +static void > > >> +add_simd_flag_for_built_in (tree fndecl) > > >> +{ > > >> + if (fndecl == NULL_TREE) > > >> + return; > > >> + > > >> + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); > > >> + for (unsigned i = 0; i < vectorized_builtins.length (); i++) > > >> + if (strcmp (vectorized_builtins[i].name, name) == 0) > > > > > > How many add_simd_flag_for_built_in calls are we expecting and how many > > > vectorized_builtins.length ()? If it is too much, perhaps e.g. sort > > > the vector by name and do a binary search. At least if it turns out to be > > > non-trivial compile time. > > >> + > > >> + vectorized_builtins.truncate (0); > > > > > > That is a memory leak, right? The names are malloced. > > > And why truncate rather than release? > > >> + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); > > >> + if (path != NULL) > > >> + return concat (argv[0], path, NULL); > > > > > > Formatting. > > >> --- /dev/null > > >> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h > > >> @@ -0,0 +1,4 @@ > > >> +!GCC$ builtin (sinf) attributes simd > > >> +!GCC$ builtin (sinf) attributes simd (inbranch) > > >> +!GCC$ builtin (sinf) attributes simd (notinbranch) > > >> +!GCC$ builtin (cosf) attributes simd (notinbranch) > > > > > > Are you sure it is a good idea to have the 3 first lines for the same > > > builtin, rather than different? > > > > > > It should be testsuite covered what we do in that case, but with the above > > > you don't cover what happens e.g. with notinbranch alone, or no argument. > > > > > > Plus, as I said, I think you should have one *.f and one *.f90 test where > > > you just use many of those !gcc$ builtin lines with spaces in various spots > > > to verify it is parsed properly. > > > > > > Jakub > > > > > > > Hi. > > > > I'm sending version, I changed the container to hash_map that should provide > > faster look up. > > > > I've been testing the patch right now. > > > > Martin > > > > -- > "If you can't explain it simply, you don't understand it well enough" > - Albert Einstein -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-16 15:12 ` Martin Liška 2018-11-17 13:30 ` Paul Richard Thomas @ 2018-11-17 18:16 ` Bernhard Reutner-Fischer 2018-11-19 12:14 ` Martin Liška 2018-11-19 12:16 ` Martin Liška 2 siblings, 1 reply; 94+ messages in thread From: Bernhard Reutner-Fischer @ 2018-11-17 18:16 UTC (permalink / raw) To: Martin Liška, Jakub Jelinek Cc: Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches Hi >I'm sending version, I changed the container to hash_map that should >provide >faster look up. > >I've been testing the patch right now. In find_fortran_preinclude_file() you allocate the filename. diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c index 55d6dafdb5d..4e500f88174 100644 --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -2428,6 +2428,10 @@ gfc_new_file (void) { bool result; + if (flag_pre_include != NULL + && !load_file (flag_pre_include, NULL, false)) + exit (FATAL_EXIT_CODE); + if (gfc_cpp_enabled ()) { result = gfc_cpp_preprocess (gfc_source_file); Don't you leak the filename here? I.e. else free() thanks, ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-17 18:16 ` Bernhard Reutner-Fischer @ 2018-11-19 12:14 ` Martin Liška 0 siblings, 0 replies; 94+ messages in thread From: Martin Liška @ 2018-11-19 12:14 UTC (permalink / raw) To: Bernhard Reutner-Fischer, Jakub Jelinek Cc: Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/17/18 7:16 PM, Bernhard Reutner-Fischer wrote: > Hi > >> I'm sending version, I changed the container to hash_map that should >> provide >> faster look up. >> >> I've been testing the patch right now. > > In find_fortran_preinclude_file() you allocate the filename. Sure, but that's driver allocation and apparently valgrind is not complaining about the memory allocation. > > diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c > index 55d6dafdb5d..4e500f88174 100644 > --- a/gcc/fortran/scanner.c > +++ b/gcc/fortran/scanner.c > @@ -2428,6 +2428,10 @@ gfc_new_file (void) > { > bool result; > > + if (flag_pre_include != NULL > + && !load_file (flag_pre_include, NULL, false)) > + exit (FATAL_EXIT_CODE); > + > if (gfc_cpp_enabled ()) > { > result = gfc_cpp_preprocess (gfc_source_file); > > > Don't you leak the filename here? This string is in FE, which lives in a option string pool. Martin > I.e. > else free() > > thanks, > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-16 15:12 ` Martin Liška 2018-11-17 13:30 ` Paul Richard Thomas 2018-11-17 18:16 ` Bernhard Reutner-Fischer @ 2018-11-19 12:16 ` Martin Liška 2018-11-19 12:33 ` Jakub Jelinek 2018-11-20 14:14 ` [PATCH][RFC] Extend locations where to seach for Fortran pre-include Martin Liška 2 siblings, 2 replies; 94+ messages in thread From: Martin Liška @ 2018-11-19 12:16 UTC (permalink / raw) To: Jakub Jelinek Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 3949 bytes --] On 11/16/18 4:12 PM, Martin LiÅ¡ka wrote: > On 11/16/18 2:49 PM, Jakub Jelinek wrote: >> On Fri, Nov 16, 2018 at 02:24:42PM +0100, Martin LiÅ¡ka wrote: >>> + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES) >>> + return MATCH_ERROR; >>> + >>> + int builtin_kind = 0; >>> + if (gfc_match (" (notinbranch)") == MATCH_YES) >> >> I think you need " ( notinbranch )" here. >> >>> + builtin_kind = -1; >>> + else if (gfc_match (" (inbranch)") == MATCH_YES) >>> + builtin_kind = 1; >> >> And similarly here (+ testsuite coverage for whether you can in free form >> insert spaces in all the spots that should be allowed). >> !gcc$ builtin ( sinf ) attributes simd ( notinbranch ) ! comment >> e.g. should be valid in free form (and fixed form too). >> >>> --- a/gcc/fortran/gfortran.h >>> +++ b/gcc/fortran/gfortran.h >>> @@ -2764,6 +2764,18 @@ bool gfc_in_match_data (void); >>> match gfc_match_char_spec (gfc_typespec *); >>> extern int directive_unroll; >>> >>> +/* Tuple for parsing of vectorized built-ins. */ >>> +struct vect_builtin_tuple >>> +{ >>> + vect_builtin_tuple (const char *n, int t): name (n), simd_type (t) >> >> gfc_vect_builtin_tuple ? >> + document what the simd_type is (or make it enum or whatever). >> One option would be enum omp_clause_code and use OMP_CLAUSE_ERROR for >> the case where the argument isn't specified, but I think generally >> gfortran.h doesn't depend on tree* stuff and wants to have its own >> enums etc. >> >>> +extern vec<vect_builtin_tuple> vectorized_builtins; >> >> gfc_vectorized_builtins ? >> >>> --- a/gcc/fortran/trans-intrinsic.c >>> +++ b/gcc/fortran/trans-intrinsic.c >>> @@ -597,7 +597,61 @@ define_quad_builtin (const char *name, tree type, bool is_const) >>> return fndecl; >>> } >>> >>> +/* Add SIMD attribute for FNDECL built-in if the built-in >>> + name is in VECTORIZED_BUILTINS. */ >>> +#include "print-tree.h" >> >> If you need to include a header, include it at the start of the file. >> >>> +static void >>> +add_simd_flag_for_built_in (tree fndecl) >>> +{ >>> + if (fndecl == NULL_TREE) >>> + return; >>> + >>> + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); >>> + for (unsigned i = 0; i < vectorized_builtins.length (); i++) >>> + if (strcmp (vectorized_builtins[i].name, name) == 0) >> >> How many add_simd_flag_for_built_in calls are we expecting and how many >> vectorized_builtins.length ()? If it is too much, perhaps e.g. sort >> the vector by name and do a binary search. At least if it turns out to be >> non-trivial compile time. >>> + >>> + vectorized_builtins.truncate (0); >> >> That is a memory leak, right? The names are malloced. >> And why truncate rather than release? >>> + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); >>> + if (path != NULL) >>> + return concat (argv[0], path, NULL); >> >> Formatting. >>> --- /dev/null >>> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h >>> @@ -0,0 +1,4 @@ >>> +!GCC$ builtin (sinf) attributes simd >>> +!GCC$ builtin (sinf) attributes simd (inbranch) >>> +!GCC$ builtin (sinf) attributes simd (notinbranch) >>> +!GCC$ builtin (cosf) attributes simd (notinbranch) >> >> Are you sure it is a good idea to have the 3 first lines for the same >> builtin, rather than different? >> >> It should be testsuite covered what we do in that case, but with the above >> you don't cover what happens e.g. with notinbranch alone, or no argument. >> >> Plus, as I said, I think you should have one *.f and one *.f90 test where >> you just use many of those !gcc$ builtin lines with spaces in various spots >> to verify it is parsed properly. >> >> Jakub >> > > Hi. > > I'm sending version, I changed the container to hash_map that should provide > faster look up. > > I've been testing the patch right now. > > Martin > Hi. I'm sending one another tested version on x86_64-linux-gnu. I fixed issues spotted by Jakub. Martin [-- Attachment #2: 0001-Support-simd-function-declarations-via-a-pre-include.patch --] [-- Type: text/x-patch, Size: 19479 bytes --] From 0d39d1dc7067849cec0fbd35382bb18f98ed29ba Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Wed, 7 Nov 2018 12:41:19 +0100 Subject: [PATCH] Support simd function declarations via a pre-include. gcc/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * config/gnu-user.h (TARGET_F951_OPTIONS): New. * gcc.c (find_fortran_preinclude_file): New function to handle Fortran pre-include. gcc/fortran/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): New function. * gfortran.h (struct vect_builtin_tuple): New. (gfc_adjust_builtins): Likewise. * lang-specs.h (TARGET_F951_OPTIONS): New. (F951_OPTIONS): Use it. * lang.opt: Add new option -fpre-include. * match.h (gfc_match_gcc_builtin): Declare new function. * parse.c (decode_gcc_attribute): Handle builtin. (parse_progunit): Call gfc_adjust_builtins. * scanner.c (gfc_new_file): Load pre-included header file when provided. * trans-intrinsic.c (add_simd_flag_for_built_in): New. (gfc_adjust_builtins): Likewise. gcc/testsuite/ChangeLog: 2018-11-15 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-1.f90: New test. * gfortran.dg/simd-builtins-1.h: New test. * gfortran.dg/simd-builtins-2.f90: New test. * gfortran.dg/simd-builtins-3.f90: New test. * gfortran.dg/simd-builtins-3.h: New test. * gfortran.dg/simd-builtins-4.f: New test. * gfortran.dg/simd-builtins-4.h: New test. * gfortran.dg/simd-builtins-5.f: New test. * gfortran.dg/simd-builtins-6.f90: New test. --- gcc/config/gnu-user.h | 4 ++ gcc/fortran/decl.c | 41 +++++++++++ gcc/fortran/gfortran.h | 22 ++++++ gcc/fortran/lang-specs.h | 10 ++- gcc/fortran/lang.opt | 4 ++ gcc/fortran/match.h | 1 + gcc/fortran/parse.c | 3 + gcc/fortran/scanner.c | 4 ++ gcc/fortran/trans-intrinsic.c | 70 +++++++++++++++++++ gcc/gcc.c | 19 +++++ gcc/testsuite/gfortran.dg/simd-builtins-1.f90 | 19 +++++ gcc/testsuite/gfortran.dg/simd-builtins-1.h | 4 ++ gcc/testsuite/gfortran.dg/simd-builtins-2.f90 | 20 ++++++ gcc/testsuite/gfortran.dg/simd-builtins-3.f90 | 1 + gcc/testsuite/gfortran.dg/simd-builtins-3.h | 8 +++ gcc/testsuite/gfortran.dg/simd-builtins-4.f | 1 + gcc/testsuite/gfortran.dg/simd-builtins-4.h | 8 +++ gcc/testsuite/gfortran.dg/simd-builtins-5.f | 9 +++ gcc/testsuite/gfortran.dg/simd-builtins-6.f90 | 24 +++++++ 19 files changed, 270 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-1.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-1.h create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-2.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-3.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-3.h create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-4.f create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-4.h create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-5.f create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-6.f90 diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index 5b48fb21514..d0acfed5116 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -170,3 +170,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see LD_STATIC_OPTION " --whole-archive -llsan --no-whole-archive " \ LD_DYNAMIC_OPTION "}}%{!static-liblsan:-llsan}" #endif + +#undef TARGET_F951_OPTIONS +#define TARGET_F951_OPTIONS "%{!nostdinc:\ + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 2b77d950abb..ac8679886af 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -98,6 +98,9 @@ bool gfc_matching_function; /* Set upon parsing a !GCC$ unroll n directive for use in the next loop. */ int directive_unroll = -1; +/* Map of middle-end built-ins that should be vectorized. */ +hash_map<nofree_string_hash, int> *gfc_vectorized_builtins; + /* If a kind expression of a component of a parameterized derived type is parameterized, temporarily store the expression here. */ static gfc_expr *saved_kind_expr = NULL; @@ -11243,3 +11246,41 @@ gfc_match_gcc_unroll (void) gfc_error ("Syntax error in !GCC$ UNROLL directive at %C"); return MATCH_ERROR; } + +/* Match a !GCC$ builtin (b) attributes simd flags form: + + The parameter b is name of a middle-end built-in. + Flags are one of: + - (empty) + - inbranch + - notinbranch + + When we come here, we have already matched the !GCC$ builtin string. */ +match +gfc_match_gcc_builtin (void) +{ + char builtin[GFC_MAX_SYMBOL_LEN + 1]; + + if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES) + return MATCH_ERROR; + + gfc_simd_clause clause = SIMD_NONE; + if (gfc_match (" ( notinbranch ) ") == MATCH_YES) + clause = SIMD_NOTINBRANCH; + else if (gfc_match (" ( inbranch ) ") == MATCH_YES) + clause = SIMD_INBRANCH; + + if (gfc_vectorized_builtins == NULL) + gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); + + char *r = XNEWVEC (char, strlen (builtin) + 32); + sprintf (r, "__builtin_%s", builtin); + + bool existed; + int &value = gfc_vectorized_builtins->get_or_insert (r, &existed); + value |= clause; + if (existed) + free (r); + + return MATCH_YES; +} diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index d8ef35d9d6c..9248685a271 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -2764,6 +2764,27 @@ bool gfc_in_match_data (void); match gfc_match_char_spec (gfc_typespec *); extern int directive_unroll; +/* SIMD clause enum. */ +enum gfc_simd_clause +{ + SIMD_NONE = (1 << 0), + SIMD_INBRANCH = (1 << 1), + SIMD_NOTINBRANCH = (1 << 2) +}; + +/* Tuple for parsing of vectorized built-ins. */ +struct gfc_vect_builtin_tuple +{ + gfc_vect_builtin_tuple (const char *n, gfc_simd_clause t) + : name (n), simd_type (t) {} + + const char *name; + gfc_simd_clause simd_type; +}; + +/* Map of middle-end built-ins that should be vectorized. */ +extern hash_map<nofree_string_hash, int> *gfc_vectorized_builtins; + /* Handling Parameterized Derived Types */ bool gfc_insert_kind_parameter_exprs (gfc_expr *); bool gfc_insert_parameter_exprs (gfc_expr *, gfc_actual_arglist *); @@ -3501,5 +3522,6 @@ bool gfc_is_reallocatable_lhs (gfc_expr *); /* trans-decl.c */ void finish_oacc_declare (gfc_namespace *, gfc_symbol *, bool); +void gfc_adjust_builtins (void); #endif /* GCC_GFORTRAN_H */ diff --git a/gcc/fortran/lang-specs.h b/gcc/fortran/lang-specs.h index c3ab9700ea7..61a9118d531 100644 --- a/gcc/fortran/lang-specs.h +++ b/gcc/fortran/lang-specs.h @@ -32,9 +32,15 @@ #define F951_CPP_OPTIONS "%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \ %{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \ " -fsyntax-only};: " CPP_FORWARD_OPTIONS "}" + +#ifndef TARGET_F951_OPTIONS +#define TARGET_F951_OPTIONS +#endif + #define F951_OPTIONS "%(cc1_options) %{J*} \ - %{!nostdinc:-fintrinsic-modules-path finclude%s}\ - %{!fsyntax-only:%(invoke_as)}" + %{!nostdinc:-fintrinsic-modules-path finclude%s}" \ + TARGET_F951_OPTIONS \ + "%{!fsyntax-only:%(invoke_as)}" #define F951_SOURCE_FORM "%{!ffree-form:-ffixed-form}" diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt index 2b7f2903761..c86b2623fac 100644 --- a/gcc/fortran/lang.opt +++ b/gcc/fortran/lang.opt @@ -662,6 +662,10 @@ fprotect-parens Fortran Var(flag_protect_parens) Init(-1) Protect parentheses in expressions. +fpre-include= +Fortran RejectNegative Joined Var(flag_pre_include) Undocumented +Path to header file that should be pre-included before each compilation unit. + frange-check Fortran Var(flag_range_check) Init(1) Enable range checking during compilation. diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h index 418542bd5a6..f25ed860c06 100644 --- a/gcc/fortran/match.h +++ b/gcc/fortran/match.h @@ -247,6 +247,7 @@ match gfc_match_dimension (void); match gfc_match_external (void); match gfc_match_gcc_attributes (void); match gfc_match_gcc_unroll (void); +match gfc_match_gcc_builtin (void); match gfc_match_import (void); match gfc_match_intent (void); match gfc_match_intrinsic (void); diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c index 13cc6f5fccd..56d0d050bc3 100644 --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -1072,6 +1072,7 @@ decode_gcc_attribute (void) match ("attributes", gfc_match_gcc_attributes, ST_ATTR_DECL); match ("unroll", gfc_match_gcc_unroll, ST_NONE); + match ("builtin", gfc_match_gcc_builtin, ST_NONE); /* All else has failed, so give up. See if any of the matchers has stored an error message of some sort. */ @@ -5663,6 +5664,8 @@ parse_progunit (gfc_statement st) gfc_state_data *p; int n; + gfc_adjust_builtins (); + if (gfc_new_block && gfc_new_block->abr_modproc_decl && gfc_new_block->attr.function) diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c index 55d6dafdb5d..4e500f88174 100644 --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -2428,6 +2428,10 @@ gfc_new_file (void) { bool result; + if (flag_pre_include != NULL + && !load_file (flag_pre_include, NULL, false)) + exit (FATAL_EXIT_CODE); + if (gfc_cpp_enabled ()) { result = gfc_cpp_preprocess (gfc_source_file); diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index 4ae2b3252b5..40a74916bb8 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -597,7 +597,77 @@ define_quad_builtin (const char *name, tree type, bool is_const) return fndecl; } +/* Add SIMD attribute for FNDECL built-in if the built-in + name is in VECTORIZED_BUILTINS. */ +static void +add_simd_flag_for_built_in (tree fndecl) +{ + if (gfc_vectorized_builtins == NULL + || fndecl == NULL_TREE) + return; + + const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl)); + int *clauses = gfc_vectorized_builtins->get (name); + if (clauses) + { + for (unsigned i = 0; i < 3; i++) + if (*clauses & (1 << i)) + { + gfc_simd_clause simd_type = (gfc_simd_clause)*clauses; + tree omp_clause = NULL_TREE; + if (simd_type == SIMD_NONE) + ; /* No SIMD clause. */ + else + { + omp_clause_code code + = (simd_type == SIMD_INBRANCH + ? OMP_CLAUSE_INBRANCH : OMP_CLAUSE_NOTINBRANCH); + omp_clause = build_omp_clause (UNKNOWN_LOCATION, code); + omp_clause = build_tree_list (NULL_TREE, omp_clause); + } + + DECL_ATTRIBUTES (fndecl) + = tree_cons (get_identifier ("omp declare simd"), omp_clause, + DECL_ATTRIBUTES (fndecl)); + } + } +} + + /* Set SIMD attribute to all built-in functions that are mentioned + in gfc_vectorized_builtins vector. */ + +void +gfc_adjust_builtins (void) +{ + gfc_intrinsic_map_t *m; + for (m = gfc_intrinsic_map; + m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++) + { + add_simd_flag_for_built_in (m->real4_decl); + add_simd_flag_for_built_in (m->complex4_decl); + add_simd_flag_for_built_in (m->real8_decl); + add_simd_flag_for_built_in (m->complex8_decl); + add_simd_flag_for_built_in (m->real10_decl); + add_simd_flag_for_built_in (m->complex10_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + add_simd_flag_for_built_in (m->real16_decl); + add_simd_flag_for_built_in (m->complex16_decl); + } + + /* Release all strings. */ + if (gfc_vectorized_builtins != NULL) + { + for (hash_map<nofree_string_hash, int>::iterator it + = gfc_vectorized_builtins->begin (); + it != gfc_vectorized_builtins->end (); ++it) + free (CONST_CAST (char *, (*it).first)); + + delete gfc_vectorized_builtins; + gfc_vectorized_builtins = NULL; + } +} /* Initialize function decls for library functions. The external functions are created as required. Builtin functions are added here. */ diff --git a/gcc/gcc.c b/gcc/gcc.c index c0d17eb4f1b..4d01e1e2f3b 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -408,6 +408,7 @@ static const char *pass_through_libs_spec_func (int, const char **); static const char *replace_extension_spec_func (int, const char **); static const char *greater_than_spec_func (int, const char **); static const char *debug_level_greater_than_spec_func (int, const char **); +static const char *find_fortran_preinclude_file (int, const char **); static char *convert_white_space (char *); \f /* The Specs Language @@ -1647,6 +1648,7 @@ static const struct spec_function static_spec_functions[] = { "replace-extension", replace_extension_spec_func }, { "gt", greater_than_spec_func }, { "debug-level-gt", debug_level_greater_than_spec_func }, + { "fortran-preinclude-file", find_fortran_preinclude_file}, #ifdef EXTRA_SPEC_FUNCTIONS EXTRA_SPEC_FUNCTIONS #endif @@ -9889,6 +9891,23 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } +/* The function takes 2 arguments: OPTION name and file name. + When the FILE is found by find_file, return OPTION=path_to_file. */ + +static const char * +find_fortran_preinclude_file (int argc, const char **argv) +{ + if (argc != 2) + return NULL; + + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); + if (path != NULL) + return concat (argv[0], path, NULL); + + return NULL; +} + + /* Insert backslash before spaces in ORIG (usually a file path), to avoid being broken by spec parser. diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 new file mode 100644 index 00000000000..e5ee380943f --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -nostdinc -Ofast -fpre-include=simd-builtins-1.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.h b/gcc/testsuite/gfortran.dg/simd-builtins-1.h new file mode 100644 index 00000000000..88d555cf41a --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h @@ -0,0 +1,4 @@ +!GCC$ builtin (sin) attributes simd (inbranch) +!GCC$ builtin (sinf) attributes simd (notinbranch) +!GCC$ builtin (cosf) attributes simd +!GCC$ builtin (cosf) attributes simd (notinbranch) diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 new file mode 100644 index 00000000000..f0e6bc13862 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-2.f90 @@ -0,0 +1,20 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -nostdinc -Ofast -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "__builtin_sinf" "optimized" } } */ +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ +! { dg-final { scan-tree-dump-not "simdclone" "optimized" } } */ +! { dg-final { scan-assembler-not "call.*_ZGVbN4v_sinf" } } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-3.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-3.f90 new file mode 100644 index 00000000000..949209bcf60 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-3.f90 @@ -0,0 +1 @@ +! { dg-additional-options "-nostdinc -fpre-include=simd-builtins-3.h" } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-3.h b/gcc/testsuite/gfortran.dg/simd-builtins-3.h new file mode 100644 index 00000000000..9707ef0a628 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-3.h @@ -0,0 +1,8 @@ +!GCC$ builtin (sin) attributes simd (inbranch) +!GCC$ builtin ( sin) attributes simd (inbranch) +!GCC$ builtin (sin ) attributes simd (inbranch) +!GCC$ builtin (sin) attributes simd ( inbranch) +!GCC$ builtin (sin) attributes simd (inbranch ) +!GCC$ builtin(sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-4.f b/gcc/testsuite/gfortran.dg/simd-builtins-4.f new file mode 100644 index 00000000000..48947b6f951 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-4.f @@ -0,0 +1 @@ +! { dg-additional-options "-nostdinc -fpre-include=simd-builtins-4.h" } diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-4.h b/gcc/testsuite/gfortran.dg/simd-builtins-4.h new file mode 100644 index 00000000000..9707ef0a628 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-4.h @@ -0,0 +1,8 @@ +!GCC$ builtin (sin) attributes simd (inbranch) +!GCC$ builtin ( sin) attributes simd (inbranch) +!GCC$ builtin (sin ) attributes simd (inbranch) +!GCC$ builtin (sin) attributes simd ( inbranch) +!GCC$ builtin (sin) attributes simd (inbranch ) +!GCC$ builtin(sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd ( inbranch ) +!GCC$ builtin ( sin ) attributes simd diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-5.f b/gcc/testsuite/gfortran.dg/simd-builtins-5.f new file mode 100644 index 00000000000..55330a8306d --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-5.f @@ -0,0 +1,9 @@ +! { dg-do compile } + +!GCC$ buil tin (s in) attributes simd (inbranch) +!GCC$ builtin (sinf) at tributes simd (notinbranch) +!GCC$ builtin (cosf) att r i bu tes s imd +!GCC$ buil ti n ( cosf) attrib utes simd (noti nbranch) + + PROGRAM Z + END diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 new file mode 100644 index 00000000000..5ff99212cf1 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 @@ -0,0 +1,24 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -nostdinc -Ofast -fdump-tree-optimized" } + +!GCC$ builtin (sin) attributes simd (inbranch) +!GCC$ builtin (sinf) attributes simd (notinbranch) +!GCC$ builtin (cosf) attributes simd +!GCC$ builtin (cosf) attributes simd (notinbranch) + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" } } */ +! { dg-final { scan-tree-dump "__builtin_sin" "optimized" } } */ +! { dg-final { scan-assembler "call.*_ZGVbN4v_sinf" } } -- 2.19.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. 2018-11-19 12:16 ` Martin Liška @ 2018-11-19 12:33 ` Jakub Jelinek 2018-11-20 14:14 ` [PATCH][RFC] Extend locations where to seach for Fortran pre-include Martin Liška 1 sibling, 0 replies; 94+ messages in thread From: Jakub Jelinek @ 2018-11-19 12:33 UTC (permalink / raw) To: Martin Liška Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Mon, Nov 19, 2018 at 01:15:43PM +0100, Martin LiÅ¡ka wrote: > 2018-11-15 Martin Liska <mliska@suse.cz> > > * config/gnu-user.h (TARGET_F951_OPTIONS): New. > * gcc.c (find_fortran_preinclude_file): New function > to handle Fortran pre-include. > > gcc/fortran/ChangeLog: > > 2018-11-15 Martin Liska <mliska@suse.cz> > > * decl.c (gfc_match_gcc_builtin): New function. > * gfortran.h (struct vect_builtin_tuple): New. > (gfc_adjust_builtins): Likewise. > * lang-specs.h (TARGET_F951_OPTIONS): New. > (F951_OPTIONS): Use it. > * lang.opt: Add new option -fpre-include. > * match.h (gfc_match_gcc_builtin): Declare new function. > * parse.c (decode_gcc_attribute): Handle builtin. > (parse_progunit): Call gfc_adjust_builtins. > * scanner.c (gfc_new_file): Load pre-included header file > when provided. > * trans-intrinsic.c (add_simd_flag_for_built_in): New. > (gfc_adjust_builtins): Likewise. > > gcc/testsuite/ChangeLog: > > 2018-11-15 Martin Liska <mliska@suse.cz> > > * gfortran.dg/simd-builtins-1.f90: New test. > * gfortran.dg/simd-builtins-1.h: New test. > * gfortran.dg/simd-builtins-2.f90: New test. > * gfortran.dg/simd-builtins-3.f90: New test. > * gfortran.dg/simd-builtins-3.h: New test. > * gfortran.dg/simd-builtins-4.f: New test. > * gfortran.dg/simd-builtins-4.h: New test. > * gfortran.dg/simd-builtins-5.f: New test. > * gfortran.dg/simd-builtins-6.f90: New test. LGTM. Please give Fortran maintainers 2 days so that they can comment on it before committing. Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-19 12:16 ` Martin Liška 2018-11-19 12:33 ` Jakub Jelinek @ 2018-11-20 14:14 ` Martin Liška 2018-11-20 14:27 ` Jakub Jelinek 1 sibling, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-20 14:14 UTC (permalink / raw) To: Jakub Jelinek Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 952 bytes --] Hi. Following patch is a follow up of the discussion we had on IRC about locations where a Fortran pre-include should be searched. With the patch applied I see now: $ strace -f -s512 ./xgcc -B. ~/Programming/testcases/usage.F90 -c 2>&1 | grep math-vector access("./x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("./math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/bin/../include/finclude/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/home/marxin/bin/gcc2/bin/../include/finclude/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/usr/include/finclude/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) access("/usr/include/finclude/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) Martin [-- Attachment #2: 0001-Extend-locations-where-to-seach-for-Fortran-pre-incl.patch --] [-- Type: text/x-patch, Size: 2314 bytes --] From c89d25005ae649d652d316cefe2aab8c676cd6ca Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Tue, 20 Nov 2018 15:09:16 +0100 Subject: [PATCH] Extend locations where to seach for Fortran pre-include. --- gcc/gcc.c | 49 +++++++++++++++++++++++++++++++------------------ 1 file changed, 31 insertions(+), 18 deletions(-) diff --git a/gcc/gcc.c b/gcc/gcc.c index 4d01e1e2f3b..bd6b83a3e6d 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -9891,20 +9891,49 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } +static void +path_prefix_reset (path_prefix *prefix) +{ + struct prefix_list *iter, *next; + iter = prefix->plist; + while (iter) + { + next = iter->next; + free (const_cast <char *> (iter->prefix)); + XDELETE (iter); + iter = next; + } + prefix->plist = 0; + prefix->max_len = 0; +} + /* The function takes 2 arguments: OPTION name and file name. When the FILE is found by find_file, return OPTION=path_to_file. */ static const char * find_fortran_preinclude_file (int argc, const char **argv) { + char *result = NULL; if (argc != 2) return NULL; + struct path_prefix prefixes = { 0, 0, "preinclude" }; + add_prefix (&prefixes, STANDARD_BINDIR_PREFIX "../include/finclude/", NULL, + 0, 0, 0); + add_prefix (&prefixes, "/usr/include/finclude/", NULL, 0, 0, 0); + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); if (path != NULL) - return concat (argv[0], path, NULL); + result = concat (argv[0], path, NULL); + else + { + path = find_a_file (&prefixes, argv[1], R_OK, true); + if (path != NULL) + result = concat (argv[0], path, NULL); + } - return NULL; + path_prefix_reset (&prefixes); + return result; } @@ -9956,22 +9985,6 @@ convert_white_space (char *orig) return orig; } -static void -path_prefix_reset (path_prefix *prefix) -{ - struct prefix_list *iter, *next; - iter = prefix->plist; - while (iter) - { - next = iter->next; - free (const_cast <char *> (iter->prefix)); - XDELETE (iter); - iter = next; - } - prefix->plist = 0; - prefix->max_len = 0; -} - /* Restore all state within gcc.c to the initial state, so that the driver code can be safely re-run in-process. -- 2.19.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-20 14:14 ` [PATCH][RFC] Extend locations where to seach for Fortran pre-include Martin Liška @ 2018-11-20 14:27 ` Jakub Jelinek 2018-11-20 18:11 ` Joseph Myers 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2018-11-20 14:27 UTC (permalink / raw) To: Martin Liška, Joseph S. Myers Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Tue, Nov 20, 2018 at 03:14:02PM +0100, Martin LiÅ¡ka wrote: > Following patch is a follow up of the discussion we had on IRC about > locations where a Fortran pre-include should be searched. > > With the patch applied I see now: > $ strace -f -s512 ./xgcc -B. ~/Programming/testcases/usage.F90 -c 2>&1 | grep math-vector > access("./x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("./math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/bin/../include/finclude/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/home/marxin/bin/gcc2/bin/../include/finclude/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/usr/include/finclude/x86_64-pc-linux-gnu/9.0.0/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > access("/usr/include/finclude/math-vector-fortran.h", R_OK) = -1 ENOENT (No such file or directory) > > static const char * > find_fortran_preinclude_file (int argc, const char **argv) > { > + char *result = NULL; > if (argc != 2) > return NULL; > it doesn't search the same directory as is normally searched for Fortran modules; that is finclude%s and thus would need to be yet another argument to this spec internal function and you'd check if a file exists with that prefix > + struct path_prefix prefixes = { 0, 0, "preinclude" }; > + add_prefix (&prefixes, STANDARD_BINDIR_PREFIX "../include/finclude/", NULL, > + 0, 0, 0); > + add_prefix (&prefixes, "/usr/include/finclude/", NULL, 0, 0, 0); hardcoding /usr/include looks just very wrong here. That should always be dependent on the configured prefix or better be relative from the driver, gcc should be relocatable. Or at least come from configure. It should e.g. honor the sysroot stuff etc. That said, I think you need somebody familiar with the driver, perhaps Joseph? Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-20 14:27 ` Jakub Jelinek @ 2018-11-20 18:11 ` Joseph Myers 2018-11-22 8:58 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2018-11-20 18:11 UTC (permalink / raw) To: Jakub Jelinek Cc: Martin Liška, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Tue, 20 Nov 2018, Jakub Jelinek wrote: > hardcoding /usr/include looks just very wrong here. That should always be > dependent on the configured prefix or better be relative from the driver, > gcc should be relocatable. Or at least come from configure. It should e.g. > honor the sysroot stuff etc. > > That said, I think you need somebody familiar with the driver, perhaps > Joseph? I'd sort of expect structures like those in cppdefault.[ch] to describe the relevant Fortran directories and their properties (such as being sysrooted or not - and if sysrooted, I suppose you'll want to make sure SYSROOT_HEADERS_SUFFIX_SPEC is properly applied). If this preinclude doesn't pass through the C preprocessor, directories in which it is searched for will need multilib or multiarch suffixes. (Multilib suffixes on include directories for C are more or less an implementation detail of how fixed headers are arranged in the case where sysroot headers suffixes are used; they aren't really expected to be a stable interface such that third-party software might install anything using them, but I'm not sure if this preinclude is meant to come from external software or be installed by GCC. Multiarch suffixes, for systems using Debian/Ubuntu-style multiarch directory arrangements, *are* intended as a stable interface. And multilib *OS* suffixes (-print-multi-os-directory) are a stable interface, but only really suitable for libraries, not headers, because they are paths relative to lib/ such as ../lib64.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-20 18:11 ` Joseph Myers @ 2018-11-22 8:58 ` Martin Liška 2018-11-22 14:35 ` Joseph Myers 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-22 8:58 UTC (permalink / raw) To: Joseph Myers, Jakub Jelinek Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/20/18 7:11 PM, Joseph Myers wrote: > On Tue, 20 Nov 2018, Jakub Jelinek wrote: > >> hardcoding /usr/include looks just very wrong here. That should always be >> dependent on the configured prefix or better be relative from the driver, >> gcc should be relocatable. Or at least come from configure. It should e.g. >> honor the sysroot stuff etc. >> >> That said, I think you need somebody familiar with the driver, perhaps >> Joseph? Hi Joseph. > > I'd sort of expect structures like those in cppdefault.[ch] to describe > the relevant Fortran directories and their properties (such as being > sysrooted or not - and if sysrooted, I suppose you'll want to make sure > SYSROOT_HEADERS_SUFFIX_SPEC is properly applied). We probably forgot to mention that the search mechanism happens in GCC driver. It's because we want to include the file (via a Fortran -fpre-include) conditionally only when found. > > If this preinclude doesn't pass through the C preprocessor, directories in > which it is searched for will need multilib or multiarch suffixes. No, it's not C preprocessor. > (Multilib suffixes on include directories for C are more or less an > implementation detail of how fixed headers are arranged in the case where > sysroot headers suffixes are used; they aren't really expected to be a > stable interface such that third-party software might install anything > using them, but I'm not sure if this preinclude is meant to come from > external software or be installed by GCC. It will come from glibc-devel package, and it's expected to be installed in: usr/include/finclude/ for 64-bit header and /usr/include/finclude/32/ for the 32-bit header. Multiarch suffixes, for systems > using Debian/Ubuntu-style multiarch directory arrangements, *are* intended > as a stable interface. And multilib *OS* suffixes > (-print-multi-os-directory) are a stable interface, but only really > suitable for libraries, not headers, because they are paths relative to > lib/ such as ../lib64.) If I understand correctly, Jakub wanted to have it working with -m32 being used for 64-bit GCC compiler. So yes, multi os for header files. So the question is what can we really do in the GCC driver? Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-22 8:58 ` Martin Liška @ 2018-11-22 14:35 ` Joseph Myers 2018-11-23 13:59 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2018-11-22 14:35 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 2625 bytes --] On Thu, 22 Nov 2018, Martin LiÅ¡ka wrote: > > (Multilib suffixes on include directories for C are more or less an > > implementation detail of how fixed headers are arranged in the case where > > sysroot headers suffixes are used; they aren't really expected to be a > > stable interface such that third-party software might install anything > > using them, but I'm not sure if this preinclude is meant to come from > > external software or be installed by GCC. > > It will come from glibc-devel package, and it's expected to be installed in: > usr/include/finclude/ for 64-bit header > and /usr/include/finclude/32/ for the 32-bit header. So, to be clear, is that <sysroot><sysroot-headers-suffix><native-system-header-dir>/finclude/$($CC $CFLAGS $CPPFLAGS -print-multi-directory) ? (Where glibc would be what uses the $CC $CFLAGS $CPPFLAGS -print-multi-directory to determine where to install the file.) If so, you need to make sure that all of those pieces are properly used. * The sysroot and headers suffix in the case of a sysrooted toolchain. (Sysroot headers suffixes are for e.g. the case of a toolchain with both glibc and uClibc multilibs, so needing multiple sets of headers. Most toolchains with multiple sysroots using the same libc only need a single set of headers and don't use sysroot headers suffixes, only sysroot suffixes (non-headers), with appropriate arrangements being made for all the per-multilib headers, such as gnu/lib-names-*.h and gnu/stubs-*.h, to be copied into the common include directory.) * The native system header directory (which is /include not /usr/include for GNU Hurd, for example; see config.gcc). * Then finclude with the multilib (non-OS) suffix. And you need to consider what's right for non-sysrooted toolchains. If native, the above is right, but without the sysroot-related components. But what about a non-sysrooted cross toolchain? Certainly using the native directory would be wrong there. Also, what's right in the multiarch directory arrangements case - should it be <sysroot><sysroot-headers-suffix><native-system-header-dir>/<multiarch>/finclude instead? Would one of the Debian / Ubuntu GCC maintainers like to comment? Are there corresponding versions with /usr/local/include (LOCAL_INCLUDE_DIR, in general), before those with NATIVE_SYSTEM_HEADER_DIR? Even in the driver, the list of directories in cppdefault.c should at least serve as a guide to which directories you want to search and which get sysroots added (of course, the C++-specific ones are irrelevant here). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-22 14:35 ` Joseph Myers @ 2018-11-23 13:59 ` Martin Liška 2018-11-23 18:08 ` Joseph Myers 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-23 13:59 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 2872 bytes --] On 11/22/18 3:35 PM, Joseph Myers wrote: > On Thu, 22 Nov 2018, Martin LiÅ¡ka wrote: > >>> (Multilib suffixes on include directories for C are more or less an >>> implementation detail of how fixed headers are arranged in the case where >>> sysroot headers suffixes are used; they aren't really expected to be a >>> stable interface such that third-party software might install anything >>> using them, but I'm not sure if this preinclude is meant to come from >>> external software or be installed by GCC. >> >> It will come from glibc-devel package, and it's expected to be installed in: >> usr/include/finclude/ for 64-bit header >> and /usr/include/finclude/32/ for the 32-bit header. > > So, to be clear, is that > > <sysroot><sysroot-headers-suffix><native-system-header-dir>/finclude/$($CC $CFLAGS $CPPFLAGS -print-multi-directory) > > ? (Where glibc would be what uses the $CC $CFLAGS $CPPFLAGS > -print-multi-directory to determine where to install the file.) > > If so, you need to make sure that all of those pieces are properly used. > > * The sysroot and headers suffix in the case of a sysrooted toolchain. > (Sysroot headers suffixes are for e.g. the case of a toolchain with both > glibc and uClibc multilibs, so needing multiple sets of headers. Most > toolchains with multiple sysroots using the same libc only need a single > set of headers and don't use sysroot headers suffixes, only sysroot > suffixes (non-headers), with appropriate arrangements being made for all > the per-multilib headers, such as gnu/lib-names-*.h and gnu/stubs-*.h, to > be copied into the common include directory.) > > * The native system header directory (which is /include not /usr/include > for GNU Hurd, for example; see config.gcc). > > * Then finclude with the multilib (non-OS) suffix. > > And you need to consider what's right for non-sysrooted toolchains. If > native, the above is right, but without the sysroot-related components. > But what about a non-sysrooted cross toolchain? Certainly using the > native directory would be wrong there. > > Also, what's right in the multiarch directory arrangements case - should > it be > <sysroot><sysroot-headers-suffix><native-system-header-dir>/<multiarch>/finclude > instead? Would one of the Debian / Ubuntu GCC maintainers like to > comment? > > Are there corresponding versions with /usr/local/include > (LOCAL_INCLUDE_DIR, in general), before those with > NATIVE_SYSTEM_HEADER_DIR? Even in the driver, the list of directories in > cppdefault.c should at least serve as a guide to which directories you > want to search and which get sysroots added (of course, the C++-specific > ones are irrelevant here). > Hi. Looks the problematic is quite complex as I can understand. I prepared a patch that should hopefully follow advises provided. Thoughts? Thanks, Martin [-- Attachment #2: 0001-Extend-locations-where-to-seach-for-Fortran-pre-incl.patch --] [-- Type: text/x-patch, Size: 3703 bytes --] From b59f043ff448f06ac95981d8a61b0dd63bc58bd7 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Tue, 20 Nov 2018 15:09:16 +0100 Subject: [PATCH] Extend locations where to seach for Fortran pre-include. --- gcc/Makefile.in | 4 ++- gcc/config/gnu-user.h | 2 +- gcc/gcc.c | 58 ++++++++++++++++++++++++++++--------------- 3 files changed, 42 insertions(+), 22 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 16c9ed6c5fd..c6ded7baf79 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \ @TARGET_SYSTEM_ROOT_DEFINE@ \ $(VALGRIND_DRIVER_DEFINES) \ $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \ - -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" + -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \ + -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \ + -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\" CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s) gcc.o: $(BASEVER) diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index d0acfed5116..eff6c7d6f83 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -173,4 +173,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #undef TARGET_F951_OPTIONS #define TARGET_F951_OPTIONS "%{!nostdinc:\ - %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}" diff --git a/gcc/gcc.c b/gcc/gcc.c index 4d01e1e2f3b..3b8b8eaf1bb 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -9891,20 +9891,54 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } -/* The function takes 2 arguments: OPTION name and file name. +static void +path_prefix_reset (path_prefix *prefix) +{ + struct prefix_list *iter, *next; + iter = prefix->plist; + while (iter) + { + next = iter->next; + free (const_cast <char *> (iter->prefix)); + XDELETE (iter); + iter = next; + } + prefix->plist = 0; + prefix->max_len = 0; +} + +/* The function takes 3 arguments: OPTION name, file name and location + where we search for Fortran modules. When the FILE is found by find_file, return OPTION=path_to_file. */ static const char * find_fortran_preinclude_file (int argc, const char **argv) { - if (argc != 2) + char *result = NULL; + if (argc != 3) return NULL; + struct path_prefix prefixes = { 0, 0, "preinclude" }; + add_prefix (&prefixes, argv[2], NULL, 0, 0, true); +#ifdef TOOL_INCLUDE_DIR + add_prefix (&prefixes, TOOL_INCLUDE_DIR "/finclude/", NULL, 0, 0, true); +#endif +#ifdef NATIVE_SYSTEM_HEADER_DIR + add_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR "/finclude/", NULL, 0, 0, true); +#endif + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); if (path != NULL) - return concat (argv[0], path, NULL); + result = concat (argv[0], path, NULL); + else + { + path = find_a_file (&prefixes, argv[1], R_OK, true); + if (path != NULL) + result = concat (argv[0], path, NULL); + } - return NULL; + path_prefix_reset (&prefixes); + return result; } @@ -9956,22 +9990,6 @@ convert_white_space (char *orig) return orig; } -static void -path_prefix_reset (path_prefix *prefix) -{ - struct prefix_list *iter, *next; - iter = prefix->plist; - while (iter) - { - next = iter->next; - free (const_cast <char *> (iter->prefix)); - XDELETE (iter); - iter = next; - } - prefix->plist = 0; - prefix->max_len = 0; -} - /* Restore all state within gcc.c to the initial state, so that the driver code can be safely re-run in-process. -- 2.19.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-23 13:59 ` Martin Liška @ 2018-11-23 18:08 ` Joseph Myers 2018-11-26 12:20 ` Martin Liška 2018-11-26 16:54 ` Martin Liška 0 siblings, 2 replies; 94+ messages in thread From: Joseph Myers @ 2018-11-23 18:08 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1027 bytes --] On Fri, 23 Nov 2018, Martin LiÅ¡ka wrote: > Looks the problematic is quite complex as I can understand. I prepared a patch > that should hopefully follow advises provided. I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is properly sysrooted. Note there's add_sysrooted_prefix separate from add_prefix (but that's *not* the correct thing to use here because it uses target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix). The last argument to add_prefix, which you're setting to true, is os_multilib. But using the OS multilib scheme seems wrong here, because the OS multilib names are names like "../lib64", which only make sense in directories called lib - you don't want to end up searching a directory <something>/include/finclude/../lib64. In the multiarch case, do you want <something>/include/finclude/<multiarch> or <something>/include/<multiarch>/finclude? (This is where I'd hope Debian / Ubuntu GCC people would comment.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-23 18:08 ` Joseph Myers @ 2018-11-26 12:20 ` Martin Liška 2018-11-26 16:19 ` Matthias Klose 2018-11-26 16:54 ` Martin Liška 1 sibling, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-26 12:20 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches, doko On 11/23/18 7:08 PM, Joseph Myers wrote: > In the multiarch case, do you want > <something>/include/finclude/<multiarch> or > <something>/include/<multiarch>/finclude? (This is where I'd hope Debian > / Ubuntu GCC people would comment.) Mathias can you please reply to this? Thanks, Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 12:20 ` Martin Liška @ 2018-11-26 16:19 ` Matthias Klose 2018-11-26 16:35 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Matthias Klose @ 2018-11-26 16:19 UTC (permalink / raw) To: Martin Liška, Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 26.11.18 13:20, Martin LiÅ¡ka wrote: > On 11/23/18 7:08 PM, Joseph Myers wrote: >> In the multiarch case, do you want >> <something>/include/finclude/<multiarch> or >> <something>/include/<multiarch>/finclude? (This is where I'd hope Debian >> / Ubuntu GCC people would comment.) > > Mathias can you please reply to this? this should not matter, as long as you use the multilib name, and the correct directory is used with the -m32/-m64/-mabi options. Are other compilers like a clang based compiler supposed to access this directory as well? In that case the include directories should be documented. One more question: Will GCC itself install header files in these directories, or will you have different directories depending on the GCC version (or gfortran module version)? Matthias ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 16:19 ` Matthias Klose @ 2018-11-26 16:35 ` Martin Liška 2018-11-26 18:33 ` Joseph Myers ` (2 more replies) 0 siblings, 3 replies; 94+ messages in thread From: Martin Liška @ 2018-11-26 16:35 UTC (permalink / raw) To: Matthias Klose, Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/26/18 5:19 PM, Matthias Klose wrote: > On 26.11.18 13:20, Martin LiÅ¡ka wrote: >> On 11/23/18 7:08 PM, Joseph Myers wrote: >>> In the multiarch case, do you want >>> <something>/include/finclude/<multiarch> or >>> <something>/include/<multiarch>/finclude? (This is where I'd hope Debian >>> / Ubuntu GCC people would comment.) >> >> Mathias can you please reply to this? > > this should not matter, as long as you use the multilib name, and the correct > directory is used with the -m32/-m64/-mabi options. Are other compilers like a > clang based compiler supposed to access this directory as well? I don't think so. > In that case > the include directories should be documented. > > One more question: Will GCC itself install header files in these directories, or > will you have different directories depending on the GCC version (or gfortran > module version)? The header file will be install by glibc (glibc-devel package). Martin > > Matthias > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 16:35 ` Martin Liška @ 2018-11-26 18:33 ` Joseph Myers 2018-11-27 13:34 ` Martin Liška 2018-11-27 7:57 ` Thomas Koenig 2018-11-27 16:22 ` Steve Ellcey 2 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2018-11-26 18:33 UTC (permalink / raw) To: Martin Liška Cc: Matthias Klose, Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 302 bytes --] On Mon, 26 Nov 2018, Martin LiÅ¡ka wrote: > The header file will be install by glibc (glibc-devel package). To confirm: you intend to submit a patch to glibc upstream to install this file (rather than it only being something in distribution packaging)? -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 18:33 ` Joseph Myers @ 2018-11-27 13:34 ` Martin Liška 0 siblings, 0 replies; 94+ messages in thread From: Martin Liška @ 2018-11-27 13:34 UTC (permalink / raw) To: Joseph Myers Cc: Matthias Klose, Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/26/18 7:33 PM, Joseph Myers wrote: > On Mon, 26 Nov 2018, Martin LiÅ¡ka wrote: > >> The header file will be install by glibc (glibc-devel package). > > To confirm: you intend to submit a patch to glibc upstream to install this > file (rather than it only being something in distribution packaging)? > Yes, I've already ask glibc people about it: https://sourceware.org/ml/libc-help/2018-11/msg00015.html I would appreciate a help with that. Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 16:35 ` Martin Liška 2018-11-26 18:33 ` Joseph Myers @ 2018-11-27 7:57 ` Thomas Koenig 2018-11-27 13:32 ` Martin Liška 2018-11-27 16:22 ` Steve Ellcey 2 siblings, 1 reply; 94+ messages in thread From: Thomas Koenig @ 2018-11-27 7:57 UTC (permalink / raw) To: Martin Liška, Matthias Klose, Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Toon Moene, GCC Patches Hi Martin, > he header file will be install by glibc (glibc-devel package). Why actually glibc-devel? Needing glibc-devel for fast compilation of Fortran seems to be counter-intuitive. Maybe glibc would be better. Regards Thomas ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-27 7:57 ` Thomas Koenig @ 2018-11-27 13:32 ` Martin Liška 0 siblings, 0 replies; 94+ messages in thread From: Martin Liška @ 2018-11-27 13:32 UTC (permalink / raw) To: Thomas Koenig, Matthias Klose, Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Toon Moene, GCC Patches On 11/27/18 8:57 AM, Thomas Koenig wrote: > Hi Martin, > >> he header file will be install by glibc (glibc-devel package). > > Why actually glibc-devel? Needing glibc-devel for fast compilation > of Fortran seems to be counter-intuitive. Maybe glibc would be better. Works for me. Martin > > Regards > >     Thomas ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 16:35 ` Martin Liška 2018-11-26 18:33 ` Joseph Myers 2018-11-27 7:57 ` Thomas Koenig @ 2018-11-27 16:22 ` Steve Ellcey 2018-11-27 21:12 ` Thomas Koenig 2 siblings, 1 reply; 94+ messages in thread From: Steve Ellcey @ 2018-11-27 16:22 UTC (permalink / raw) To: Martin Liška, Matthias Klose, Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Mon, 2018-11-26 at 17:35 +0100, Martin Liška wrote: > On 11/26/18 5:19 PM, Matthias Klose wrote: > > On 26.11.18 13:20, Martin Liška wrote: > > > On 11/23/18 7:08 PM, Joseph Myers wrote: > > > > In the multiarch case, do you want > > > > <something>/include/finclude/<multiarch> or > > > > <something>/include/<multiarch>/finclude? (This is where I'd > > > > hope Debian > > > > / Ubuntu GCC people would comment.) > > > > > > Mathias can you please reply to this? > > > > this should not matter, as long as you use the multilib name, and the correct > > directory is used with the -m32/-m64/-mabi options. Are other compilers like a > > clang based compiler supposed to access this directory as well? > > I don't think so. > > > In that case > > the include directories should be documented. Why wouldn't clang (flang) want to use the same mechanism as GCC/gfortran? I know there is some interest/work going on here for flang and we would like a consistent way to use pre-includes to define SIMD vector functions in both gfortran and flang. I think this should be documented so flang and other compilers can use it. Even if no other compilers did use it I think it should be documented because it crosses project/package boundries, i.e. it is created by glibc and used by gfortran. Steve Ellcey sellcey@cavium.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-27 16:22 ` Steve Ellcey @ 2018-11-27 21:12 ` Thomas Koenig 2019-02-18 13:23 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Thomas Koenig @ 2018-11-27 21:12 UTC (permalink / raw) To: Steve Ellcey, Martin Liška, Matthias Klose, Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Toon Moene, GCC Patches Am 27.11.18 um 17:22 schrieb Steve Ellcey: > Why wouldn't clang (flang) want to use the same mechanism as > GCC/gfortran? I know there is some interest/work going on here for > flang and we would like a consistent way to use pre-includes to define > SIMD vector functions in both gfortran and flang. I think this should > be documented so flang and other compilers can use it. Even if no > other compilers did use it I think it should be documented because it > crosses project/package boundries, i.e. it is created by glibc and used > by gfortran. Absolutely. As soon as this is committed, we should document all the specifics in the gfortran manual. Regards Thomas ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-27 21:12 ` Thomas Koenig @ 2019-02-18 13:23 ` Martin Liška 2019-02-19 18:18 ` Steve Kargl 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-02-18 13:23 UTC (permalink / raw) To: Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 898 bytes --] On 11/27/18 10:11 PM, Thomas Koenig wrote: > Am 27.11.18 um 17:22 schrieb Steve Ellcey: >> Why wouldn't clang (flang) want to use the same mechanism as >> GCC/gfortran? I know there is some interest/work going on here for >> flang and we would like a consistent way to use pre-includes to define >> SIMD vector functions in both gfortran and flang. I think this should >> be documented so flang and other compilers can use it. Even if no >> other compilers did use it I think it should be documented because it >> crosses project/package boundries, i.e. it is created by glibc and used >> by gfortran. > > Absolutely. > > As soon as this is committed, we should document all the > specifics in the gfortran manual. > > Regards > >     Thomas Hi. As I installed all needed patches, I'm sending a documentation entry for the new functionality. Thoughts? Thanks, Martin [-- Attachment #2: 0001-Document-Fortran-header-directive.patch --] [-- Type: text/x-patch, Size: 1444 bytes --] From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Mon, 18 Feb 2019 14:21:56 +0100 Subject: [PATCH] Document Fortran header directive. --- gcc/fortran/gfortran.texi | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index 02ff32f741f..72771a851f7 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -3596,6 +3596,25 @@ loop that follows. N is an integer constant specifying the unrolling factor. The values of 0 and 1 block any unrolling of the loop. +@node BUILTIN directive +@subsection BUILTIN directive + +The syntax of the directive is + +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')} + +You can used this directive to define which middle-end built-ins have vector +implementation. B is name of the middle-end built-in. FLAGS are optional +and must have be either "(inbranch)" or "(notinbranch)". IF statement +is optional and is used to filter multilib ABIs for that +the built-in should be vectorized. Example usage: + +@smallexample +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') +@end smallexample + +The purpose of the directive is to provide an API among the GCC compiler and +the GNU C Library which would define vector implementation of math routines. @node Non-Fortran Main Program @section Non-Fortran Main Program -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-18 13:23 ` Martin Liška @ 2019-02-19 18:18 ` Steve Kargl 2019-02-20 7:09 ` Bernhard Reutner-Fischer 0 siblings, 1 reply; 94+ messages in thread From: Steve Kargl @ 2019-02-19 18:18 UTC (permalink / raw) To: Martin Liška Cc: Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Toon Moene, GCC Patches On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin LiÅ¡ka wrote: > > As I installed all needed patches, I'm sending a documentation entry > for the new functionality. > > Thoughts? See below. Ok to commit with suggested changes. > Thanks, > Martin > >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00 2001 > From: marxin <mliska@suse.cz> > Date: Mon, 18 Feb 2019 14:21:56 +0100 > Subject: [PATCH] Document Fortran header directive. > > --- > gcc/fortran/gfortran.texi | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi > index 02ff32f741f..72771a851f7 100644 > --- a/gcc/fortran/gfortran.texi > +++ b/gcc/fortran/gfortran.texi > @@ -3596,6 +3596,25 @@ loop that follows. N is an integer constant specifying the unrolling factor. > The values of 0 and 1 block any unrolling of the loop. > > > +@node BUILTIN directive > +@subsection BUILTIN directive > + > +The syntax of the directive is > + > +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')} > + > +You can used this directive to define which middle-end built-ins have vector s/used/use > +implementation. B is name of the middle-end built-in. FLAGS are optional s/B is/@code{B} is the S/FLAGS/@code{FLAGS} > +and must have be either "(inbranch)" or "(notinbranch)". IF statement delete 'have' s/IF/The @code{IF} > +is optional and is used to filter multilib ABIs for that > +the built-in should be vectorized. Example usage: Change "for that the built-in should be vectorized" to "for the built-in that should be vectorized" > + > +@smallexample > +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') > +@end smallexample > + > +The purpose of the directive is to provide an API among the GCC compiler and > +the GNU C Library which would define vector implementation of math routines. > > @node Non-Fortran Main Program > @section Non-Fortran Main Program > -- > 2.20.1 > -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-19 18:18 ` Steve Kargl @ 2019-02-20 7:09 ` Bernhard Reutner-Fischer 2019-02-20 9:23 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Bernhard Reutner-Fischer @ 2019-02-20 7:09 UTC (permalink / raw) To: sgk, Steve Kargl, Martin Liška Cc: Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches On 19 February 2019 19:18:21 CET, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: >On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin Liška wrote: >> >> As I installed all needed patches, I'm sending a documentation entry >> for the new functionality. >> >> Thoughts? > >See below. Ok to commit with suggested changes. > >> Thanks, >> Martin > >> >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00 >2001 >> From: marxin <mliska@suse.cz> >> Date: Mon, 18 Feb 2019 14:21:56 +0100 >> Subject: [PATCH] Document Fortran header directive. >> >> --- >> gcc/fortran/gfortran.texi | 19 +++++++++++++++++++ >> 1 file changed, 19 insertions(+) >> >> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi >> index 02ff32f741f..72771a851f7 100644 >> --- a/gcc/fortran/gfortran.texi >> +++ b/gcc/fortran/gfortran.texi >> @@ -3596,6 +3596,25 @@ loop that follows. N is an integer constant >specifying the unrolling factor. >> The values of 0 and 1 block any unrolling of the loop. >> >> >> +@node BUILTIN directive >> +@subsection BUILTIN directive >> + >> +The syntax of the directive is >> + >> +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')} >> + >> +You can used this directive to define which middle-end built-ins >have vector > >s/used/use > >> +implementation. B is name of the middle-end built-in. FLAGS are >optional > >s/B is/@code{B} is the >S/FLAGS/@code{FLAGS} > >> +and must have be either "(inbranch)" or "(notinbranch)". IF >statement > >delete 'have' >s/IF/The @code{IF} > >> +is optional and is used to filter multilib ABIs for that >> +the built-in should be vectorized. Example usage: > >Change "for that the built-in should be vectorized" to >"for the built-in that should be vectorized" > > >> + >> +@smallexample >> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') >> +@end smallexample >> + >> +The purpose of the directive is to provide an API among the GCC >compiler and >> +the GNU C Library which would define vector implementation of math >routines. s/implementation/implementations/ define? Or provide. Thanks, >> >> @node Non-Fortran Main Program >> @section Non-Fortran Main Program >> -- >> 2.20.1 >> ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 7:09 ` Bernhard Reutner-Fischer @ 2019-02-20 9:23 ` Martin Liška 2019-02-20 9:37 ` Thomas König 2019-02-20 9:52 ` Bernhard Reutner-Fischer 0 siblings, 2 replies; 94+ messages in thread From: Martin Liška @ 2019-02-20 9:23 UTC (permalink / raw) To: Bernhard Reutner-Fischer, sgk Cc: Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches On 2/20/19 8:06 AM, Bernhard Reutner-Fischer wrote: > On 19 February 2019 19:18:21 CET, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: >> On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin LiÅ¡ka wrote: >>> >>> As I installed all needed patches, I'm sending a documentation entry >>> for the new functionality. >>> >>> Thoughts? >> >> See below. Ok to commit with suggested changes. >> >>> Thanks, >>> Martin >> >>> >From 2d304e3b1d734548811f963c5bed1855b5375c43 Mon Sep 17 00:00:00 >> 2001 >>> From: marxin <mliska@suse.cz> >>> Date: Mon, 18 Feb 2019 14:21:56 +0100 >>> Subject: [PATCH] Document Fortran header directive. >>> >>> --- >>> gcc/fortran/gfortran.texi | 19 +++++++++++++++++++ >>> 1 file changed, 19 insertions(+) >>> >>> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi >>> index 02ff32f741f..72771a851f7 100644 >>> --- a/gcc/fortran/gfortran.texi >>> +++ b/gcc/fortran/gfortran.texi >>> @@ -3596,6 +3596,25 @@ loop that follows. N is an integer constant >> specifying the unrolling factor. >>> The values of 0 and 1 block any unrolling of the loop. >>> >>> >>> +@node BUILTIN directive >>> +@subsection BUILTIN directive >>> + >>> +The syntax of the directive is >>> + >>> +@code{!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')} >>> + >>> +You can used this directive to define which middle-end built-ins >> have vector >> >> s/used/use >> >>> +implementation. B is name of the middle-end built-in. FLAGS are >> optional >> >> s/B is/@code{B} is the >> S/FLAGS/@code{FLAGS} >> >>> +and must have be either "(inbranch)" or "(notinbranch)". IF >> statement >> >> delete 'have' >> s/IF/The @code{IF} >> >>> +is optional and is used to filter multilib ABIs for that >>> +the built-in should be vectorized. Example usage: >> >> Change "for that the built-in should be vectorized" to >> "for the built-in that should be vectorized" >> >> >>> + >>> +@smallexample >>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') >>> +@end smallexample >>> + >>> +The purpose of the directive is to provide an API among the GCC >> compiler and >>> +the GNU C Library which would define vector implementation of math >> routines. > > s/implementation/implementations/ > > define? Or provide. > > Thanks, > >>> >>> @node Non-Fortran Main Program >>> @section Non-Fortran Main Program >>> -- >>> 2.20.1 >>> > Hello. Thank you both useful comments! I installed that as r269035. Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 9:23 ` Martin Liška @ 2019-02-20 9:37 ` Thomas König 2019-02-20 14:17 ` Martin Liška 2019-02-20 9:52 ` Bernhard Reutner-Fischer 1 sibling, 1 reply; 94+ messages in thread From: Thomas König @ 2019-02-20 9:37 UTC (permalink / raw) To: Martin Liška Cc: Bernhard Reutner-Fischer, sgk, Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches Hi Martin, > Thank you both useful comments! I installed that as r269035. Excellent work, thanks! Now a final step: Could you also add a short sentence to gcc-9/changes.html ? In German, we have a saying „Tue Gutes und rede darüber“, do good deeds and talk about it 😉 Regards, Thomas ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 9:37 ` Thomas König @ 2019-02-20 14:17 ` Martin Liška 2019-02-20 20:11 ` Thomas König 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-02-20 14:17 UTC (permalink / raw) To: Thomas König Cc: Bernhard Reutner-Fischer, sgk, Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 525 bytes --] On 2/20/19 10:36 AM, Thomas König wrote: > Hi Martin, > >> Thank you both useful comments! I installed that as r269035. > > Excellent work, thanks! ;) > > Now a final step: Could you also add a short sentence to gcc-9/changes.html ? In German, we have a saying „Tue Gutes und rede darüber“, do good deeds and talk about it 😉 > > Regards, Thomas > Sure, let's document it with patch attached. Btw. the glibc part patch has been just approved and will be available in glibc release 2.30. Martin [-- Attachment #2: 0001-Document-Fortran-BUILTIN-directive.patch --] [-- Type: text/x-patch, Size: 963 bytes --] From 71a1c50d617c88ea9025385e8139d51e77321c81 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Wed, 20 Feb 2019 15:13:52 +0100 Subject: [PATCH] Document Fortran BUILTIN directive. --- htdocs/gcc-9/changes.html | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html index 4d9f549..ee7aac1 100644 --- a/htdocs/gcc-9/changes.html +++ b/htdocs/gcc-9/changes.html @@ -243,6 +243,11 @@ foo (int how) which allows the directive to be written on multiple source lines with line continuations. </li> + <li> + A new <a href="https://gcc.gnu.org/onlinedocs/gfortran/BUILTIN-directive.html#BUILTIN-directive"><code>BUILTIN</code></a> directive, has been added. + The purpose of the directive is to provide an API among the GCC compiler and + the GNU C Library which would define vector implementations of math routines. + </li> </ul> <!-- <h3 id="go">Go</h3> --> -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 14:17 ` Martin Liška @ 2019-02-20 20:11 ` Thomas König 0 siblings, 0 replies; 94+ messages in thread From: Thomas König @ 2019-02-20 20:11 UTC (permalink / raw) To: Martin Liška Cc: Bernhard Reutner-Fischer, sgk, Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches Hi Martin, I would change "among" to "between" in the sentence below. OK otherwise (not that I think an OK is really needed in this case). + The purpose of the directive is to provide an API among the GCC compiler and + the GNU C Library which would define vector implementations of math routines. Regards Thomas ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 9:23 ` Martin Liška 2019-02-20 9:37 ` Thomas König @ 2019-02-20 9:52 ` Bernhard Reutner-Fischer 2019-02-20 9:57 ` Martin Liška 1 sibling, 1 reply; 94+ messages in thread From: Bernhard Reutner-Fischer @ 2019-02-20 9:52 UTC (permalink / raw) To: Martin Liška Cc: Steve Kargl, Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches Marin, > >>> + > >>> +@smallexample > >>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') > >>> +@end smallexample > >>> + > >>> +The purpose of the directive is to provide an API among the GCC > >> compiler and > >>> +the GNU C Library which would define vector implementation of math > >> routines. > > > > s/implementation/implementations/ > > > > define? Or provide. > > > > Thanks, > > > >>> > >>> @node Non-Fortran Main Program > >>> @section Non-Fortran Main Program > >>> -- > >>> 2.20.1 > >>> > > > > Hello. > > Thank you both useful comments! I installed that as r269035. AFAICS you ignored my comment though ;) thanks, ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 9:52 ` Bernhard Reutner-Fischer @ 2019-02-20 9:57 ` Martin Liška 2019-02-20 10:46 ` Bernhard Reutner-Fischer 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-02-20 9:57 UTC (permalink / raw) To: Bernhard Reutner-Fischer Cc: Steve Kargl, Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote: > Marin, > >>>>> + >>>>> +@smallexample >>>>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') >>>>> +@end smallexample >>>>> + >>>>> +The purpose of the directive is to provide an API among the GCC >>>> compiler and >>>>> +the GNU C Library which would define vector implementation of math >>>> routines. >>> >>> s/implementation/implementations/ >>> >>> define? Or provide. >>> >>> Thanks, >>> >>>>> >>>>> @node Non-Fortran Main Program >>>>> @section Non-Fortran Main Program >>>>> -- >>>>> 2.20.1 >>>>> >>> >> >> Hello. >> >> Thank you both useful comments! I installed that as r269035. > > AFAICS you ignored my comment though ;) > thanks, > Hi. I reworded first sentence into: "You can use this directive to define which middle-end built-ins provide vector implementations" That should align with the comment you sent? Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 9:57 ` Martin Liška @ 2019-02-20 10:46 ` Bernhard Reutner-Fischer 2019-02-20 11:12 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Bernhard Reutner-Fischer @ 2019-02-20 10:46 UTC (permalink / raw) To: Martin Liška Cc: Steve Kargl, Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches On 20 February 2019 10:57:29 CET, "Martin Liška" <mliska@suse.cz> wrote: >On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote: >> Marin, >> >>>>>> + >>>>>> +@smallexample >>>>>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') >>>>>> +@end smallexample >>>>>> + >>>>>> +The purpose of the directive is to provide an API among the GCC >>>>> compiler and >>>>>> +the GNU C Library which would define vector implementation of >math >>>>> routines. >>>> >>>> s/implementation/implementations/ >>>> >>>> define? Or provide. >>>> >>>> Thanks, >>>> >>>>>> >>>>>> @node Non-Fortran Main Program >>>>>> @section Non-Fortran Main Program >>>>>> -- >>>>>> 2.20.1 >>>>>> >>>> >>> >>> Hello. >>> >>> Thank you both useful comments! I installed that as r269035. >> >> AFAICS you ignored my comment though ;) >> thanks, >> > >Hi. > >I reworded first sentence into: >"You can use this directive to define which middle-end built-ins >provide vector implementations" > >That should align with the comment you sent? My comment concerned the sentence below the example as per above. You committed the version with singular: https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/gfortran.texi;h=39441bdd57f1369ef7b0fccb204934effc07e21b;hp=02ff32f741f1c6f7c1490b6e35ca7e5111ccd21f;hb=f4ed9e9b1f6c918e6141813491577f6e5d346f96;hpb=25395ee8780231bd50f23c64f9df03b500aad940 thanks, ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-02-20 10:46 ` Bernhard Reutner-Fischer @ 2019-02-20 11:12 ` Martin Liška 0 siblings, 0 replies; 94+ messages in thread From: Martin Liška @ 2019-02-20 11:12 UTC (permalink / raw) To: Bernhard Reutner-Fischer Cc: Steve Kargl, Thomas Koenig, Steve Ellcey, Matthias Klose, Joseph Myers, Jakub Jelinek, Richard Biener, fortran, Toon Moene, GCC Patches On 2/20/19 11:45 AM, Bernhard Reutner-Fischer wrote: > On 20 February 2019 10:57:29 CET, "Martin LiÅ¡ka" <mliska@suse.cz> wrote: >> On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote: >>> Marin, >>> >>>>>>> + >>>>>>> +@smallexample >>>>>>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64') >>>>>>> +@end smallexample >>>>>>> + >>>>>>> +The purpose of the directive is to provide an API among the GCC >>>>>> compiler and >>>>>>> +the GNU C Library which would define vector implementation of >> math >>>>>> routines. >>>>> >>>>> s/implementation/implementations/ >>>>> >>>>> define? Or provide. >>>>> >>>>> Thanks, >>>>> >>>>>>> >>>>>>> @node Non-Fortran Main Program >>>>>>> @section Non-Fortran Main Program >>>>>>> -- >>>>>>> 2.20.1 >>>>>>> >>>>> >>>> >>>> Hello. >>>> >>>> Thank you both useful comments! I installed that as r269035. >>> >>> AFAICS you ignored my comment though ;) >>> thanks, >>> >> >> Hi. >> >> I reworded first sentence into: >> "You can use this directive to define which middle-end built-ins >> provide vector implementations" >> >> That should align with the comment you sent? > > My comment concerned the sentence below the example as per above. > You committed the version with singular: > > https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/fortran/gfortran.texi;h=39441bdd57f1369ef7b0fccb204934effc07e21b;hp=02ff32f741f1c6f7c1490b6e35ca7e5111ccd21f;hb=f4ed9e9b1f6c918e6141813491577f6e5d346f96;hpb=25395ee8780231bd50f23c64f9df03b500aad940 > > thanks, > Ah, yes, now that sentence should be fixed in r269038. Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-23 18:08 ` Joseph Myers 2018-11-26 12:20 ` Martin Liška @ 2018-11-26 16:54 ` Martin Liška 2018-11-26 18:45 ` Joseph Myers 1 sibling, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-26 16:54 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1514 bytes --] On 11/23/18 7:08 PM, Joseph Myers wrote: > On Fri, 23 Nov 2018, Martin LiÅ¡ka wrote: > >> Looks the problematic is quite complex as I can understand. I prepared a patch >> that should hopefully follow advises provided. Hello. > > I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is > properly sysrooted. Note there's add_sysrooted_prefix separate from > add_prefix (but that's *not* the correct thing to use here because it uses > target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix). I address that in updated version of the patch. > > The last argument to add_prefix, which you're setting to true, is > os_multilib. But using the OS multilib scheme seems wrong here, because > the OS multilib names are names like "../lib64", which only make sense in > directories called lib - you don't want to end up searching a directory > <something>/include/finclude/../lib64. Agree, does not make sense. > > In the multiarch case, do you want > <something>/include/finclude/<multiarch> or > <something>/include/<multiarch>/finclude? (This is where I'd hope Debian > / Ubuntu GCC people would comment.) > As Mathias wrote he's fine with both of these variants. I've just configure a compiler with --enable-multiarch=yes and I see that the file is eventually searched in: /usr/include/finclude/i386-linux-gnu/math-vector-fortran.h (with -m32) and /usr/include/finclude/x86_64-linux-gnu/math-vector-fortran.h (with -m64) Which looks fine to me? Thanks, Martin [-- Attachment #2: 0001-Extend-locations-where-to-seach-for-Fortran-pre-incl.patch --] [-- Type: text/x-patch, Size: 5397 bytes --] From 84202b443adc00e0847b17c07e3dbf3451e77fb9 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Tue, 20 Nov 2018 15:09:16 +0100 Subject: [PATCH] Extend locations where to seach for Fortran pre-include. --- gcc/Makefile.in | 4 +- gcc/config/gnu-user.h | 2 +- gcc/gcc.c | 99 ++++++++++++++++++++++++++++++++++--------- 3 files changed, 83 insertions(+), 22 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 16c9ed6c5fd..c6ded7baf79 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \ @TARGET_SYSTEM_ROOT_DEFINE@ \ $(VALGRIND_DRIVER_DEFINES) \ $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \ - -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" + -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \ + -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \ + -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\" CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s) gcc.o: $(BASEVER) diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index d0acfed5116..eff6c7d6f83 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -173,4 +173,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #undef TARGET_F951_OPTIONS #define TARGET_F951_OPTIONS "%{!nostdinc:\ - %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}" diff --git a/gcc/gcc.c b/gcc/gcc.c index 4d01e1e2f3b..7c57fe03b41 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -2976,6 +2976,45 @@ add_sysrooted_prefix (struct path_prefix *pprefix, const char *prefix, add_prefix (pprefix, prefix, component, priority, require_machine_suffix, os_multilib); } + +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix. */ + +static void +add_sysrooted_hdrs_prefix (struct path_prefix *pprefix, const char *prefix, + const char *component, + /* enum prefix_priority */ int priority, + int require_machine_suffix, int os_multilib) +{ + if (!IS_ABSOLUTE_PATH (prefix)) + fatal_error (input_location, "system path %qs is not absolute", prefix); + + if (target_sysroot_hdrs_suffix) + { + char *sysroot_no_trailing_dir_separator + = xstrdup (target_sysroot_hdrs_suffix); + size_t sysroot_len = strlen (target_sysroot_hdrs_suffix); + + if (sysroot_len > 0 + && target_sysroot_hdrs_suffix [sysroot_len - 1] == DIR_SEPARATOR) + sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0'; + + if (target_sysroot_suffix) + prefix = concat (sysroot_no_trailing_dir_separator, + target_sysroot_suffix, prefix, NULL); + else + prefix = concat (sysroot_no_trailing_dir_separator, prefix, NULL); + + free (sysroot_no_trailing_dir_separator); + + /* We have to override this because GCC's notion of sysroot + moves along with GCC. */ + component = "GCC"; + } + + add_prefix (pprefix, prefix, component, priority, + require_machine_suffix, os_multilib); +} + \f /* Execute the command specified by the arguments on the current line of spec. When using pipes, this includes several piped-together commands @@ -9891,20 +9930,56 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } -/* The function takes 2 arguments: OPTION name and file name. +static void +path_prefix_reset (path_prefix *prefix) +{ + struct prefix_list *iter, *next; + iter = prefix->plist; + while (iter) + { + next = iter->next; + free (const_cast <char *> (iter->prefix)); + XDELETE (iter); + iter = next; + } + prefix->plist = 0; + prefix->max_len = 0; +} + +/* The function takes 3 arguments: OPTION name, file name and location + where we search for Fortran modules. When the FILE is found by find_file, return OPTION=path_to_file. */ static const char * find_fortran_preinclude_file (int argc, const char **argv) { - if (argc != 2) + char *result = NULL; + if (argc != 3) return NULL; + struct path_prefix prefixes = { 0, 0, "preinclude" }; + add_sysrooted_hdrs_prefix (&prefixes, argv[2], NULL, 0, 0, false); +#ifdef TOOL_INCLUDE_DIR + add_sysrooted_hdrs_prefix (&prefixes, TOOL_INCLUDE_DIR "/finclude/", + NULL, 0, 0, false); +#endif +#ifdef NATIVE_SYSTEM_HEADER_DIR + add_sysrooted_hdrs_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR "/finclude/", + NULL, 0, 0, false); +#endif + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); if (path != NULL) - return concat (argv[0], path, NULL); + result = concat (argv[0], path, NULL); + else + { + path = find_a_file (&prefixes, argv[1], R_OK, true); + if (path != NULL) + result = concat (argv[0], path, NULL); + } - return NULL; + path_prefix_reset (&prefixes); + return result; } @@ -9956,22 +10031,6 @@ convert_white_space (char *orig) return orig; } -static void -path_prefix_reset (path_prefix *prefix) -{ - struct prefix_list *iter, *next; - iter = prefix->plist; - while (iter) - { - next = iter->next; - free (const_cast <char *> (iter->prefix)); - XDELETE (iter); - iter = next; - } - prefix->plist = 0; - prefix->max_len = 0; -} - /* Restore all state within gcc.c to the initial state, so that the driver code can be safely re-run in-process. -- 2.19.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 16:54 ` Martin Liška @ 2018-11-26 18:45 ` Joseph Myers 2018-11-27 13:40 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2018-11-26 18:45 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1133 bytes --] On Mon, 26 Nov 2018, Martin LiÅ¡ka wrote: > > I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is > > properly sysrooted. Note there's add_sysrooted_prefix separate from > > add_prefix (but that's *not* the correct thing to use here because it uses > > target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix). > > I address that in updated version of the patch. However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well. I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, roughly) is a non-sysroot location for headers. Note that it's not sysrooted in cppdefault.c, which is a good guide to which directories should or should not be sysrooted, and what order they should come in (though as discussed, various of the directories there are not relevant for the present issue). The patch appears to be against some tree other than current trunk. At least, it shows a function find_fortran_preinclude_file in gcc.c as already existing in the diff context, but I see no such function in the current sources. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-26 18:45 ` Joseph Myers @ 2018-11-27 13:40 ` Martin Liška 2018-11-30 13:51 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-27 13:40 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/26/18 7:44 PM, Joseph Myers wrote: > On Mon, 26 Nov 2018, Martin LiÅ¡ka wrote: > >>> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is >>> properly sysrooted. Note there's add_sysrooted_prefix separate from >>> add_prefix (but that's *not* the correct thing to use here because it uses >>> target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix). >> >> I address that in updated version of the patch. > > However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well. > I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, > roughly) is a non-sysroot location for headers. Note that it's not > sysrooted in cppdefault.c, which is a good guide to which directories > should or should not be sysrooted, and what order they should come in > (though as discussed, various of the directories there are not relevant > for the present issue). > > The patch appears to be against some tree other than current trunk. At > least, it shows a function find_fortran_preinclude_file in gcc.c as > already existing in the diff context, but I see no such function in the > current sources. > I've just installed a prerequisite patch and now you should be able to apply the patch on top of current trunk. Thanks, Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-27 13:40 ` Martin Liška @ 2018-11-30 13:51 ` Martin Liška 2019-01-09 16:01 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2018-11-30 13:51 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/27/18 2:40 PM, Martin LiÅ¡ka wrote: > On 11/26/18 7:44 PM, Joseph Myers wrote: >> On Mon, 26 Nov 2018, Martin LiÅ¡ka wrote: >> >>>> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is >>>> properly sysrooted. Note there's add_sysrooted_prefix separate from >>>> add_prefix (but that's *not* the correct thing to use here because it uses >>>> target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix). >>> >>> I address that in updated version of the patch. >> >> However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well. >> I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, >> roughly) is a non-sysroot location for headers. Note that it's not >> sysrooted in cppdefault.c, which is a good guide to which directories >> should or should not be sysrooted, and what order they should come in >> (though as discussed, various of the directories there are not relevant >> for the present issue). >> >> The patch appears to be against some tree other than current trunk. At >> least, it shows a function find_fortran_preinclude_file in gcc.c as >> already existing in the diff context, but I see no such function in the >> current sources. >> > > I've just installed a prerequisite patch and now you should be able > to apply the patch on top of current trunk. > > Thanks, > Martin > Hi Joseph. About this: I'll be away for next 3 weeks and I'm planning to return to this once I'm back. If you find a spare cycles and help me with the location which should be searched in find_fortran_preinclude_file, I would be happy ;) Thanks, Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2018-11-30 13:51 ` Martin Liška @ 2019-01-09 16:01 ` Martin Liška 2019-01-09 17:16 ` Joseph Myers 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-09 16:01 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 11/30/18 2:51 PM, Martin LiÅ¡ka wrote: > On 11/27/18 2:40 PM, Martin LiÅ¡ka wrote: >> On 11/26/18 7:44 PM, Joseph Myers wrote: >>> On Mon, 26 Nov 2018, Martin LiÅ¡ka wrote: >>> >>>>> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is >>>>> properly sysrooted. Note there's add_sysrooted_prefix separate from >>>>> add_prefix (but that's *not* the correct thing to use here because it uses >>>>> target_sysroot_suffix whereas you need target_sysroot_hdrs_suffix). >>>> >>>> I address that in updated version of the patch. >>> >>> However, this version seems to make TOOL_INCLUDE_DIR sysrooted as well. >>> I don't think that's correct; TOOL_INCLUDE_DIR ($prefix/$target/include, >>> roughly) is a non-sysroot location for headers. Note that it's not >>> sysrooted in cppdefault.c, which is a good guide to which directories >>> should or should not be sysrooted, and what order they should come in >>> (though as discussed, various of the directories there are not relevant >>> for the present issue). >>> >>> The patch appears to be against some tree other than current trunk. At >>> least, it shows a function find_fortran_preinclude_file in gcc.c as >>> already existing in the diff context, but I see no such function in the >>> current sources. >>> >> >> I've just installed a prerequisite patch and now you should be able >> to apply the patch on top of current trunk. >> >> Thanks, >> Martin >> > > Hi Joseph. > > About this: I'll be away for next 3 weeks and I'm planning to return to > this once I'm back. If you find a spare cycles and help me with the > location which should be searched in find_fortran_preinclude_file, I would > be happy ;) Hi. May I please ping that Joseph. The provided patch should be applicable and I would need help with the proper locations. Thanks, Martin > > Thanks, > Martin > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-01-09 16:01 ` Martin Liška @ 2019-01-09 17:16 ` Joseph Myers 2019-01-09 17:21 ` Joseph Myers 2019-01-11 15:17 ` Martin Liška 0 siblings, 2 replies; 94+ messages in thread From: Joseph Myers @ 2019-01-09 17:16 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 728 bytes --] On Wed, 9 Jan 2019, Martin LiÅ¡ka wrote: > Hi. > > May I please ping that Joseph. The provided patch should be applicable and > I would need help with the proper locations. I'm not clear if there is a specific question here, or a patch needing review. In <https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02106.html> I noted a specific issue: TOOL_INCLUDE_DIR should be a non-sysrooted prefix. Also, could you clarify what, in the patch <https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02089.html> (if that's still the current version), > + add_sysrooted_hdrs_prefix (&prefixes, argv[2], NULL, 0, 0, false); is doing (that is, examples of what sort of prefixes it's adding)? -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-01-09 17:16 ` Joseph Myers @ 2019-01-09 17:21 ` Joseph Myers 2019-01-11 15:17 ` Martin Liška 1 sibling, 0 replies; 94+ messages in thread From: Joseph Myers @ 2019-01-09 17:21 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, 9 Jan 2019, Joseph Myers wrote: > Also, could you clarify what, in the patch > <https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02089.html> (if that's > still the current version), > > > + add_sysrooted_hdrs_prefix (&prefixes, argv[2], NULL, 0, 0, false); > > is doing (that is, examples of what sort of prefixes it's adding)? (I guess this indicates something for the next revision of the patch - if each add_sysrooted_hdrs_prefix call has a comment indicating the sort of path you expect to be searched, e.g. <sysroot>/usr/include/finclude/<multilib>, that would help both review and subsequent readers of the code.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-01-09 17:16 ` Joseph Myers 2019-01-09 17:21 ` Joseph Myers @ 2019-01-11 15:17 ` Martin Liška 2019-01-11 18:06 ` Joseph Myers 1 sibling, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-11 15:17 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 859 bytes --] On 1/9/19 6:15 PM, Joseph Myers wrote: > On Wed, 9 Jan 2019, Martin LiÅ¡ka wrote: > >> Hi. >> >> May I please ping that Joseph. The provided patch should be applicable and >> I would need help with the proper locations. > > I'm not clear if there is a specific question here, or a patch needing > review. In <https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02106.html> I > noted a specific issue: TOOL_INCLUDE_DIR should be a non-sysrooted prefix. > > Also, could you clarify what, in the patch > <https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02089.html> (if that's > still the current version), > >> + add_sysrooted_hdrs_prefix (&prefixes, argv[2], NULL, 0, 0, false); > > is doing (that is, examples of what sort of prefixes it's adding)? > Hi. I'm sending updated version of the patch that addresses the 2 notes mentioned by Joseph. Martin [-- Attachment #2: 0001-Extend-locations-where-to-seach-for-Fortran-pre-incl.patch --] [-- Type: text/x-patch, Size: 5620 bytes --] From 531180219809153592100a9eb92ca07b1bf51bda Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Tue, 20 Nov 2018 15:09:16 +0100 Subject: [PATCH] Extend locations where to seach for Fortran pre-include. --- gcc/Makefile.in | 4 +- gcc/config/gnu-user.h | 2 +- gcc/gcc.c | 104 ++++++++++++++++++++++++++++++++++-------- 3 files changed, 88 insertions(+), 22 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 2fa9083d1b3..095156bd537 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \ @TARGET_SYSTEM_ROOT_DEFINE@ \ $(VALGRIND_DRIVER_DEFINES) \ $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \ - -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" + -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \ + -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \ + -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\" CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s) gcc.o: $(BASEVER) diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index ba146921655..055a4f0afec 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -151,4 +151,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #undef TARGET_F951_OPTIONS #define TARGET_F951_OPTIONS "%{!nostdinc:\ - %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}" diff --git a/gcc/gcc.c b/gcc/gcc.c index bcd04df1691..79e1e7d5f6e 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -2976,6 +2976,45 @@ add_sysrooted_prefix (struct path_prefix *pprefix, const char *prefix, add_prefix (pprefix, prefix, component, priority, require_machine_suffix, os_multilib); } + +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix. */ + +static void +add_sysrooted_hdrs_prefix (struct path_prefix *pprefix, const char *prefix, + const char *component, + /* enum prefix_priority */ int priority, + int require_machine_suffix, int os_multilib) +{ + if (!IS_ABSOLUTE_PATH (prefix)) + fatal_error (input_location, "system path %qs is not absolute", prefix); + + if (target_sysroot_hdrs_suffix) + { + char *sysroot_no_trailing_dir_separator + = xstrdup (target_sysroot_hdrs_suffix); + size_t sysroot_len = strlen (target_sysroot_hdrs_suffix); + + if (sysroot_len > 0 + && target_sysroot_hdrs_suffix[sysroot_len - 1] == DIR_SEPARATOR) + sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0'; + + if (target_sysroot_suffix) + prefix = concat (sysroot_no_trailing_dir_separator, + target_sysroot_suffix, prefix, NULL); + else + prefix = concat (sysroot_no_trailing_dir_separator, prefix, NULL); + + free (sysroot_no_trailing_dir_separator); + + /* We have to override this because GCC's notion of sysroot + moves along with GCC. */ + component = "GCC"; + } + + add_prefix (pprefix, prefix, component, priority, + require_machine_suffix, os_multilib); +} + \f /* Execute the command specified by the arguments on the current line of spec. When using pipes, this includes several piped-together commands @@ -9896,20 +9935,61 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } -/* The function takes 2 arguments: OPTION name and file name. +static void +path_prefix_reset (path_prefix *prefix) +{ + struct prefix_list *iter, *next; + iter = prefix->plist; + while (iter) + { + next = iter->next; + free (const_cast <char *> (iter->prefix)); + XDELETE (iter); + iter = next; + } + prefix->plist = 0; + prefix->max_len = 0; +} + +/* The function takes 3 arguments: OPTION name, file name and location + where we search for Fortran modules. When the FILE is found by find_file, return OPTION=path_to_file. */ static const char * find_fortran_preinclude_file (int argc, const char **argv) { - if (argc != 2) + char *result = NULL; + if (argc != 3) return NULL; + struct path_prefix prefixes = { 0, 0, "preinclude" }; + + /* Search first for 'finclude' folder location for a header file + installed by the compiler (similar to omp_lib.h). */ + add_prefix (&prefixes, argv[2], NULL, 0, 0, false); +#ifdef TOOL_INCLUDE_DIR + /* Then search: <prefix>/<target>/<include>/finclude */ + add_prefix (&prefixes, TOOL_INCLUDE_DIR "/finclude/", + NULL, 0, 0, false); +#endif +#ifdef NATIVE_SYSTEM_HEADER_DIR + /* Then search: <sysroot>/usr/include/finclude/<multilib> */ + add_sysrooted_hdrs_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR "/finclude/", + NULL, 0, 0, false); +#endif + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); if (path != NULL) - return concat (argv[0], path, NULL); + result = concat (argv[0], path, NULL); + else + { + path = find_a_file (&prefixes, argv[1], R_OK, true); + if (path != NULL) + result = concat (argv[0], path, NULL); + } - return NULL; + path_prefix_reset (&prefixes); + return result; } @@ -9961,22 +10041,6 @@ convert_white_space (char *orig) return orig; } -static void -path_prefix_reset (path_prefix *prefix) -{ - struct prefix_list *iter, *next; - iter = prefix->plist; - while (iter) - { - next = iter->next; - free (const_cast <char *> (iter->prefix)); - XDELETE (iter); - iter = next; - } - prefix->plist = 0; - prefix->max_len = 0; -} - /* Restore all state within gcc.c to the initial state, so that the driver code can be safely re-run in-process. -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-01-11 15:17 ` Martin Liška @ 2019-01-11 18:06 ` Joseph Myers 2019-01-14 14:09 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-01-11 18:06 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1120 bytes --] On Fri, 11 Jan 2019, Martin LiÅ¡ka wrote: > +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix. */ Actually, it should be prepending target_system_root, but followed by target_sysroot_hdrs_suffix rather than target_sysroot_suffix. That is, this function should be following add_sysrooted_prefix more closely. > + if (target_sysroot_hdrs_suffix) So this should be "if (target_system_root)" - it needs to be sysrooted even if there is no sysroot headers suffix. > + { > + char *sysroot_no_trailing_dir_separator > + = xstrdup (target_sysroot_hdrs_suffix); > + size_t sysroot_len = strlen (target_sysroot_hdrs_suffix); And again this would use target_system_root. > + if (sysroot_len > 0 > + && target_sysroot_hdrs_suffix[sysroot_len - 1] == DIR_SEPARATOR) > + sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0'; Likewise. > + if (target_sysroot_suffix) > + prefix = concat (sysroot_no_trailing_dir_separator, > + target_sysroot_suffix, prefix, NULL); While this would use target_sysroot_hdrs_suffix. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-01-11 18:06 ` Joseph Myers @ 2019-01-14 14:09 ` Martin Liška 2019-01-15 17:45 ` Joseph Myers 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-14 14:09 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1344 bytes --] On 1/11/19 7:06 PM, Joseph Myers wrote: > On Fri, 11 Jan 2019, Martin LiÅ¡ka wrote: > >> +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix. */ > > Actually, it should be prepending target_system_root, but followed by > target_sysroot_hdrs_suffix rather than target_sysroot_suffix. That is, > this function should be following add_sysrooted_prefix more closely. > >> + if (target_sysroot_hdrs_suffix) > > So this should be "if (target_system_root)" - it needs to be sysrooted > even if there is no sysroot headers suffix. > >> + { >> + char *sysroot_no_trailing_dir_separator >> + = xstrdup (target_sysroot_hdrs_suffix); >> + size_t sysroot_len = strlen (target_sysroot_hdrs_suffix); > > And again this would use target_system_root. > >> + if (sysroot_len > 0 >> + && target_sysroot_hdrs_suffix[sysroot_len - 1] == DIR_SEPARATOR) >> + sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0'; > > Likewise. > >> + if (target_sysroot_suffix) >> + prefix = concat (sysroot_no_trailing_dir_separator, >> + target_sysroot_suffix, prefix, NULL); > > While this would use target_sysroot_hdrs_suffix. > Thanks for review, fixed that in updated version of the patch. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin [-- Attachment #2: 0001-Extend-locations-where-to-seach-for-Fortran-pre-incl.patch --] [-- Type: text/x-patch, Size: 6007 bytes --] From 8f60e280c40d60b1590d0eb41ce130582c7733a9 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Tue, 20 Nov 2018 15:09:16 +0100 Subject: [PATCH] Extend locations where to seach for Fortran pre-include. gcc/ChangeLog: 2019-01-14 Martin Liska <mliska@suse.cz> * Makefile.in: Set TOOL_INCLUDE_DIR and NATIVE_SYSTEM_HEADER_DIR for GCC driver. * config/gnu-user.h (TARGET_F951_OPTIONS): Add 'finclude%s/' as a new argument. * gcc.c (add_sysrooted_hdrs_prefix): New function. (path_prefix_reset): Move up in the source file. (find_fortran_preinclude_file): Make complex search for the fortran header files. --- gcc/Makefile.in | 4 +- gcc/config/gnu-user.h | 2 +- gcc/gcc.c | 103 ++++++++++++++++++++++++++++++++++-------- 3 files changed, 87 insertions(+), 22 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 2fa9083d1b3..095156bd537 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2172,7 +2172,9 @@ DRIVER_DEFINES = \ @TARGET_SYSTEM_ROOT_DEFINE@ \ $(VALGRIND_DRIVER_DEFINES) \ $(if $(SHLIB),$(if $(filter yes,@enable_shared@),-DENABLE_SHARED_LIBGCC)) \ - -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" + -DCONFIGURE_SPECS="\"@CONFIGURE_SPECS@\"" \ + -DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \ + -DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\" CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s) gcc.o: $(BASEVER) diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h index ba146921655..055a4f0afec 100644 --- a/gcc/config/gnu-user.h +++ b/gcc/config/gnu-user.h @@ -151,4 +151,4 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #undef TARGET_F951_OPTIONS #define TARGET_F951_OPTIONS "%{!nostdinc:\ - %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h)}" + %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}" diff --git a/gcc/gcc.c b/gcc/gcc.c index bcd04df1691..797ed36616f 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -2976,6 +2976,44 @@ add_sysrooted_prefix (struct path_prefix *pprefix, const char *prefix, add_prefix (pprefix, prefix, component, priority, require_machine_suffix, os_multilib); } + +/* Same as add_prefix, but prepending target_sysroot_hdrs_suffix to prefix. */ + +static void +add_sysrooted_hdrs_prefix (struct path_prefix *pprefix, const char *prefix, + const char *component, + /* enum prefix_priority */ int priority, + int require_machine_suffix, int os_multilib) +{ + if (!IS_ABSOLUTE_PATH (prefix)) + fatal_error (input_location, "system path %qs is not absolute", prefix); + + if (target_system_root) + { + char *sysroot_no_trailing_dir_separator = xstrdup (target_system_root); + size_t sysroot_len = strlen (target_system_root); + + if (sysroot_len > 0 + && target_system_root[sysroot_len - 1] == DIR_SEPARATOR) + sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0'; + + if (target_sysroot_hdrs_suffix) + prefix = concat (sysroot_no_trailing_dir_separator, + target_sysroot_hdrs_suffix, prefix, NULL); + else + prefix = concat (sysroot_no_trailing_dir_separator, prefix, NULL); + + free (sysroot_no_trailing_dir_separator); + + /* We have to override this because GCC's notion of sysroot + moves along with GCC. */ + component = "GCC"; + } + + add_prefix (pprefix, prefix, component, priority, + require_machine_suffix, os_multilib); +} + \f /* Execute the command specified by the arguments on the current line of spec. When using pipes, this includes several piped-together commands @@ -9896,20 +9934,61 @@ debug_level_greater_than_spec_func (int argc, const char **argv) return NULL; } -/* The function takes 2 arguments: OPTION name and file name. +static void +path_prefix_reset (path_prefix *prefix) +{ + struct prefix_list *iter, *next; + iter = prefix->plist; + while (iter) + { + next = iter->next; + free (const_cast <char *> (iter->prefix)); + XDELETE (iter); + iter = next; + } + prefix->plist = 0; + prefix->max_len = 0; +} + +/* The function takes 3 arguments: OPTION name, file name and location + where we search for Fortran modules. When the FILE is found by find_file, return OPTION=path_to_file. */ static const char * find_fortran_preinclude_file (int argc, const char **argv) { - if (argc != 2) + char *result = NULL; + if (argc != 3) return NULL; + struct path_prefix prefixes = { 0, 0, "preinclude" }; + + /* Search first for 'finclude' folder location for a header file + installed by the compiler (similar to omp_lib.h). */ + add_prefix (&prefixes, argv[2], NULL, 0, 0, false); +#ifdef TOOL_INCLUDE_DIR + /* Then search: <prefix>/<target>/<include>/finclude */ + add_prefix (&prefixes, TOOL_INCLUDE_DIR "/finclude/", + NULL, 0, 0, false); +#endif +#ifdef NATIVE_SYSTEM_HEADER_DIR + /* Then search: <sysroot>/usr/include/finclude/<multilib> */ + add_sysrooted_hdrs_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR "/finclude/", + NULL, 0, 0, false); +#endif + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); if (path != NULL) - return concat (argv[0], path, NULL); + result = concat (argv[0], path, NULL); + else + { + path = find_a_file (&prefixes, argv[1], R_OK, true); + if (path != NULL) + result = concat (argv[0], path, NULL); + } - return NULL; + path_prefix_reset (&prefixes); + return result; } @@ -9961,22 +10040,6 @@ convert_white_space (char *orig) return orig; } -static void -path_prefix_reset (path_prefix *prefix) -{ - struct prefix_list *iter, *next; - iter = prefix->plist; - while (iter) - { - next = iter->next; - free (const_cast <char *> (iter->prefix)); - XDELETE (iter); - iter = next; - } - prefix->plist = 0; - prefix->max_len = 0; -} - /* Restore all state within gcc.c to the initial state, so that the driver code can be safely re-run in-process. -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include. 2019-01-14 14:09 ` Martin Liška @ 2019-01-15 17:45 ` Joseph Myers 2019-01-16 9:42 ` Fortran vector math header Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-01-15 17:45 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 277 bytes --] On Mon, 14 Jan 2019, Martin LiÅ¡ka wrote: > Thanks for review, fixed that in updated version of the patch. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? This patch is OK. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Fortran vector math header 2019-01-15 17:45 ` Joseph Myers @ 2019-01-16 9:42 ` Martin Liška 2019-01-16 12:39 ` Jakub Jelinek 2019-01-16 13:59 ` Joseph Myers 0 siblings, 2 replies; 94+ messages in thread From: Martin Liška @ 2019-01-16 9:42 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 1/15/19 6:45 PM, Joseph Myers wrote: > On Mon, 14 Jan 2019, Martin LiÅ¡ka wrote: > >> Thanks for review, fixed that in updated version of the patch. >> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> >> Ready to be installed? > > This patch is OK. > Great, thank you very much for advises you provided. Now we should add the header file into glibc, I kicked a discussion here: https://sourceware.org/ml/libc-help/2018-11/msg00015.html Joseph: will you please help with a patch for glibc? I'm also planning to document the header file in gfortran so that other compiler can leverage that. Thanks, Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-16 9:42 ` Fortran vector math header Martin Liška @ 2019-01-16 12:39 ` Jakub Jelinek 2019-01-16 14:05 ` Joseph Myers 2019-01-16 13:59 ` Joseph Myers 1 sibling, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-16 12:39 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, Jan 16, 2019 at 10:42:13AM +0100, Martin LiÅ¡ka wrote: > On 1/15/19 6:45 PM, Joseph Myers wrote: > > On Mon, 14 Jan 2019, Martin LiÅ¡ka wrote: > > > >> Thanks for review, fixed that in updated version of the patch. > >> > >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > >> > >> Ready to be installed? > > > > This patch is OK. > > > > Great, thank you very much for advises you provided. > > Now we should add the header file into glibc, I kicked a discussion here: > https://sourceware.org/ml/libc-help/2018-11/msg00015.html > > Joseph: will you please help with a patch for glibc? > > I'm also planning to document the header file in gfortran so that other > compiler can leverage that. I'd like to raise a concern I have. On IRC you've mentioned you'd like to see that header in /usr/include/finclude/{,32/}math-vector-fortran.h (with 32/ header being empty) which looks problematic to me. The 32/ in there is the compiler's multilib suffix, which is though dependent on how exactly one configures the compiler. On x86_64-linux-gnu, one can either build (native) x86_64-pc-linux-gnu compiler that defaults to -m64, supports -m32 and uses . and 32/ multilibs for those, or one can build also native i686-pc-linux-gnu compiler (ideally with 32-bit binutils too) that only supports -m32 and uses . multilib for the 32-bit. If glibc installs the above, then if one uses the 32-bit i686-linux gfortran, it will misbehave, as it will think glibc.i686 provides the math-vector.h entrypoints when it doesn't. Right now no other target supports them, but if say powerpc64-linux got them, there one can build powerpc-linux gcc that supports -m32 and -m64 with . and 64/ multilib subdirs, or powerpc64-linux gcc that supports -m64 and -m32 with . and 32/ multilib subdirs. So, what would /usr/include/finclude/math-vector-fortran.h stand for in that case (again, assuming the entry points are implemented in one of the multilibs only). In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or defined(__ILP64__) and similar, but in these headers we can't, as no preprocessing is happening. So, I think we need more multi-arch like setup for these locations, say /usr/include/finclude/<target-triplet>{,<multisubdir>/}/ or similar which would be less ambiguous. Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-16 12:39 ` Jakub Jelinek @ 2019-01-16 14:05 ` Joseph Myers 2019-01-16 17:42 ` Joseph Myers 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-01-16 14:05 UTC (permalink / raw) To: Jakub Jelinek Cc: Martin Liška, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, 16 Jan 2019, Jakub Jelinek wrote: > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or > defined(__ILP64__) and similar, but in these headers we can't, as no > preprocessing is happening. (With such preprocessing, the mechanism glibc uses for gnu/stubs.h and gnu/lib-names.h could be used.) > So, I think we need more multi-arch like setup for these locations, say > /usr/include/finclude/<target-triplet>{,<multisubdir>/}/ > or similar which would be less ambiguous. My understanding from the previous discussions is that with --enable-multiarch, these files will (or should) use multiarch names - but we don't have any support for using multiarch names for only some files in a toolchain. (Which leads to suggestions like this one for having a target triplet in there which isn't actually a canonical multiarch name.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-16 14:05 ` Joseph Myers @ 2019-01-16 17:42 ` Joseph Myers 2019-01-16 18:04 ` Jakub Jelinek 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-01-16 17:42 UTC (permalink / raw) To: Jakub Jelinek Cc: Martin Liška, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, 16 Jan 2019, Joseph Myers wrote: > On Wed, 16 Jan 2019, Jakub Jelinek wrote: > > > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or > > defined(__ILP64__) and similar, but in these headers we can't, as no > > preprocessing is happening. > > (With such preprocessing, the mechanism glibc uses for gnu/stubs.h and > gnu/lib-names.h could be used.) And I guess this leads to the question: Since the Fortran front end has preprocessing support, could it be made to run the preprocessor on such preincluded headers? If it could, the driver code could be changed to avoid looking in multilib locations for this header, and that glibc machinery could be used. (It would be necessary to resolve the FIXME in fortran/cpp.c so that architecture-specific macros get predefined; __x86_64__, __LP64__ and __ILP32__ all need to be properly defined or not defined for this mechanism to work for x86.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-16 17:42 ` Joseph Myers @ 2019-01-16 18:04 ` Jakub Jelinek 2019-01-16 20:35 ` Joseph Myers 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-16 18:04 UTC (permalink / raw) To: Joseph Myers Cc: Martin Liška, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, Jan 16, 2019 at 05:42:06PM +0000, Joseph Myers wrote: > On Wed, 16 Jan 2019, Joseph Myers wrote: > > > On Wed, 16 Jan 2019, Jakub Jelinek wrote: > > > > > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or > > > defined(__ILP64__) and similar, but in these headers we can't, as no > > > preprocessing is happening. > > > > (With such preprocessing, the mechanism glibc uses for gnu/stubs.h and > > gnu/lib-names.h could be used.) > > And I guess this leads to the question: > > Since the Fortran front end has preprocessing support, could it be made to > run the preprocessor on such preincluded headers? If it could, the driver > code could be changed to avoid looking in multilib locations for this > header, and that glibc machinery could be used. (It would be necessary to > resolve the FIXME in fortran/cpp.c so that architecture-specific macros > get predefined; __x86_64__, __LP64__ and __ILP32__ all need to be properly > defined or not defined for this mechanism to work for x86.) Well, it has, but extremely inefficient one. Basically, it preprocesses everything into a temporary file and then parses that temporary file instead of the original input. Doing such preprocessing for this tiny header file that is now going to be included in every fortran compilation would slow it down, require the driver to tell where to create the temporary file etc. Perhaps easier would be to add optional if clause to the !GCC$ builtin with constant expression argument which if present and evaluates to .false. would tell us to ignore the attribute. Or, add !GCC$ if/else/end if which would act like preprocessing conditionals or something similar. Not really sure one can query in Fortran what the multilib is some way (say look at size of a pointer etc.). Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-16 18:04 ` Jakub Jelinek @ 2019-01-16 20:35 ` Joseph Myers 2019-01-18 8:18 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-01-16 20:35 UTC (permalink / raw) To: Jakub Jelinek Cc: Martin Liška, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Wed, 16 Jan 2019, Jakub Jelinek wrote: > Perhaps easier would be to add optional if clause to the !GCC$ builtin > with constant expression argument which if present and evaluates to .false. > would tell us to ignore the attribute. Or, add !GCC$ if/else/end if which > would act like preprocessing conditionals or something similar. > Not really sure one can query in Fortran what the multilib is some way (say > look at size of a pointer etc.). If something like that is done, I'd suggest doing it in a form which allows each multilib's information about glibc functions to go in a separate generated header (so having !GCC$ include or similar to include a per-multilib file, under appropriate conditionals). Otherwise you need to bring back logic in glibc to make a compiler building glibc for one multilib use appropriate -D and -U options to get its C headers to define things appropriately for another multilib, so that the all-multilib Fortran header can be generated in a single glibc build. (Like the old logic for generating bits/syscall.h that was removed in commits 2dba5ce7b8115d6a2789bf279892263621088e74 and ee17d4e99af9e49378217209d3708053ef148032.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-16 20:35 ` Joseph Myers @ 2019-01-18 8:18 ` Martin Liška 2019-01-18 8:40 ` Jakub Jelinek 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-18 8:18 UTC (permalink / raw) To: Joseph Myers, Jakub Jelinek Cc: Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 1/16/19 9:35 PM, Joseph Myers wrote: > On Wed, 16 Jan 2019, Jakub Jelinek wrote: > >> Perhaps easier would be to add optional if clause to the !GCC$ builtin >> with constant expression argument which if present and evaluates to .false. >> would tell us to ignore the attribute. Or, add !GCC$ if/else/end if which >> would act like preprocessing conditionals or something similar. >> Not really sure one can query in Fortran what the multilib is some way (say >> look at size of a pointer etc.). > > If something like that is done, I'd suggest doing it in a form which > allows each multilib's information about glibc functions to go in a > separate generated header (so having !GCC$ include or similar to include a > per-multilib file, under appropriate conditionals). Otherwise you need to > bring back logic in glibc to make a compiler building glibc for one > multilib use appropriate -D and -U options to get its C headers to define > things appropriately for another multilib, so that the all-multilib > Fortran header can be generated in a single glibc build. (Like the old > logic for generating bits/syscall.h that was removed in commits > 2dba5ce7b8115d6a2789bf279892263621088e74 and > ee17d4e99af9e49378217209d3708053ef148032.) > Hi. 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) Thoughts? Thanks, Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-18 8:18 ` Martin Liška @ 2019-01-18 8:40 ` Jakub Jelinek 2019-01-21 7:47 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-18 8:40 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches 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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-18 8:40 ` Jakub Jelinek @ 2019-01-21 7:47 ` Martin Liška 2019-01-21 7:58 ` Jakub Jelinek 2019-01-21 14:25 ` Joseph Myers 0 siblings, 2 replies; 94+ messages in thread From: Martin Liška @ 2019-01-21 7:47 UTC (permalink / raw) To: Jakub Jelinek Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 2297 bytes --] 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 [-- Attachment #2: 0001-Support-if-statement-in-GCC-builtin-directive.patch --] [-- Type: text/x-patch, Size: 1351 bytes --] From d21476c2223e6e5d12a949b4e2ba26417e37852b Mon Sep 17 00:00:00 2001 From: marxin <mliska@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 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-21 7:47 ` Martin Liška @ 2019-01-21 7:58 ` Jakub Jelinek 2019-01-21 9:09 ` Martin Liška 2019-01-21 14:25 ` Joseph Myers 1 sibling, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-21 7:58 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Mon, Jan 21, 2019 at 08:47:42AM +0100, Martin LiÅ¡ka wrote: > 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; __LP64__ macro is defined if: if (TYPE_PRECISION (long_integer_type_node) == 64 && POINTER_SIZE == 64 && TYPE_PRECISION (integer_type_node) == 32) All of these are middle-end types or target macros, so you should be able to test that in the Fortran FE too. > + } > + else if (strcmp (target, "ilp32") == 0) > + { > + if (size_of_long != 4) > + return MATCH_YES; For this obviously as well. > + } > + else > + return MATCH_ERROR; > + } > + > if (gfc_vectorized_builtins == NULL) > gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-21 7:58 ` Jakub Jelinek @ 2019-01-21 9:09 ` Martin Liška 2019-01-21 9:19 ` Jakub Jelinek 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-21 9:09 UTC (permalink / raw) To: Jakub Jelinek Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1672 bytes --] On 1/21/19 8:58 AM, Jakub Jelinek wrote: > On Mon, Jan 21, 2019 at 08:47:42AM +0100, Martin LiÅ¡ka wrote: >> 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; > > __LP64__ macro is defined if: > if (TYPE_PRECISION (long_integer_type_node) == 64 > && POINTER_SIZE == 64 > && TYPE_PRECISION (integer_type_node) == 32) > All of these are middle-end types or target macros, so you should be able to > test that in the Fortran FE too. > >> + } >> + else if (strcmp (target, "ilp32") == 0) >> + { >> + if (size_of_long != 4) >> + return MATCH_YES; > > For this obviously as well. > >> + } >> + else >> + return MATCH_ERROR; >> + } >> + >> if (gfc_vectorized_builtins == NULL) >> gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); > > Jakub > Sure, this is patch I've been currently testing. Thoughts? Martin [-- Attachment #2: 0001-Support-if-statement-in-GCC-builtin-directive.patch --] [-- Type: text/x-patch, Size: 3690 bytes --] From 1520b49856a1b39358602c4105dda3891cb166ff Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Mon, 21 Jan 2019 08:46:06 +0100 Subject: [PATCH] Support if statement in !GCC$ builtin directive. gcc/fortran/ChangeLog: 2019-01-21 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): Support filtering for 'lp64' and 'ilp32'. gcc/testsuite/ChangeLog: 2019-01-21 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-7.f90: New test. * gfortran.dg/simd-builtins-7.h: New test. --- gcc/fortran/decl.c | 22 +++++++++++++++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 21 ++++++++++++++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.h | 2 ++ 3 files changed, 45 insertions(+) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 3314e176881..d68ab8e7931 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -28,6 +28,7 @@ along with GCC; see the file COPYING3. If not see #include "match.h" #include "parse.h" #include "constructor.h" +#include "target.h" /* Macros to access allocate memory for gfc_data_variable, gfc_data_value and gfc_data. */ @@ -11351,6 +11352,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 +11363,26 @@ gfc_match_gcc_builtin (void) else if (gfc_match (" ( inbranch ) ") == MATCH_YES) clause = SIMD_INBRANCH; + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) + { + if (strcmp (target, "lp64") == 0) + { + if (TYPE_PRECISION (long_integer_type_node) != 64 + || POINTER_SIZE != 64 + || TYPE_PRECISION (integer_type_node) != 32) + return MATCH_YES; + } + else if (strcmp (target, "ilp32") == 0) + { + if (TYPE_PRECISION (long_integer_type_node) != 32 + || POINTER_SIZE != 32 + || TYPE_PRECISION (integer_type_node) != 32) + return MATCH_YES; + } + else + return MATCH_ERROR; + } + if (gfc_vectorized_builtins == NULL) gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 new file mode 100644 index 00000000000..6445733d288 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 @@ -0,0 +1,21 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + ! this should be using simd clone + y4 = sin(x4) + print *, y4 + + ! this should not be using simd clone + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ia32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ia32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h new file mode 100644 index 00000000000..1617e1086d0 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h @@ -0,0 +1,2 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if(lp64) +!GCC$ builtin (sinf) attributes simd (notinbranch) if(ilp32) -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-21 9:09 ` Martin Liška @ 2019-01-21 9:19 ` Jakub Jelinek 2019-01-21 9:36 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-21 9:19 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Mon, Jan 21, 2019 at 10:09:01AM +0100, Martin LiÅ¡ka wrote: > @@ -11351,6 +11352,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 +11363,26 @@ gfc_match_gcc_builtin (void) > else if (gfc_match (" ( inbranch ) ") == MATCH_YES) > clause = SIMD_INBRANCH; > > + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) > + { > + if (strcmp (target, "lp64") == 0) > + { > + if (TYPE_PRECISION (long_integer_type_node) != 64 > + || POINTER_SIZE != 64 > + || TYPE_PRECISION (integer_type_node) != 32) > + return MATCH_YES; > + } > + else if (strcmp (target, "ilp32") == 0) > + { > + if (TYPE_PRECISION (long_integer_type_node) != 32 > + || POINTER_SIZE != 32 > + || TYPE_PRECISION (integer_type_node) != 32) > + return MATCH_YES; > + } > + else > + return MATCH_ERROR; > + } You should adjust the syntax above the function too. And you need here buy-in from glibc folks. > + > if (gfc_vectorized_builtins == NULL) > gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); > > diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 > new file mode 100644 > index 00000000000..6445733d288 > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 > @@ -0,0 +1,21 @@ > +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } > +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } > + > +program test_overloaded_intrinsic > + real(4) :: x4(3200), y4(3200) > + real(8) :: x8(3200), y8(3200) > + > + ! this should be using simd clone > + y4 = sin(x4) > + print *, y4 > + > + ! this should not be using simd clone The above 2 comments are misleading, they only match what ia32 does. > + y4 = sin(x8) > + print *, y8 > +end > + > +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ia32 } } } */ > +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ia32 } } } */ Perhaps use ilp32 instead of ia32? Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-21 9:19 ` Jakub Jelinek @ 2019-01-21 9:36 ` Martin Liška 2019-01-21 9:40 ` Jakub Jelinek 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-21 9:36 UTC (permalink / raw) To: Jakub Jelinek Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 2452 bytes --] On 1/21/19 10:19 AM, Jakub Jelinek wrote: > On Mon, Jan 21, 2019 at 10:09:01AM +0100, Martin LiÅ¡ka wrote: >> @@ -11351,6 +11352,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 +11363,26 @@ gfc_match_gcc_builtin (void) >> else if (gfc_match (" ( inbranch ) ") == MATCH_YES) >> clause = SIMD_INBRANCH; >> >> + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) >> + { >> + if (strcmp (target, "lp64") == 0) >> + { >> + if (TYPE_PRECISION (long_integer_type_node) != 64 >> + || POINTER_SIZE != 64 >> + || TYPE_PRECISION (integer_type_node) != 32) >> + return MATCH_YES; >> + } >> + else if (strcmp (target, "ilp32") == 0) >> + { >> + if (TYPE_PRECISION (long_integer_type_node) != 32 >> + || POINTER_SIZE != 32 >> + || TYPE_PRECISION (integer_type_node) != 32) >> + return MATCH_YES; >> + } >> + else >> + return MATCH_ERROR; >> + } > > You should adjust the syntax above the function too. > And you need here buy-in from glibc folks. >> + >> if (gfc_vectorized_builtins == NULL) >> gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); >> >> diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 >> new file mode 100644 >> index 00000000000..6445733d288 >> --- /dev/null >> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 >> @@ -0,0 +1,21 @@ >> +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } >> +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } >> + >> +program test_overloaded_intrinsic >> + real(4) :: x4(3200), y4(3200) >> + real(8) :: x8(3200), y8(3200) >> + >> + ! this should be using simd clone >> + y4 = sin(x4) >> + print *, y4 >> + >> + ! this should not be using simd clone > > The above 2 comments are misleading, they only match what ia32 does. > >> + y4 = sin(x8) >> + print *, y8 >> +end >> + >> +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ia32 } } } */ >> +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ia32 } } } */ > > Perhaps use ilp32 instead of ia32? > > Jakub > Thanks for review, I'm attaching updated patch. Martin [-- Attachment #2: 0001-Support-if-statement-in-GCC-builtin-directive.patch --] [-- Type: text/x-patch, Size: 4112 bytes --] From f8901f176f7832591dd9702da681859b9f3ddf38 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Mon, 21 Jan 2019 08:46:06 +0100 Subject: [PATCH] Support if statement in !GCC$ builtin directive. gcc/fortran/ChangeLog: 2019-01-21 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): Support filtering for 'lp64' and 'ilp32'. gcc/testsuite/ChangeLog: 2019-01-21 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-7.f90: New test. * gfortran.dg/simd-builtins-7.h: New test. --- gcc/fortran/decl.c | 28 ++++++++++++++++++- gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 19 +++++++++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.h | 2 ++ 3 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 3314e176881..3e2e9adcb4a 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -28,6 +28,7 @@ along with GCC; see the file COPYING3. If not see #include "match.h" #include "parse.h" #include "constructor.h" +#include "target.h" /* Macros to access allocate memory for gfc_data_variable, gfc_data_value and gfc_data. */ @@ -11338,7 +11339,7 @@ gfc_match_gcc_unroll (void) return MATCH_ERROR; } -/* Match a !GCC$ builtin (b) attributes simd flags form: +/* Match a !GCC$ builtin (b) attributes simd if(target) flags form: The parameter b is name of a middle-end built-in. Flags are one of: @@ -11346,11 +11347,16 @@ gfc_match_gcc_unroll (void) - inbranch - notinbranch + Target must be one of: + - lp64 + - ilp32 + When we come here, we have already matched the !GCC$ builtin string. */ 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 +11367,26 @@ gfc_match_gcc_builtin (void) else if (gfc_match (" ( inbranch ) ") == MATCH_YES) clause = SIMD_INBRANCH; + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) + { + if (strcmp (target, "lp64") == 0) + { + if (TYPE_PRECISION (long_integer_type_node) != 64 + || POINTER_SIZE != 64 + || TYPE_PRECISION (integer_type_node) != 32) + return MATCH_YES; + } + else if (strcmp (target, "ilp32") == 0) + { + if (TYPE_PRECISION (long_integer_type_node) != 32 + || POINTER_SIZE != 32 + || TYPE_PRECISION (integer_type_node) != 32) + return MATCH_YES; + } + else + return MATCH_ERROR; + } + if (gfc_vectorized_builtins == NULL) gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 new file mode 100644 index 00000000000..c3ce5543779 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + y4 = sin(x4) + print *, y4 + + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h new file mode 100644 index 00000000000..1617e1086d0 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h @@ -0,0 +1,2 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if(lp64) +!GCC$ builtin (sinf) attributes simd (notinbranch) if(ilp32) -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-21 9:36 ` Martin Liška @ 2019-01-21 9:40 ` Jakub Jelinek 0 siblings, 0 replies; 94+ messages in thread From: Jakub Jelinek @ 2019-01-21 9:40 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Mon, Jan 21, 2019 at 10:36:20AM +0100, Martin LiÅ¡ka wrote: > @@ -11338,7 +11339,7 @@ gfc_match_gcc_unroll (void) > return MATCH_ERROR; > } > > -/* Match a !GCC$ builtin (b) attributes simd flags form: > +/* Match a !GCC$ builtin (b) attributes simd if(target) flags form: > > The parameter b is name of a middle-end built-in. > Flags are one of: > @@ -11346,11 +11347,16 @@ gfc_match_gcc_unroll (void) > - inbranch > - notinbranch > > + Target must be one of: > + - lp64 > + - ilp32 > + Not exactly correct. if(target) is optional, not mandatory, and, if it appears, must appear after flags. flags is also incorrect, because it is either nothing, or (inbranch), or (notinbranch), while the function comment suggests that it is inbranch or notinbranch. Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-21 7:47 ` Martin Liška 2019-01-21 7:58 ` Jakub Jelinek @ 2019-01-21 14:25 ` Joseph Myers 2019-01-22 11:01 ` Martin Liška 1 sibling, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-01-21 14:25 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 539 bytes --] On Mon, 21 Jan 2019, Martin LiÅ¡ka wrote: > I like the if('lp64'), if('ilp32') approach and I'm sending patch > candidate for that. Would it be accepted by glibc folks? Since glibc supports libmvec for x86_64, both 64-bit and x32, but not for 32-bit x86, those particular conditionals are insufficient because they can't distinguish x32 (libmvec supported) from 32-bit x86 (libmvec not supported); you need some architecture-specific conditional that can be used in the Fortran header. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-21 14:25 ` Joseph Myers @ 2019-01-22 11:01 ` Martin Liška 2019-01-22 11:15 ` Jakub Jelinek 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-22 11:01 UTC (permalink / raw) To: Joseph Myers Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 1031 bytes --] On 1/21/19 3:25 PM, Joseph Myers wrote: > On Mon, 21 Jan 2019, Martin LiÅ¡ka wrote: > >> I like the if('lp64'), if('ilp32') approach and I'm sending patch >> candidate for that. Would it be accepted by glibc folks? > > Since glibc supports libmvec for x86_64, both 64-bit and x32, but not for > 32-bit x86, those particular conditionals are insufficient because they > can't distinguish x32 (libmvec supported) from 32-bit x86 (libmvec not > supported); you need some architecture-specific conditional that can be > used in the Fortran header. > Hello. I discussed with Jakub possibility of generating canonical triples that will be then used in Fortran FE to filter the 'GCC$ builtin' directives. However, the approach bring some possibilities and thus I enhanced the previous version of patch to catch x32 ABI (I call it lp64ilp32), similarly to Debian: https://wiki.debian.org/Multiarch/Tuples If I'm correct, such ABI can be provided on i386, aarch64 and mips64 targets. Will the suggested approach work? Martin [-- Attachment #2: 0001-Support-if-statement-in-GCC-builtin-directive.patch --] [-- Type: text/x-patch, Size: 8289 bytes --] From d585da8b477ac13be1941d290d7e2b8c7b5bf96a Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Mon, 21 Jan 2019 08:46:06 +0100 Subject: [PATCH] Support if statement in !GCC$ builtin directive. gcc/fortran/ChangeLog: 2019-01-21 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): Support filtering for 'lp64' and 'ilp32'. gcc/testsuite/ChangeLog: 2019-01-21 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-7.f90: New test. * gfortran.dg/simd-builtins-7.h: New test. --- gcc/config/i386/i386.c | 15 ++++++++ gcc/coretypes.h | 9 +++++ gcc/doc/tm.texi | 4 +++ gcc/doc/tm.texi.in | 2 ++ gcc/fortran/decl.c | 35 +++++++++++++++++-- gcc/target.def | 6 ++++ gcc/targhooks.c | 6 ++++ gcc/targhooks.h | 1 + gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 19 ++++++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.h | 2 ++ 10 files changed, 96 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 8abff99cc62..0167b4bd3e5 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -29573,6 +29573,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t cum_v, tree type) cum->warn_empty = false; } +static target_abi_type +ix86_get_abi_type (void) +{ + if (!(TARGET_64BIT_P (ix86_isa_flags ))) + return ABI_ILP32; + else if (TARGET_X32_P (ix86_isa_flags)) + return ABI_LP64ILP32; + else + return ABI_LP64; +} + /* Compute the alignment for a variable for Intel MCU psABI. TYPE is the data type, and ALIGN is the alignment that the object would ordinarily have. */ @@ -51900,6 +51911,10 @@ ix86_run_selftests (void) #undef TARGET_WARN_PARAMETER_PASSING_ABI #define TARGET_WARN_PARAMETER_PASSING_ABI ix86_warn_parameter_passing_abi +#undef TARGET_GET_ABI_TYPE +#define TARGET_GET_ABI_TYPE \ +ix86_get_abi_type + #if CHECKING_P #undef TARGET_RUN_TARGET_SELFTESTS #define TARGET_RUN_TARGET_SELFTESTS selftest::ix86_run_selftests diff --git a/gcc/coretypes.h b/gcc/coretypes.h index 2f6b8599d7c..ba3fe9c2e7c 100644 --- a/gcc/coretypes.h +++ b/gcc/coretypes.h @@ -290,6 +290,15 @@ enum warn_strict_overflow_code WARN_STRICT_OVERFLOW_MAGNITUDE = 5 }; +/* Enum values for target ABI types. */ +enum target_abi_type +{ + ABI_LP64, + ABI_ILP32, + ABI_LP64ILP32, + ABI_OTHER +}; + /* The type of an alias set. Code currently assumes that variables of this type can take the values 0 (the alias set which aliases everything) and -1 (sometimes indicating that the alias set is diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index 4347f89cd2f..7887217f10a 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -1931,6 +1931,10 @@ superset of all other ABIs. @var{call_1} must always be a call insn, call_2 may be NULL or a call insn. @end deftypefn +@deftypefn {Target Hook} {enum target_abi_type} TARGET_GET_ABI_TYPE (void) +This hooks returns type of target ABI (LP64, ILP32, LP64ILP32 or other). +@end deftypefn + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index 41a6cb11cb0..b36a2064290 100644 --- a/gcc/doc/tm.texi.in +++ b/gcc/doc/tm.texi.in @@ -1711,6 +1711,8 @@ of @code{CALL_USED_REGISTERS}. @hook TARGET_RETURN_CALL_WITH_MAX_CLOBBERS +@hook TARGET_GET_ABI_TYPE + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 3314e176881..f4efc3140e3 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -28,6 +28,8 @@ along with GCC; see the file COPYING3. If not see #include "match.h" #include "parse.h" #include "constructor.h" +#include "target.h" +#include "xregex.h" /* Macros to access allocate memory for gfc_data_variable, gfc_data_value and gfc_data. */ @@ -11338,19 +11340,24 @@ gfc_match_gcc_unroll (void) return MATCH_ERROR; } -/* Match a !GCC$ builtin (b) attributes simd flags form: +/* Match a !GCC$ builtin (b) attributes simd flags if(target) form: The parameter b is name of a middle-end built-in. - Flags are one of: - - (empty) + FLAGS is optional and must be one of: - inbranch - notinbranch + IF(target) is optional and TARGET must be one of: + - lp64 + - ilp32 + - lp64ilp32 + When we come here, we have already matched the !GCC$ builtin string. */ 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 +11368,28 @@ gfc_match_gcc_builtin (void) else if (gfc_match (" ( inbranch ) ") == MATCH_YES) clause = SIMD_INBRANCH; + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) + { + enum target_abi_type abi = targetm.get_abi_type (); + if (strcmp (target, "lp64") == 0) + { + if (abi != ABI_LP64) + return MATCH_YES; + } + else if (strcmp (target, "ilp32") == 0) + { + if (abi != ABI_ILP32) + return MATCH_YES; + } + else if (strcmp (target, "lp64ilp32") == 0) + { + if (abi != ABI_LP64ILP32) + return MATCH_YES; + } + else + return MATCH_ERROR; + } + if (gfc_vectorized_builtins == NULL) gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); diff --git a/gcc/target.def b/gcc/target.def index 05c9cc1da28..d29d1324833 100644 --- a/gcc/target.def +++ b/gcc/target.def @@ -5791,6 +5791,12 @@ call_2 may be NULL or a call insn.", rtx_insn *, (rtx_insn *call_1, rtx_insn *call_2), NULL) +DEFHOOK +(get_abi_type, + "This hooks returns type of target ABI (LP64, ILP32, LP64ILP32 or other).", + enum target_abi_type, (void), + NULL) + DEFHOOK (remove_extra_call_preserved_regs, "This hook removes registers from the set of call-clobbered registers\n\ diff --git a/gcc/targhooks.c b/gcc/targhooks.c index 529590b55df..37a04ff1012 100644 --- a/gcc/targhooks.c +++ b/gcc/targhooks.c @@ -2379,4 +2379,10 @@ default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *) { } +enum target_abi_type +default_get_abi_type (void) +{ + return ABI_OTHER; +} + #include "gt-targhooks.h" diff --git a/gcc/targhooks.h b/gcc/targhooks.h index 59436278dcf..5494c5701de 100644 --- a/gcc/targhooks.h +++ b/gcc/targhooks.h @@ -286,5 +286,6 @@ extern bool speculation_safe_value_not_needed (bool); extern rtx default_speculation_safe_value (machine_mode, rtx, rtx, rtx); extern void default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *); +extern enum target_abi_type default_get_abi_type (void); #endif /* GCC_TARGHOOKS_H */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 new file mode 100644 index 00000000000..c3ce5543779 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + y4 = sin(x4) + print *, y4 + + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h new file mode 100644 index 00000000000..1617e1086d0 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h @@ -0,0 +1,2 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if(lp64) +!GCC$ builtin (sinf) attributes simd (notinbranch) if(ilp32) -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-22 11:01 ` Martin Liška @ 2019-01-22 11:15 ` Jakub Jelinek 2019-01-22 12:18 ` Richard Biener 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-22 11:15 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On Tue, Jan 22, 2019 at 12:01:29PM +0100, Martin LiÅ¡ka wrote: > I discussed with Jakub possibility of generating canonical triples that will > be then used in Fortran FE to filter the 'GCC$ builtin' directives. However, > the approach bring some possibilities and thus I enhanced the previous > version of patch to catch x32 ABI (I call it lp64ilp32), similarly to Debian: lp64ilp32 makes no sense. long and pointer are 64-bit and integer, long and pointer are 32-bit? That is impossible. Both ia32 and x32 are ilp32. What I was suggesting is either use normalized tuples like Debian multi-arch, but as it would be exposed to users on all targets, it would need to be something done for all targets. My suggestion was start with the canonical triplet and adjust it for multilibs in a target hook if needed. So, e.g. in config/i386, it would replace the first part of the triplet with x86_64 if not ia32, if ia32 with i386, and append x32 to the triplet if x32. For e.g. rs6000, it could modify the first part of the triplet to powerpc{,64}{,le} depending on endianity and if it is 64-bit ABI or not. For aarch64 it would modify the first part of the triplet to aarch64{,be} depending on endianity, and append _ilp32 if 32-bit ABI, etc. Or instead just come up with target specific strings to determine the ABI, say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000 etc. Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-22 11:15 ` Jakub Jelinek @ 2019-01-22 12:18 ` Richard Biener 2019-01-23 1:18 ` Joseph Myers 2019-01-23 22:53 ` Steve Ellcey 0 siblings, 2 replies; 94+ messages in thread From: Richard Biener @ 2019-01-22 12:18 UTC (permalink / raw) To: Jakub Jelinek Cc: Martin Liška, Joseph Myers, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Tue, Jan 22, 2019 at 12:15 PM Jakub Jelinek <jakub@redhat.com> wrote: > > On Tue, Jan 22, 2019 at 12:01:29PM +0100, Martin Liška wrote: > > I discussed with Jakub possibility of generating canonical triples that will > > be then used in Fortran FE to filter the 'GCC$ builtin' directives. However, > > the approach bring some possibilities and thus I enhanced the previous > > version of patch to catch x32 ABI (I call it lp64ilp32), similarly to Debian: > > lp64ilp32 makes no sense. long and pointer are 64-bit and integer, long and > pointer are 32-bit? That is impossible. Both ia32 and x32 are ilp32. > > What I was suggesting is either use normalized tuples like Debian > multi-arch, but as it would be exposed to users on all targets, it would > need to be something done for all targets. My suggestion was start with > the canonical triplet and adjust it for multilibs in a target hook if > needed. So, e.g. in config/i386, it would replace the first part of the > triplet with x86_64 if not ia32, if ia32 with i386, and append x32 to the > triplet if x32. For e.g. rs6000, it could modify the first part of the > triplet to powerpc{,64}{,le} depending on endianity and if it is 64-bit ABI > or not. For aarch64 it would modify the first part of the triplet to > aarch64{,be} depending on endianity, and append _ilp32 if 32-bit ABI, etc. > > Or instead just come up with target specific strings to determine the ABI, > say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000 > etc. Yeah, I would even suggest to use a target hook multilib_ABI_active_p (const char *) for this ... (where the hook should diagnose unknown multilib specifiers). Richard. > Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-22 12:18 ` Richard Biener @ 2019-01-23 1:18 ` Joseph Myers 2019-01-24 14:59 ` Martin Liška 2019-01-23 22:53 ` Steve Ellcey 1 sibling, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-01-23 1:18 UTC (permalink / raw) To: Richard Biener Cc: Jakub Jelinek, Martin Liška, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Tue, 22 Jan 2019, Richard Biener wrote: > > Or instead just come up with target specific strings to determine the ABI, > > say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000 > > etc. > > Yeah, I would even suggest to use a target hook multilib_ABI_active_p > (const char *) > for this ... (where the hook should diagnose unknown multilib specifiers). A header from a newer glibc version, supporting new ABIs, should still be usable with an older GCC version, not supporting some of those ABIs. Thus I don't think the hook should diagnose unknown specifiers from such a header. (This is just like how a C header can test new predefined macros without an old GCC complaining it doesn't know what would define those macros.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-23 1:18 ` Joseph Myers @ 2019-01-24 14:59 ` Martin Liška 2019-01-24 15:11 ` Jakub Jelinek 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-01-24 14:59 UTC (permalink / raw) To: Joseph Myers, Richard Biener Cc: Jakub Jelinek, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 911 bytes --] On 1/23/19 2:07 AM, Joseph Myers wrote: > On Tue, 22 Jan 2019, Richard Biener wrote: > >>> Or instead just come up with target specific strings to determine the ABI, >>> say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000 >>> etc. >> >> Yeah, I would even suggest to use a target hook multilib_ABI_active_p >> (const char *) >> for this ... (where the hook should diagnose unknown multilib specifiers). > > A header from a newer glibc version, supporting new ABIs, should still be > usable with an older GCC version, not supporting some of those ABIs. > Thus I don't think the hook should diagnose unknown specifiers from such a > header. (This is just like how a C header can test new predefined macros > without an old GCC complaining it doesn't know what would define those > macros.) > Hi. I'm sending patch candidate that introduced a new target hook. Thoughts? Martin [-- Attachment #2: 0001-Support-if-statement-in-GCC-builtin-directive.patch --] [-- Type: text/x-patch, Size: 7765 bytes --] From 46dd8bad4ce4c467e7387b75ba8241a3de194b71 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Mon, 21 Jan 2019 08:46:06 +0100 Subject: [PATCH] Support if statement in !GCC$ builtin directive. gcc/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * config/i386/i386.c (ix86_get_multilib_abi_name): New function. (TARGET_GET_MULTILIB_ABI_NAME): New macro defined. * doc/tm.texi: Document new target hook. * doc/tm.texi.in: Likewise. * target.def: Add new target macro. * targhooks.c (default_get_multilib_abi_name): New. * targhooks.h (default_get_multilib_abi_name): Likewise. gcc/fortran/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): Add support for filtering of builtin directive based on multilib ABI name. gcc/testsuite/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-7.f90: New test. * gfortran.dg/simd-builtins-7.h: New test. --- gcc/config/i386/i386.c | 15 +++++++++++++++ gcc/doc/tm.texi | 4 ++++ gcc/doc/tm.texi.in | 2 ++ gcc/fortran/decl.c | 17 ++++++++++++++--- gcc/target.def | 6 ++++++ gcc/targhooks.c | 6 ++++++ gcc/targhooks.h | 1 + gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 19 +++++++++++++++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.h | 2 ++ 9 files changed, 69 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index e0d7c74fcec..95fc905b4ea 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t cum_v, tree type) cum->warn_empty = false; } +static const char * +ix86_get_multilib_abi_name (void) +{ + if (!(TARGET_64BIT_P (ix86_isa_flags))) + return "i386"; + else if (TARGET_X32_P (ix86_isa_flags)) + return "x32"; + else + return "x86_64"; +} + /* Compute the alignment for a variable for Intel MCU psABI. TYPE is the data type, and ALIGN is the alignment that the object would ordinarily have. */ @@ -51804,6 +51815,10 @@ ix86_run_selftests (void) #undef TARGET_WARN_PARAMETER_PASSING_ABI #define TARGET_WARN_PARAMETER_PASSING_ABI ix86_warn_parameter_passing_abi +#undef TARGET_GET_MULTILIB_ABI_NAME +#define TARGET_GET_MULTILIB_ABI_NAME \ +ix86_get_multilib_abi_name + #if CHECKING_P #undef TARGET_RUN_TARGET_SELFTESTS #define TARGET_RUN_TARGET_SELFTESTS selftest::ix86_run_selftests diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index 4347f89cd2f..8c8978bb13a 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -1931,6 +1931,10 @@ superset of all other ABIs. @var{call_1} must always be a call insn, call_2 may be NULL or a call insn. @end deftypefn +@deftypefn {Target Hook} {const char *} TARGET_GET_MULTILIB_ABI_NAME (void) +This hook returns name of multilib ABI name. +@end deftypefn + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index 41a6cb11cb0..fe1194ef91a 100644 --- a/gcc/doc/tm.texi.in +++ b/gcc/doc/tm.texi.in @@ -1711,6 +1711,8 @@ of @code{CALL_USED_REGISTERS}. @hook TARGET_RETURN_CALL_WITH_MAX_CLOBBERS +@hook TARGET_GET_MULTILIB_ABI_NAME + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 3314e176881..81e4bfcf094 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -28,6 +28,7 @@ along with GCC; see the file COPYING3. If not see #include "match.h" #include "parse.h" #include "constructor.h" +#include "target.h" /* Macros to access allocate memory for gfc_data_variable, gfc_data_value and gfc_data. */ @@ -11338,19 +11339,22 @@ gfc_match_gcc_unroll (void) return MATCH_ERROR; } -/* Match a !GCC$ builtin (b) attributes simd flags form: +/* Match a !GCC$ builtin (b) attributes simd flags if(target) form: The parameter b is name of a middle-end built-in. - Flags are one of: - - (empty) + FLAGS is optional and must be one of: - inbranch - notinbranch + IF(target) is optional and TARGET is a name of a multilib ABI. + When we come here, we have already matched the !GCC$ builtin string. */ + 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 +11365,13 @@ gfc_match_gcc_builtin (void) else if (gfc_match (" ( inbranch ) ") == MATCH_YES) clause = SIMD_INBRANCH; + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) + { + const char *abi = targetm.get_multilib_abi_name (); + if (abi == NULL || strcmp (abi, target) != 0) + return MATCH_YES; + } + if (gfc_vectorized_builtins == NULL) gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); diff --git a/gcc/target.def b/gcc/target.def index 05c9cc1da28..4ba6b167e26 100644 --- a/gcc/target.def +++ b/gcc/target.def @@ -5791,6 +5791,12 @@ call_2 may be NULL or a call insn.", rtx_insn *, (rtx_insn *call_1, rtx_insn *call_2), NULL) +DEFHOOK +(get_multilib_abi_name, + "This hook returns name of multilib ABI name.", + const char *, (void), + NULL) + DEFHOOK (remove_extra_call_preserved_regs, "This hook removes registers from the set of call-clobbered registers\n\ diff --git a/gcc/targhooks.c b/gcc/targhooks.c index 529590b55df..a03b967b913 100644 --- a/gcc/targhooks.c +++ b/gcc/targhooks.c @@ -2379,4 +2379,10 @@ default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *) { } +const char * +default_get_multilib_abi_name (void) +{ + return NULL; +} + #include "gt-targhooks.h" diff --git a/gcc/targhooks.h b/gcc/targhooks.h index 59436278dcf..f732073c828 100644 --- a/gcc/targhooks.h +++ b/gcc/targhooks.h @@ -286,5 +286,6 @@ extern bool speculation_safe_value_not_needed (bool); extern rtx default_speculation_safe_value (machine_mode, rtx, rtx, rtx); extern void default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *); +extern const char *default_get_multilib_abi_name (void); #endif /* GCC_TARGHOOKS_H */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 new file mode 100644 index 00000000000..c3ce5543779 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + y4 = sin(x4) + print *, y4 + + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h new file mode 100644 index 00000000000..42d5aa4afce --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h @@ -0,0 +1,2 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if(x86_64) +!GCC$ builtin (sinf) attributes simd (notinbranch) if(i386) -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-24 14:59 ` Martin Liška @ 2019-01-24 15:11 ` Jakub Jelinek 2019-01-24 15:36 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-24 15:11 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin LiÅ¡ka wrote: > --- a/gcc/config/i386/i386.c > +++ b/gcc/config/i386/i386.c > @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t cum_v, tree type) > cum->warn_empty = false; > } > > +static const char * Missing function comment. Usually a copy of the target hook description, perhaps with arch details. > +ix86_get_multilib_abi_name (void) > +{ > + if (!(TARGET_64BIT_P (ix86_isa_flags))) > + return "i386"; > + else if (TARGET_X32_P (ix86_isa_flags)) > + return "x32"; > + else > + return "x86_64"; > +} > + > /* Compute the alignment for a variable for Intel MCU psABI. TYPE is > the data type, and ALIGN is the alignment that the object would > ordinarily have. */ > @@ -51804,6 +51815,10 @@ ix86_run_selftests (void) > #undef TARGET_WARN_PARAMETER_PASSING_ABI > #define TARGET_WARN_PARAMETER_PASSING_ABI ix86_warn_parameter_passing_abi > > +#undef TARGET_GET_MULTILIB_ABI_NAME > +#define TARGET_GET_MULTILIB_ABI_NAME \ > +ix86_get_multilib_abi_name All other #define TARGET_* that need to wrap line indent the next line by two spaces, please do that too. > -/* Match a !GCC$ builtin (b) attributes simd flags form: > +/* Match a !GCC$ builtin (b) attributes simd flags if(target) form: > > The parameter b is name of a middle-end built-in. > - Flags are one of: > - - (empty) > + FLAGS is optional and must be one of: > - inbranch > - notinbranch FLAGS must be one of (inbranch) or (notinbranch) actually. > 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 +11365,13 @@ gfc_match_gcc_builtin (void) > else if (gfc_match (" ( inbranch ) ") == MATCH_YES) > clause = SIMD_INBRANCH; > > + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) > + { > + const char *abi = targetm.get_multilib_abi_name (); > + if (abi == NULL || strcmp (abi, target) != 0) > + return MATCH_YES; > + } Wonder whether we want if (x86_64) or if ('x86_64'), I'd lean for the latter. > + > if (gfc_vectorized_builtins == NULL) > gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); > > diff --git a/gcc/target.def b/gcc/target.def > index 05c9cc1da28..4ba6b167e26 100644 > --- a/gcc/target.def > +++ b/gcc/target.def > @@ -5791,6 +5791,12 @@ call_2 may be NULL or a call insn.", > rtx_insn *, (rtx_insn *call_1, rtx_insn *call_2), > NULL) > > +DEFHOOK > +(get_multilib_abi_name, > + "This hook returns name of multilib ABI name.", > + const char *, (void), > + NULL) > + > DEFHOOK > (remove_extra_call_preserved_regs, > "This hook removes registers from the set of call-clobbered registers\n\ > diff --git a/gcc/targhooks.c b/gcc/targhooks.c > index 529590b55df..a03b967b913 100644 > --- a/gcc/targhooks.c > +++ b/gcc/targhooks.c > @@ -2379,4 +2379,10 @@ default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *) > { > } > > +const char * > +default_get_multilib_abi_name (void) > +{ > + return NULL; > +} Just use hook_constcharptr_void_null instead of adding yet another hook that does the same thing? Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-24 15:11 ` Jakub Jelinek @ 2019-01-24 15:36 ` Martin Liška 2019-01-24 22:10 ` Steve Ellcey ` (2 more replies) 0 siblings, 3 replies; 94+ messages in thread From: Martin Liška @ 2019-01-24 15:36 UTC (permalink / raw) To: Jakub Jelinek Cc: Joseph Myers, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 3535 bytes --] On 1/24/19 4:05 PM, Jakub Jelinek wrote: > On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin LiÅ¡ka wrote: >> --- a/gcc/config/i386/i386.c >> +++ b/gcc/config/i386/i386.c >> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t cum_v, tree type) >> cum->warn_empty = false; >> } >> >> +static const char * > > Missing function comment. Usually a copy of the target hook description, > perhaps with arch details. > >> +ix86_get_multilib_abi_name (void) >> +{ >> + if (!(TARGET_64BIT_P (ix86_isa_flags))) >> + return "i386"; >> + else if (TARGET_X32_P (ix86_isa_flags)) >> + return "x32"; >> + else >> + return "x86_64"; >> +} >> + >> /* Compute the alignment for a variable for Intel MCU psABI. TYPE is >> the data type, and ALIGN is the alignment that the object would >> ordinarily have. */ >> @@ -51804,6 +51815,10 @@ ix86_run_selftests (void) >> #undef TARGET_WARN_PARAMETER_PASSING_ABI >> #define TARGET_WARN_PARAMETER_PASSING_ABI ix86_warn_parameter_passing_abi >> >> +#undef TARGET_GET_MULTILIB_ABI_NAME >> +#define TARGET_GET_MULTILIB_ABI_NAME \ >> +ix86_get_multilib_abi_name > > All other #define TARGET_* that need to wrap line indent the next line > by two spaces, please do that too. > >> -/* Match a !GCC$ builtin (b) attributes simd flags form: >> +/* Match a !GCC$ builtin (b) attributes simd flags if(target) form: >> >> The parameter b is name of a middle-end built-in. >> - Flags are one of: >> - - (empty) >> + FLAGS is optional and must be one of: >> - inbranch >> - notinbranch > > FLAGS must be one of (inbranch) or (notinbranch) actually. > >> 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 +11365,13 @@ gfc_match_gcc_builtin (void) >> else if (gfc_match (" ( inbranch ) ") == MATCH_YES) >> clause = SIMD_INBRANCH; >> >> + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) >> + { >> + const char *abi = targetm.get_multilib_abi_name (); >> + if (abi == NULL || strcmp (abi, target) != 0) >> + return MATCH_YES; >> + } > > Wonder whether we want if (x86_64) or if ('x86_64'), I'd lean for the > latter. > >> + >> if (gfc_vectorized_builtins == NULL) >> gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); >> >> diff --git a/gcc/target.def b/gcc/target.def >> index 05c9cc1da28..4ba6b167e26 100644 >> --- a/gcc/target.def >> +++ b/gcc/target.def >> @@ -5791,6 +5791,12 @@ call_2 may be NULL or a call insn.", >> rtx_insn *, (rtx_insn *call_1, rtx_insn *call_2), >> NULL) >> >> +DEFHOOK >> +(get_multilib_abi_name, >> + "This hook returns name of multilib ABI name.", >> + const char *, (void), >> + NULL) >> + >> DEFHOOK >> (remove_extra_call_preserved_regs, >> "This hook removes registers from the set of call-clobbered registers\n\ >> diff --git a/gcc/targhooks.c b/gcc/targhooks.c >> index 529590b55df..a03b967b913 100644 >> --- a/gcc/targhooks.c >> +++ b/gcc/targhooks.c >> @@ -2379,4 +2379,10 @@ default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *) >> { >> } >> >> +const char * >> +default_get_multilib_abi_name (void) >> +{ >> + return NULL; >> +} > > Just use hook_constcharptr_void_null instead of adding yet another hook that > does the same thing? > > Jakub > Thanks for comments, I'm sending new version. Martin [-- Attachment #2: 0001-Support-if-statement-in-GCC-builtin-directive.patch --] [-- Type: text/x-patch, Size: 6870 bytes --] From 3dce4e127c7810c4aff38f38ecb789fedc893082 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Mon, 21 Jan 2019 08:46:06 +0100 Subject: [PATCH] Support if statement in !GCC$ builtin directive. gcc/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * config/i386/i386.c (ix86_get_multilib_abi_name): New function. (TARGET_GET_MULTILIB_ABI_NAME): New macro defined. * doc/tm.texi: Document new target hook. * doc/tm.texi.in: Likewise. * target.def: Add new target macro. gcc/fortran/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): Add support for filtering of builtin directive based on multilib ABI name. gcc/testsuite/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-7.f90: New test. * gfortran.dg/simd-builtins-7.h: New test. --- gcc/config/i386/i386.c | 17 +++++++++++++++ gcc/doc/tm.texi | 4 ++++ gcc/doc/tm.texi.in | 2 ++ gcc/fortran/decl.c | 21 ++++++++++++++----- gcc/target.def | 6 ++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 19 +++++++++++++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.h | 2 ++ 7 files changed, 66 insertions(+), 5 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index e0d7c74fcec..7b594cc46ac 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -29577,6 +29577,19 @@ ix86_warn_parameter_passing_abi (cumulative_args_t cum_v, tree type) cum->warn_empty = false; } +/* This hook returns name of multilib ABI. */ + +static const char * +ix86_get_multilib_abi_name (void) +{ + if (!(TARGET_64BIT_P (ix86_isa_flags))) + return "i386"; + else if (TARGET_X32_P (ix86_isa_flags)) + return "x32"; + else + return "x86_64"; +} + /* Compute the alignment for a variable for Intel MCU psABI. TYPE is the data type, and ALIGN is the alignment that the object would ordinarily have. */ @@ -51804,6 +51817,10 @@ ix86_run_selftests (void) #undef TARGET_WARN_PARAMETER_PASSING_ABI #define TARGET_WARN_PARAMETER_PASSING_ABI ix86_warn_parameter_passing_abi +#undef TARGET_GET_MULTILIB_ABI_NAME +#define TARGET_GET_MULTILIB_ABI_NAME \ + ix86_get_multilib_abi_name + #if CHECKING_P #undef TARGET_RUN_TARGET_SELFTESTS #define TARGET_RUN_TARGET_SELFTESTS selftest::ix86_run_selftests diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index 4347f89cd2f..8c8978bb13a 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -1931,6 +1931,10 @@ superset of all other ABIs. @var{call_1} must always be a call insn, call_2 may be NULL or a call insn. @end deftypefn +@deftypefn {Target Hook} {const char *} TARGET_GET_MULTILIB_ABI_NAME (void) +This hook returns name of multilib ABI name. +@end deftypefn + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index 41a6cb11cb0..fe1194ef91a 100644 --- a/gcc/doc/tm.texi.in +++ b/gcc/doc/tm.texi.in @@ -1711,6 +1711,8 @@ of @code{CALL_USED_REGISTERS}. @hook TARGET_RETURN_CALL_WITH_MAX_CLOBBERS +@hook TARGET_GET_MULTILIB_ABI_NAME + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 3314e176881..945d3180834 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -28,6 +28,7 @@ along with GCC; see the file COPYING3. If not see #include "match.h" #include "parse.h" #include "constructor.h" +#include "target.h" /* Macros to access allocate memory for gfc_data_variable, gfc_data_value and gfc_data. */ @@ -11338,19 +11339,22 @@ gfc_match_gcc_unroll (void) return MATCH_ERROR; } -/* Match a !GCC$ builtin (b) attributes simd flags form: +/* Match a !GCC$ builtin (b) attributes simd flags if('target') form: The parameter b is name of a middle-end built-in. - Flags are one of: - - (empty) - - inbranch - - notinbranch + FLAGS is optional and must be one of: + - (inbranch) + - (notinbranch) + + IF('target') is optional and TARGET is a name of a multilib ABI. When we come here, we have already matched the !GCC$ builtin string. */ + 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 +11365,13 @@ gfc_match_gcc_builtin (void) else if (gfc_match (" ( inbranch ) ") == MATCH_YES) clause = SIMD_INBRANCH; + if (gfc_match (" if ( '%n' ) ", target) == MATCH_YES) + { + const char *abi = targetm.get_multilib_abi_name (); + if (abi == NULL || strcmp (abi, target) != 0) + return MATCH_YES; + } + if (gfc_vectorized_builtins == NULL) gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); diff --git a/gcc/target.def b/gcc/target.def index 05c9cc1da28..66cee075018 100644 --- a/gcc/target.def +++ b/gcc/target.def @@ -5791,6 +5791,12 @@ call_2 may be NULL or a call insn.", rtx_insn *, (rtx_insn *call_1, rtx_insn *call_2), NULL) +DEFHOOK +(get_multilib_abi_name, + "This hook returns name of multilib ABI name.", + const char *, (void), + hook_constcharptr_void_null) + DEFHOOK (remove_extra_call_preserved_regs, "This hook removes registers from the set of call-clobbered registers\n\ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 new file mode 100644 index 00000000000..c3ce5543779 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + y4 = sin(x4) + print *, y4 + + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h new file mode 100644 index 00000000000..1c19b88f877 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h @@ -0,0 +1,2 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386') -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-24 15:36 ` Martin Liška @ 2019-01-24 22:10 ` Steve Ellcey 2019-01-25 13:17 ` Martin Liška 2019-02-04 9:59 ` Martin Liška 2019-02-04 10:10 ` Jakub Jelinek 2 siblings, 1 reply; 94+ messages in thread From: Steve Ellcey @ 2019-01-24 22:10 UTC (permalink / raw) To: mliska, jakub Cc: gcc-patches, fortran, toon, tkoenig, richard.guenther, joseph, rep.dot.nop On Thu, 2019-01-24 at 16:25 +0100, Martin Liška wrote: > > > > > > +ix86_get_multilib_abi_name (void) > > > +{ > > > + if (!(TARGET_64BIT_P (ix86_isa_flags))) > > > + return "i386"; > > > + else if (TARGET_X32_P (ix86_isa_flags)) > > > + return "x32"; > > > + else > > > + return "x86_64"; > > > +} I'd like to get an aarch64 version of this target function into GCC 9.* too in order to support ILP32/LP64 on aarch64. It doesn't necessarily have to be part of this patch though, I could submit one later if you do not want to add it here. Aarch64 ILP32 support is in GCC and binutils but not GLIBC (except on a branch), I am thinking the Aarch64 version of this function would return "aarch64" or "aarch64_ilp32". Perhaps we should also have "aarch64_be" and "aarch64_be_ilp32" for big endian ABI's? Steve Ellcey sellcey@marvell.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-24 22:10 ` Steve Ellcey @ 2019-01-25 13:17 ` Martin Liška 0 siblings, 0 replies; 94+ messages in thread From: Martin Liška @ 2019-01-25 13:17 UTC (permalink / raw) To: Steve Ellcey, jakub Cc: gcc-patches, fortran, toon, tkoenig, richard.guenther, joseph, rep.dot.nop On 1/24/19 10:24 PM, Steve Ellcey wrote: > On Thu, 2019-01-24 at 16:25 +0100, Martin LiÅ¡ka wrote: >> >>> >>>> +ix86_get_multilib_abi_name (void) >>>> +{ >>>> + if (!(TARGET_64BIT_P (ix86_isa_flags))) >>>> + return "i386"; >>>> + else if (TARGET_X32_P (ix86_isa_flags)) >>>> + return "x32"; >>>> + else >>>> + return "x86_64"; >>>> +} > > > I'd like to get an aarch64 version of this target function into GCC 9.* > too in order to support ILP32/LP64 on aarch64. It doesn't necessarily > have to be part of this patch though, I could submit one later if you > do not want to add it here. Sure, feel free to provide a patch candidate. Once the patch is installed, I'm planning to document format of the pre-include header file. Martin > > Aarch64 ILP32 support is in GCC and binutils but not GLIBC (except on a > branch), I am thinking the Aarch64 version of this function would > return "aarch64" or "aarch64_ilp32". Perhaps we should also have > "aarch64_be" and "aarch64_be_ilp32" for big endian ABI's? > > Steve Ellcey > sellcey@marvell.com > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-24 15:36 ` Martin Liška 2019-01-24 22:10 ` Steve Ellcey @ 2019-02-04 9:59 ` Martin Liška 2019-02-04 10:10 ` Jakub Jelinek 2 siblings, 0 replies; 94+ messages in thread From: Martin Liška @ 2019-02-04 9:59 UTC (permalink / raw) To: Jakub Jelinek Cc: Joseph Myers, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches PING^1 On 1/24/19 4:25 PM, Martin LiÅ¡ka wrote: > On 1/24/19 4:05 PM, Jakub Jelinek wrote: >> On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin LiÅ¡ka wrote: >>> --- a/gcc/config/i386/i386.c >>> +++ b/gcc/config/i386/i386.c >>> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t cum_v, tree type) >>> cum->warn_empty = false; >>> } >>> >>> +static const char * >> >> Missing function comment. Usually a copy of the target hook description, >> perhaps with arch details. >> >>> +ix86_get_multilib_abi_name (void) >>> +{ >>> + if (!(TARGET_64BIT_P (ix86_isa_flags))) >>> + return "i386"; >>> + else if (TARGET_X32_P (ix86_isa_flags)) >>> + return "x32"; >>> + else >>> + return "x86_64"; >>> +} >>> + >>> /* Compute the alignment for a variable for Intel MCU psABI. TYPE is >>> the data type, and ALIGN is the alignment that the object would >>> ordinarily have. */ >>> @@ -51804,6 +51815,10 @@ ix86_run_selftests (void) >>> #undef TARGET_WARN_PARAMETER_PASSING_ABI >>> #define TARGET_WARN_PARAMETER_PASSING_ABI ix86_warn_parameter_passing_abi >>> >>> +#undef TARGET_GET_MULTILIB_ABI_NAME >>> +#define TARGET_GET_MULTILIB_ABI_NAME \ >>> +ix86_get_multilib_abi_name >> >> All other #define TARGET_* that need to wrap line indent the next line >> by two spaces, please do that too. >> >>> -/* Match a !GCC$ builtin (b) attributes simd flags form: >>> +/* Match a !GCC$ builtin (b) attributes simd flags if(target) form: >>> >>> The parameter b is name of a middle-end built-in. >>> - Flags are one of: >>> - - (empty) >>> + FLAGS is optional and must be one of: >>> - inbranch >>> - notinbranch >> >> FLAGS must be one of (inbranch) or (notinbranch) actually. >> >>> 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 +11365,13 @@ gfc_match_gcc_builtin (void) >>> else if (gfc_match (" ( inbranch ) ") == MATCH_YES) >>> clause = SIMD_INBRANCH; >>> >>> + if (gfc_match (" if ( %n ) ", target) == MATCH_YES) >>> + { >>> + const char *abi = targetm.get_multilib_abi_name (); >>> + if (abi == NULL || strcmp (abi, target) != 0) >>> + return MATCH_YES; >>> + } >> >> Wonder whether we want if (x86_64) or if ('x86_64'), I'd lean for the >> latter. >> >>> + >>> if (gfc_vectorized_builtins == NULL) >>> gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); >>> >>> diff --git a/gcc/target.def b/gcc/target.def >>> index 05c9cc1da28..4ba6b167e26 100644 >>> --- a/gcc/target.def >>> +++ b/gcc/target.def >>> @@ -5791,6 +5791,12 @@ call_2 may be NULL or a call insn.", >>> rtx_insn *, (rtx_insn *call_1, rtx_insn *call_2), >>> NULL) >>> >>> +DEFHOOK >>> +(get_multilib_abi_name, >>> + "This hook returns name of multilib ABI name.", >>> + const char *, (void), >>> + NULL) >>> + >>> DEFHOOK >>> (remove_extra_call_preserved_regs, >>> "This hook removes registers from the set of call-clobbered registers\n\ >>> diff --git a/gcc/targhooks.c b/gcc/targhooks.c >>> index 529590b55df..a03b967b913 100644 >>> --- a/gcc/targhooks.c >>> +++ b/gcc/targhooks.c >>> @@ -2379,4 +2379,10 @@ default_remove_extra_call_preserved_regs (rtx_insn *, HARD_REG_SET *) >>> { >>> } >>> >>> +const char * >>> +default_get_multilib_abi_name (void) >>> +{ >>> + return NULL; >>> +} >> >> Just use hook_constcharptr_void_null instead of adding yet another hook that >> does the same thing? >> >> Jakub >> > > Thanks for comments, I'm sending new version. > > Martin > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-24 15:36 ` Martin Liška 2019-01-24 22:10 ` Steve Ellcey 2019-02-04 9:59 ` Martin Liška @ 2019-02-04 10:10 ` Jakub Jelinek 2019-02-05 1:31 ` Joseph Myers 2019-02-05 12:48 ` Martin Liška 2 siblings, 2 replies; 94+ messages in thread From: Jakub Jelinek @ 2019-02-04 10:10 UTC (permalink / raw) To: Martin Liška Cc: Joseph Myers, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Thu, Jan 24, 2019 at 04:25:13PM +0100, Martin LiÅ¡ka wrote: > @@ -11361,6 +11365,13 @@ gfc_match_gcc_builtin (void) > else if (gfc_match (" ( inbranch ) ") == MATCH_YES) > clause = SIMD_INBRANCH; > > + if (gfc_match (" if ( '%n' ) ", target) == MATCH_YES) Not sure if it is clean enough to have the 's in there, rather than matching there a string literal, requiring that it is a constant and getting at the string in there. But if this is fine with the Fortran maintainers, I won't object. Given the patches for aarch64, I'd think that in addition to the target specific multilib strings it might be worth to handle here also the generic lp64, ilp32 and llp64 strings (by checking the precision of the corresponding C types) and perhaps also big-endian, little-endian and pdp-endian. This way, targets which have only those differences wouldn't need to come up with their hooks. > +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ > +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ I think you need ia32 here, otherwise it will fail on x32, which is also ilp32 target, but not i386. > +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ > +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ > diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h > new file mode 100644 > index 00000000000..1c19b88f877 > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h > @@ -0,0 +1,2 @@ > +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64') > +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386') That is all from me, but I think you need a buy-in from the Fortran maintainers (if they are ok with such an extension from Fortran language POV) and from Joseph (or other glibc people). Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-04 10:10 ` Jakub Jelinek @ 2019-02-05 1:31 ` Joseph Myers 2019-02-05 12:48 ` Martin Liška 2019-02-05 12:48 ` Martin Liška 1 sibling, 1 reply; 94+ messages in thread From: Joseph Myers @ 2019-02-05 1:31 UTC (permalink / raw) To: Jakub Jelinek Cc: Martin Liška, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Mon, 4 Feb 2019, Jakub Jelinek wrote: > > +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64') > > +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386') > > That is all from me, but I think you need a buy-in from the Fortran > maintainers (if they are ok with such an extension from Fortran language > POV) and from Joseph (or other glibc people). My main comment here is that if you go with the approach of a single header shared by multilibs, you should also update the driver code so it no longer uses any sort of multilib suffix when searching for this header (it *should* still use the sysroot headers suffix when searching in a sysroot). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-05 1:31 ` Joseph Myers @ 2019-02-05 12:48 ` Martin Liška 2019-02-13 11:34 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-02-05 12:48 UTC (permalink / raw) To: Joseph Myers, Jakub Jelinek Cc: Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches, fortran On 2/5/19 2:31 AM, Joseph Myers wrote: > My main comment here is that if you go with the approach of a single > header shared by multilibs, you should also update the driver code so it > no longer uses any sort of multilib suffix when searching for this header > (it *should* still use the sysroot headers suffix when searching in a > sysroot). Addressed in the reply I've just sent to the Jakub's email. Martin ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-05 12:48 ` Martin Liška @ 2019-02-13 11:34 ` Martin Liška 2019-02-14 21:14 ` Steve Ellcey 0 siblings, 1 reply; 94+ messages in thread From: Martin Liška @ 2019-02-13 11:34 UTC (permalink / raw) To: Joseph Myers, Jakub Jelinek Cc: Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches May I please ping this so that we can reach mainline soon? Thanks, Martin On 2/5/19 1:48 PM, Martin LiÅ¡ka wrote: > On 2/5/19 2:31 AM, Joseph Myers wrote: >> My main comment here is that if you go with the approach of a single >> header shared by multilibs, you should also update the driver code so it >> no longer uses any sort of multilib suffix when searching for this header >> (it *should* still use the sysroot headers suffix when searching in a >> sysroot). > > Addressed in the reply I've just sent to the Jakub's email. > > Martin > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-13 11:34 ` Martin Liška @ 2019-02-14 21:14 ` Steve Ellcey 2019-02-15 11:16 ` Martin Liška 0 siblings, 1 reply; 94+ messages in thread From: Steve Ellcey @ 2019-02-14 21:14 UTC (permalink / raw) To: mliska, jakub, joseph Cc: gcc-patches, fortran, toon, tkoenig, richard.guenther, rep.dot.nop On Wed, 2019-02-13 at 12:34 +0100, Martin Liška wrote: > May I please ping this so that we can reach mainline soon? > > Thanks, > Martin Martin, I can't approve this patch but I can say that I have used it on Aarch64 and created a follow up patch for aarch64 to create a get_multilib_abi_name target function for that platform. Everything seemed to work fine for me and I did not have any problems or see any regressions when using your patch. I hope it gets approved and checked in soon. Steve Ellcey sellcey@marvell.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-14 21:14 ` Steve Ellcey @ 2019-02-15 11:16 ` Martin Liška 0 siblings, 0 replies; 94+ messages in thread From: Martin Liška @ 2019-02-15 11:16 UTC (permalink / raw) To: Steve Ellcey, jakub, joseph Cc: gcc-patches, fortran, toon, tkoenig, richard.guenther, rep.dot.nop On 2/14/19 10:13 PM, Steve Ellcey wrote: > On Wed, 2019-02-13 at 12:34 +0100, Martin LiÅ¡ka wrote: >> May I please ping this so that we can reach mainline soon? >> >> Thanks, >> Martin > > Martin, I can't approve this patch but I can say that I have used it on > Aarch64 and created a follow up patch for aarch64 to create a > get_multilib_abi_name target function for that platform. Everything > seemed to work fine for me and I did not have any problems or see any > regressions when using your patch. Great, can you please send the patch to this email thread? > I hope it gets approved and checked > in soon. Me too :) Martin > > Steve Ellcey > sellcey@marvell.com > ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-04 10:10 ` Jakub Jelinek 2019-02-05 1:31 ` Joseph Myers @ 2019-02-05 12:48 ` Martin Liška 2019-02-14 18:27 ` Joseph Myers 2019-02-16 0:05 ` Steve Kargl 1 sibling, 2 replies; 94+ messages in thread From: Martin Liška @ 2019-02-05 12:48 UTC (permalink / raw) To: Jakub Jelinek Cc: Joseph Myers, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches, fortran [-- Attachment #1: Type: text/plain, Size: 2298 bytes --] On 2/4/19 11:10 AM, Jakub Jelinek wrote: > On Thu, Jan 24, 2019 at 04:25:13PM +0100, Martin LiÅ¡ka wrote: >> @@ -11361,6 +11365,13 @@ gfc_match_gcc_builtin (void) >> else if (gfc_match (" ( inbranch ) ") == MATCH_YES) >> clause = SIMD_INBRANCH; >> >> + if (gfc_match (" if ( '%n' ) ", target) == MATCH_YES) > > Not sure if it is clean enough to have the 's in there, rather than > matching there a string literal, requiring that it is a constant and getting > at the string in there. But if this is fine with the Fortran maintainers, I > won't object. > > Given the patches for aarch64, I'd think that in addition to the target > specific multilib strings it might be worth to handle here also the generic > lp64, ilp32 and llp64 strings (by checking the precision of the > corresponding C types) and perhaps also big-endian, little-endian and > pdp-endian. This way, targets which have only those differences wouldn't > need to come up with their hooks. I would prefer to leave the implementation as simple as possible. I don't expect many targets implementing the SIMD ABI in glibc. It would not require much work on glibc side (math header file). > >> +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ilp32 } } } */ >> +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ilp32 } } } */ > > I think you need ia32 here, otherwise it will fail on x32, which is also > ilp32 target, but not i386. Fixed. > >> +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ >> +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ >> diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h >> new file mode 100644 >> index 00000000000..1c19b88f877 >> --- /dev/null >> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h >> @@ -0,0 +1,2 @@ >> +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64') >> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386') > > That is all from me, but I think you need a buy-in from the Fortran > maintainers (if they are ok with such an extension from Fortran language > POV) and from Joseph (or other glibc people). I CCed Fortran ML, I'm attaching update patch. Martin > > Jakub > [-- Attachment #2: 0001-Support-if-statement-in-GCC-builtin-directive.patch --] [-- Type: text/x-patch, Size: 8299 bytes --] From 74fa90f002d862582db7f613ff7aa758a0cbc5c0 Mon Sep 17 00:00:00 2001 From: marxin <mliska@suse.cz> Date: Mon, 21 Jan 2019 08:46:06 +0100 Subject: [PATCH] Support if statement in !GCC$ builtin directive. gcc/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * config/i386/i386.c (ix86_get_multilib_abi_name): New function. (TARGET_GET_MULTILIB_ABI_NAME): New macro defined. * doc/tm.texi: Document new target hook. * doc/tm.texi.in: Likewise. * target.def: Add new target macro. * gcc.c (find_fortran_preinclude_file): Do not search multilib suffixes. gcc/fortran/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * decl.c (gfc_match_gcc_builtin): Add support for filtering of builtin directive based on multilib ABI name. gcc/testsuite/ChangeLog: 2019-01-24 Martin Liska <mliska@suse.cz> * gfortran.dg/simd-builtins-7.f90: New test. * gfortran.dg/simd-builtins-7.h: New test. --- gcc/config/i386/i386.c | 17 +++++++++++++++ gcc/doc/tm.texi | 4 ++++ gcc/doc/tm.texi.in | 2 ++ gcc/fortran/decl.c | 21 ++++++++++++++----- gcc/gcc.c | 10 ++++----- gcc/target.def | 6 ++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 19 +++++++++++++++++ gcc/testsuite/gfortran.dg/simd-builtins-7.h | 2 ++ 8 files changed, 71 insertions(+), 10 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 789a53501ee..232a14a7de7 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -29583,6 +29583,19 @@ ix86_warn_parameter_passing_abi (cumulative_args_t cum_v, tree type) cum->warn_empty = false; } +/* This hook returns name of multilib ABI. */ + +static const char * +ix86_get_multilib_abi_name (void) +{ + if (!(TARGET_64BIT_P (ix86_isa_flags))) + return "i386"; + else if (TARGET_X32_P (ix86_isa_flags)) + return "x32"; + else + return "x86_64"; +} + /* Compute the alignment for a variable for Intel MCU psABI. TYPE is the data type, and ALIGN is the alignment that the object would ordinarily have. */ @@ -51815,6 +51828,10 @@ ix86_run_selftests (void) #undef TARGET_WARN_PARAMETER_PASSING_ABI #define TARGET_WARN_PARAMETER_PASSING_ABI ix86_warn_parameter_passing_abi +#undef TARGET_GET_MULTILIB_ABI_NAME +#define TARGET_GET_MULTILIB_ABI_NAME \ + ix86_get_multilib_abi_name + #if CHECKING_P #undef TARGET_RUN_TARGET_SELFTESTS #define TARGET_RUN_TARGET_SELFTESTS selftest::ix86_run_selftests diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index 4347f89cd2f..8c8978bb13a 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -1931,6 +1931,10 @@ superset of all other ABIs. @var{call_1} must always be a call insn, call_2 may be NULL or a call insn. @end deftypefn +@deftypefn {Target Hook} {const char *} TARGET_GET_MULTILIB_ABI_NAME (void) +This hook returns name of multilib ABI name. +@end deftypefn + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in index 41a6cb11cb0..fe1194ef91a 100644 --- a/gcc/doc/tm.texi.in +++ b/gcc/doc/tm.texi.in @@ -1711,6 +1711,8 @@ of @code{CALL_USED_REGISTERS}. @hook TARGET_RETURN_CALL_WITH_MAX_CLOBBERS +@hook TARGET_GET_MULTILIB_ABI_NAME + @findex fixed_regs @findex call_used_regs @findex global_regs diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 4393287e1f1..df7d5733ef0 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -28,6 +28,7 @@ along with GCC; see the file COPYING3. If not see #include "match.h" #include "parse.h" #include "constructor.h" +#include "target.h" /* Macros to access allocate memory for gfc_data_variable, gfc_data_value and gfc_data. */ @@ -11352,19 +11353,22 @@ gfc_match_gcc_unroll (void) return MATCH_ERROR; } -/* Match a !GCC$ builtin (b) attributes simd flags form: +/* Match a !GCC$ builtin (b) attributes simd flags if('target') form: The parameter b is name of a middle-end built-in. - Flags are one of: - - (empty) - - inbranch - - notinbranch + FLAGS is optional and must be one of: + - (inbranch) + - (notinbranch) + + IF('target') is optional and TARGET is a name of a multilib ABI. When we come here, we have already matched the !GCC$ builtin string. */ + 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; @@ -11375,6 +11379,13 @@ gfc_match_gcc_builtin (void) else if (gfc_match (" ( inbranch ) ") == MATCH_YES) clause = SIMD_INBRANCH; + if (gfc_match (" if ( '%n' ) ", target) == MATCH_YES) + { + const char *abi = targetm.get_multilib_abi_name (); + if (abi == NULL || strcmp (abi, target) != 0) + return MATCH_YES; + } + if (gfc_vectorized_builtins == NULL) gfc_vectorized_builtins = new hash_map<nofree_string_hash, int> (); diff --git a/gcc/gcc.c b/gcc/gcc.c index 797ed36616f..481e8289ad3 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -9965,24 +9965,24 @@ find_fortran_preinclude_file (int argc, const char **argv) /* Search first for 'finclude' folder location for a header file installed by the compiler (similar to omp_lib.h). */ - add_prefix (&prefixes, argv[2], NULL, 0, 0, false); + add_prefix (&prefixes, argv[2], NULL, 0, 0, 0); #ifdef TOOL_INCLUDE_DIR /* Then search: <prefix>/<target>/<include>/finclude */ add_prefix (&prefixes, TOOL_INCLUDE_DIR "/finclude/", - NULL, 0, 0, false); + NULL, 0, 0, 0); #endif #ifdef NATIVE_SYSTEM_HEADER_DIR /* Then search: <sysroot>/usr/include/finclude/<multilib> */ add_sysrooted_hdrs_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR "/finclude/", - NULL, 0, 0, false); + NULL, 0, 0, 0); #endif - const char *path = find_a_file (&include_prefixes, argv[1], R_OK, true); + const char *path = find_a_file (&include_prefixes, argv[1], R_OK, false); if (path != NULL) result = concat (argv[0], path, NULL); else { - path = find_a_file (&prefixes, argv[1], R_OK, true); + path = find_a_file (&prefixes, argv[1], R_OK, false); if (path != NULL) result = concat (argv[0], path, NULL); } diff --git a/gcc/target.def b/gcc/target.def index 05c9cc1da28..66cee075018 100644 --- a/gcc/target.def +++ b/gcc/target.def @@ -5791,6 +5791,12 @@ call_2 may be NULL or a call insn.", rtx_insn *, (rtx_insn *call_1, rtx_insn *call_2), NULL) +DEFHOOK +(get_multilib_abi_name, + "This hook returns name of multilib ABI name.", + const char *, (void), + hook_constcharptr_void_null) + DEFHOOK (remove_extra_call_preserved_regs, "This hook removes registers from the set of call-clobbered registers\n\ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 new file mode 100644 index 00000000000..75734d43c3d --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 @@ -0,0 +1,19 @@ +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } } +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" } + +program test_overloaded_intrinsic + real(4) :: x4(3200), y4(3200) + real(8) :: x8(3200), y8(3200) + + y4 = sin(x4) + print *, y4 + + y4 = sin(x8) + print *, y8 +end + +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ia32 } } } */ +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ia32 } } } */ + +! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */ +! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */ diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h b/gcc/testsuite/gfortran.dg/simd-builtins-7.h new file mode 100644 index 00000000000..1c19b88f877 --- /dev/null +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.h @@ -0,0 +1,2 @@ +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64') +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386') -- 2.20.1 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-05 12:48 ` Martin Liška @ 2019-02-14 18:27 ` Joseph Myers 2019-02-16 0:05 ` Steve Kargl 1 sibling, 0 replies; 94+ messages in thread From: Joseph Myers @ 2019-02-14 18:27 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches, fortran [-- Attachment #1: Type: text/plain, Size: 474 bytes --] On Tue, 5 Feb 2019, Martin LiÅ¡ka wrote: > #ifdef NATIVE_SYSTEM_HEADER_DIR > /* Then search: <sysroot>/usr/include/finclude/<multilib> */ > add_sysrooted_hdrs_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR "/finclude/", > - NULL, 0, 0, false); > + NULL, 0, 0, 0); > #endif The comment needs updating to reflect that the search no longer uses multilib suffixes. The driver changes are OK with that change. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-02-05 12:48 ` Martin Liška 2019-02-14 18:27 ` Joseph Myers @ 2019-02-16 0:05 ` Steve Kargl 1 sibling, 0 replies; 94+ messages in thread From: Steve Kargl @ 2019-02-16 0:05 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Joseph Myers, Richard Biener, Bernhard Reutner-Fischer, fortran, Thomas Koenig, Toon Moene, GCC Patches On Tue, Feb 05, 2019 at 01:47:57PM +0100, Martin LiÅ¡ka wrote: > > gcc/fortran/ChangeLog: > > 2019-01-24 Martin Liska <mliska@suse.cz> > > * decl.c (gfc_match_gcc_builtin): Add support for filtering > of builtin directive based on multilib ABI name. > > gcc/testsuite/ChangeLog: > > 2019-01-24 Martin Liska <mliska@suse.cz> > > * gfortran.dg/simd-builtins-7.f90: New test. > * gfortran.dg/simd-builtins-7.h: New test. The Fortran bits look ok to me. -- steve ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-22 12:18 ` Richard Biener 2019-01-23 1:18 ` Joseph Myers @ 2019-01-23 22:53 ` Steve Ellcey 2019-01-23 22:57 ` Jakub Jelinek 1 sibling, 1 reply; 94+ messages in thread From: Steve Ellcey @ 2019-01-23 22:53 UTC (permalink / raw) To: jakub, richard.guenther Cc: gcc-patches, fortran, toon, mliska, tkoenig, joseph, rep.dot.nop On Tue, 2019-01-22 at 13:18 +0100, Richard Biener wrote: > > Yeah, I would even suggest to use a target hook multilib_ABI_active_p > (const char *) > for this ... (where the hook should diagnose unknown multilib specifiers). > > Richard. I wonder if we even need to pass a string to the target hook. Instead of: !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64-linux-gnu') We just have: !GCC$ builtin (cos) attributes simd (notinbranch) if_allowed When we see if_allowed we call a target function like multilib_ABI_active_p and it can use whatever criteria it wants to use to determine if the simd attribute should be honored. Or, if we are going this far, how about leaving out the if altogher and everytime we see a simd attribute in Fortran we call a target function to determine if it should or should not be honored. The default function can just return true, target specific versions could look at the ABI and return true or false as needed. It might also be worth passing the function (cos) as an argument to the target function, then we could have different ABI's enabling different functions and not have to have them all on or all off based on the ABI. Steve Ellcey sellcey@marvell.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-23 22:53 ` Steve Ellcey @ 2019-01-23 22:57 ` Jakub Jelinek 2019-01-23 23:14 ` [EXT] " Steve Ellcey 0 siblings, 1 reply; 94+ messages in thread From: Jakub Jelinek @ 2019-01-23 22:57 UTC (permalink / raw) To: Steve Ellcey Cc: richard.guenther, gcc-patches, fortran, toon, mliska, tkoenig, joseph, rep.dot.nop On Wed, Jan 23, 2019 at 09:56:21PM +0000, Steve Ellcey wrote: > I wonder if we even need to pass a string to the target hook. Instead > of: > > !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64-linux-gnu') > > We just have: > > !GCC$ builtin (cos) attributes simd (notinbranch) if_allowed That is not possible. The whole point why we have a header is that glibc as the library provider provides a header which says to gcc which builtins have simd entrypoints, for which target and for which multilib. If GCC knew or wanted to hardcode that info, we wouldn't have a header, we'd just hardcode it. The point is that at some later point, glibc might get an implementation for say powerpc64 64-bit, or mips n32, or whatever else, say for a subset of the builtins x86_64 has, or superset, ... Jakub ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [EXT] Re: Fortran vector math header 2019-01-23 22:57 ` Jakub Jelinek @ 2019-01-23 23:14 ` Steve Ellcey 0 siblings, 0 replies; 94+ messages in thread From: Steve Ellcey @ 2019-01-23 23:14 UTC (permalink / raw) To: jakub Cc: mliska, fortran, richard.guenther, toon, rep.dot.nop, tkoenig, gcc-patches, joseph On Wed, 2019-01-23 at 23:53 +0100, Jakub Jelinek wrote: > External Email > > ------------------------------------------------------------------- > --- > On Wed, Jan 23, 2019 at 09:56:21PM +0000, Steve Ellcey wrote: > > I wonder if we even need to pass a string to the target > > hook. Instead > > of: > > > > !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64-linux-gnu') > > > > We just have: > > > > !GCC$ builtin (cos) attributes simd (notinbranch) if_allowed > > That is not possible. The whole point why we have a header is that glibc > as the library provider provides a header which says to gcc which builtins > have simd entrypoints, for which target and for which multilib. > > If GCC knew or wanted to hardcode that info, we wouldn't have a header, we'd > just hardcode it. > The point is that at some later point, glibc might get an implementation for > say powerpc64 64-bit, or mips n32, or whatever else, say for a subset of the > builtins x86_64 has, or superset, ... Duh. Of course. I am not sure how I lost track of that fact. Steve Ellcey sellcey@marvell.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Fortran vector math header 2019-01-16 9:42 ` Fortran vector math header Martin Liška 2019-01-16 12:39 ` Jakub Jelinek @ 2019-01-16 13:59 ` Joseph Myers 1 sibling, 0 replies; 94+ messages in thread From: Joseph Myers @ 2019-01-16 13:59 UTC (permalink / raw) To: Martin Liška Cc: Jakub Jelinek, Bernhard Reutner-Fischer, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches [-- Attachment #1: Type: text/plain, Size: 314 bytes --] On Wed, 16 Jan 2019, Martin LiÅ¡ka wrote: > Now we should add the header file into glibc, I kicked a discussion here: > https://sourceware.org/ml/libc-help/2018-11/msg00015.html libc-help is for user questions. It's not suitable for glibc development discussions. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) 2018-11-15 20:54 ` Jakub Jelinek 2018-11-16 13:25 ` [PATCH] Support simd function declarations via a pre-include Martin Liška @ 2018-11-17 21:13 ` Bernhard Reutner-Fischer 1 sibling, 0 replies; 94+ messages in thread From: Bernhard Reutner-Fischer @ 2018-11-17 21:13 UTC (permalink / raw) To: Jakub Jelinek Cc: Martin Liška, Richard Biener, fortran, Thomas Koenig, Toon Moene, GCC Patches On 15 November 2018 21:54:23 CET, Jakub Jelinek <jakub@redhat.com> wrote: >> Can we use plain -include like in C? > >Wouldn't that be confusing whether it is included in preprocessor only >or if >it is included as a magic fortran include line at the beginning? Yes, of course. Forgot that its a cpp argument. So -fpre-include is fine. Thanks, ^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2019-02-20 20:00 UTC | newest]
Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <d749cd46-e231-1405-5713-ae7d966ff8c1@suse.cz>
[not found] ` <CAFiYyc0QyhpvQxam9E3BHn2hPkr1izQM13oo+_QvkhQvwroJqw@mail.gmail.com>
[not found] ` <ee42ab7d-12b8-d7d2-1769-1c96252bbd7b@netcologne.de>
[not found] ` <CAFiYyc1cHpw-7CEE8-1ipqHKCqpL+sX6dWOCK88iVk0cn2Mm8A@mail.gmail.com>
[not found] ` <48dcb864-bad1-5e09-d209-def296ed1cd3@suse.cz>
[not found] ` <676acdda-1253-b3bd-4e03-60298c4c995c@netcologne.de>
[not found] ` <4f37f79f-647a-4851-2ff2-e0e5592b3e7f@suse.cz>
[not found] ` <2082f59c-7c61-6b81-79f7-addf70da39fa@netcologne.de>
[not found] ` <CAFiYyc2AFExBnak5YX8-L_STQYxORuwWHnD9ETRMWN3u0gB1gg@mail.gmail.com>
[not found] ` <6b852ddd-001c-40d6-383b-0b36f3d13ee7@suse.cz>
[not found] ` <CAFiYyc2Q4eXBXBSisaWDE2JH_tS82AnZBPJv1D9fkZnAQpz0CA@mail.gmail.com>
[not found] ` <60df9de6-9607-c88a-de0d-1f2c83bf3970@suse.cz>
[not found] ` <D6325C52-AE0D-49DB-86A2-F5CBDE6BAC0B@gmail.com>
[not found] ` <916e3e10-e020-f4f3-6f8e-c57909c81d55@suse.cz>
[not found] ` <CAFiYyc14yjzAojw0o+mJoLvBwobLGhN1ppLKHOt56wan_-ApZw@mail.gmail.com>
[not found] ` <20181112163347.4cc3537e@nbbrfq.loc>
[not found] ` <CAFiYyc1cczXvCf1v4PPhHVmuvT_W8RuU+8R05vjuJ=_c_nP-6w@mail.gmail.com>
2018-11-14 10:06 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Martin Liška
2018-11-14 11:35 ` Jakub Jelinek
2018-11-14 11:56 ` Jakub Jelinek
2018-11-14 11:57 ` Jakub Jelinek
2018-11-14 14:09 ` [PATCH] Support simd function declarations via a pre-include Martin Liška
2018-11-14 14:14 ` Jakub Jelinek
2018-11-15 19:40 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Bernhard Reutner-Fischer
2018-11-15 20:54 ` Jakub Jelinek
2018-11-16 13:25 ` [PATCH] Support simd function declarations via a pre-include Martin Liška
2018-11-16 13:50 ` Jakub Jelinek
2018-11-16 15:12 ` Martin Liška
2018-11-17 13:30 ` Paul Richard Thomas
2018-11-17 17:57 ` Paul Richard Thomas
2018-11-17 18:16 ` Bernhard Reutner-Fischer
2018-11-19 12:14 ` Martin Liška
2018-11-19 12:16 ` Martin Liška
2018-11-19 12:33 ` Jakub Jelinek
2018-11-20 14:14 ` [PATCH][RFC] Extend locations where to seach for Fortran pre-include Martin Liška
2018-11-20 14:27 ` Jakub Jelinek
2018-11-20 18:11 ` Joseph Myers
2018-11-22 8:58 ` Martin Liška
2018-11-22 14:35 ` Joseph Myers
2018-11-23 13:59 ` Martin Liška
2018-11-23 18:08 ` Joseph Myers
2018-11-26 12:20 ` Martin Liška
2018-11-26 16:19 ` Matthias Klose
2018-11-26 16:35 ` Martin Liška
2018-11-26 18:33 ` Joseph Myers
2018-11-27 13:34 ` Martin Liška
2018-11-27 7:57 ` Thomas Koenig
2018-11-27 13:32 ` Martin Liška
2018-11-27 16:22 ` Steve Ellcey
2018-11-27 21:12 ` Thomas Koenig
2019-02-18 13:23 ` Martin Liška
2019-02-19 18:18 ` Steve Kargl
2019-02-20 7:09 ` Bernhard Reutner-Fischer
2019-02-20 9:23 ` Martin Liška
2019-02-20 9:37 ` Thomas König
2019-02-20 14:17 ` Martin Liška
2019-02-20 20:11 ` Thomas König
2019-02-20 9:52 ` Bernhard Reutner-Fischer
2019-02-20 9:57 ` Martin Liška
2019-02-20 10:46 ` Bernhard Reutner-Fischer
2019-02-20 11:12 ` Martin Liška
2018-11-26 16:54 ` Martin Liška
2018-11-26 18:45 ` Joseph Myers
2018-11-27 13:40 ` Martin Liška
2018-11-30 13:51 ` Martin Liška
2019-01-09 16:01 ` Martin Liška
2019-01-09 17:16 ` Joseph Myers
2019-01-09 17:21 ` Joseph Myers
2019-01-11 15:17 ` Martin Liška
2019-01-11 18:06 ` Joseph Myers
2019-01-14 14:09 ` Martin Liška
2019-01-15 17:45 ` Joseph Myers
2019-01-16 9:42 ` Fortran vector math header Martin Liška
2019-01-16 12:39 ` Jakub Jelinek
2019-01-16 14:05 ` Joseph Myers
2019-01-16 17:42 ` Joseph Myers
2019-01-16 18:04 ` Jakub Jelinek
2019-01-16 20:35 ` Joseph Myers
2019-01-18 8:18 ` Martin Liška
2019-01-18 8:40 ` Jakub Jelinek
2019-01-21 7:47 ` Martin Liška
2019-01-21 7:58 ` Jakub Jelinek
2019-01-21 9:09 ` Martin Liška
2019-01-21 9:19 ` Jakub Jelinek
2019-01-21 9:36 ` Martin Liška
2019-01-21 9:40 ` Jakub Jelinek
2019-01-21 14:25 ` Joseph Myers
2019-01-22 11:01 ` Martin Liška
2019-01-22 11:15 ` Jakub Jelinek
2019-01-22 12:18 ` Richard Biener
2019-01-23 1:18 ` Joseph Myers
2019-01-24 14:59 ` Martin Liška
2019-01-24 15:11 ` Jakub Jelinek
2019-01-24 15:36 ` Martin Liška
2019-01-24 22:10 ` Steve Ellcey
2019-01-25 13:17 ` Martin Liška
2019-02-04 9:59 ` Martin Liška
2019-02-04 10:10 ` Jakub Jelinek
2019-02-05 1:31 ` Joseph Myers
2019-02-05 12:48 ` Martin Liška
2019-02-13 11:34 ` Martin Liška
2019-02-14 21:14 ` Steve Ellcey
2019-02-15 11:16 ` Martin Liška
2019-02-05 12:48 ` Martin Liška
2019-02-14 18:27 ` Joseph Myers
2019-02-16 0:05 ` Steve Kargl
2019-01-23 22:53 ` Steve Ellcey
2019-01-23 22:57 ` Jakub Jelinek
2019-01-23 23:14 ` [EXT] " Steve Ellcey
2019-01-16 13:59 ` Joseph Myers
2018-11-17 21:13 ` [PATCH] Support simd function declarations via a pre-include. (was: [PATCH][RFC]Overloading intrinsics) Bernhard Reutner-Fischer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).