| Message ID | 54AFF59C.6040908@mentor.com |
|---|---|
| State | New |
| Headers | show |
If unused on trunk, why would we commit it there? When your branch is merged, you'll merge it along. Otherwise that defeats the purpose of working on a branch, unless I misunderstand something... FX > Le 9 janv. 2015 à 16:37, Tom de Vries <Tom_deVries@mentor.com> a écrit : > > Jakub, > > For the oacc kernels patch series I need a fortran builtin with fn spec attribute (as mentioned here: https://gcc.gnu.org/ml/gcc/2014-12/msg00001.html ). > > Attached patch adds a function gfc_define_builtin_with_spec that allows me to define such a builtin. > > At this point there's no user yet in trunk, so I've declared it unused. > > Bootstrapped and reg-tested on x86_64. > > OK for stage 3 trunk? > > Thanks, > - Tom > <0001-Add-gfc_define_builtin_with_spec.patch>
On 09-01-15 18:11, FX wrote: > If unused on trunk, why would we commit it there? > When your branch is merged, you'll merge it along. Otherwise that defeats the purpose of working on a branch, unless I misunderstand something... This patch is not branch-specific. Thanks, - Tom > > FX > > > >> Le 9 janv. 2015 à 16:37, Tom de Vries <Tom_deVries@mentor.com> a écrit : >> >> Jakub, >> >> For the oacc kernels patch series I need a fortran builtin with fn spec attribute (as mentioned here: https://gcc.gnu.org/ml/gcc/2014-12/msg00001.html ). >> >> Attached patch adds a function gfc_define_builtin_with_spec that allows me to define such a builtin. >> >> At this point there's no user yet in trunk, so I've declared it unused. >> >> Bootstrapped and reg-tested on x86_64. >> >> OK for stage 3 trunk? >> >> Thanks, >> - Tom >> <0001-Add-gfc_define_builtin_with_spec.patch>
>> If unused on trunk, why would we commit it there? >> When your branch is merged, you'll merge it along. Otherwise that defeats the purpose of working on a branch, unless I misunderstand something... > > This patch is not branch-specific. As far as I understand, we don’t add unused code to the codebase. A quick grep through the current front-end and middle-end confirms that. Because it’s not used and not tested, it could bitrot and adds to the maintainance cost. FX
2015-01-09 Tom de Vries <tom@codesourcery.com> * f95-lang.c (gfc_define_builtin_with_spec): New function. --- gcc/fortran/f95-lang.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c index 9103fa9..0c33bb8 100644 --- a/gcc/fortran/f95-lang.c +++ b/gcc/fortran/f95-lang.c @@ -29,6 +29,7 @@ along with GCC; see the file COPYING3. If not see #include "coretypes.h" #include "gfortran.h" #include "tree.h" +#include "stringpool.h" #include "flags.h" #include "langhooks.h" #include "langhooks-def.h" @@ -594,6 +595,26 @@ gfc_define_builtin (const char *name, tree type, enum built_in_function code, set_builtin_decl (code, decl, true); } +/* Like gfc_define_builtin, but with fn spec attribute FNSPEC. */ + +static void ATTRIBUTE_UNUSED +gfc_define_builtin_with_spec (const char *name, tree fntype, + enum built_in_function code, + const char *library_name, int attr, + const char *fnspec) +{ + if (fnspec) + { + /* Code copied from build_library_function_decl_1. */ + tree attr_args = build_tree_list (NULL_TREE, + build_string (strlen (fnspec), fnspec)); + tree attrs = tree_cons (get_identifier ("fn spec"), + attr_args, TYPE_ATTRIBUTES (fntype)); + fntype = build_type_attribute_variant (fntype, attrs); + } + + gfc_define_builtin (name, fntype, code, library_name, attr); +} #define DO_DEFINE_MATH_BUILTIN(code, name, argtype, tbase) \ gfc_define_builtin ("__builtin_" name "l", tbase##longdouble[argtype], \ -- 1.9.1