search for: unknown_funct

...ied 3 classes of issues which manifest as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings). 2. In different TU's, pre-instr inlini...

...ings when >> applying profile data with IRPGO (these affect FEPGO also I believe, but we >> looked in depth at IRPGO): >> >> 1. The main concerning one is that getPGOFuncName mangles the filename >> into the counter name. This causes us to get >> instrprof_error::unknown_function when the pgo-use build is done in a >> different build directory from the training build (which is a reasonable >> thing to support). In this situation, PGO data is useless for all `static` >> functions (and as a byproduct results in a huge volume of warnings). >> > &g...

...manifest as spammy warnings when > applying profile data with IRPGO (these affect FEPGO also I believe, but we > looked in depth at IRPGO): > > 1. The main concerning one is that getPGOFuncName mangles the filename > into the counter name. This causes us to get > instrprof_error::unknown_function when the pgo-use build is done in a > different build directory from the training build (which is a reasonable > thing to support). In this situation, PGO data is useless for all `static` > functions (and as a byproduct results in a huge volume of warnings). > Rong, I was just look...

...pplying profile data with IRPGO (these affect FEPGO also I believe, but we >>> looked in depth at IRPGO): >>> >>> 1. The main concerning one is that getPGOFuncName mangles the filename >>> into the counter name. This causes us to get >>> instrprof_error::unknown_function when the pgo-use build is done in a >>> different build directory from the training build (which is a reasonable >>> thing to support). In this situation, PGO data is useless for all `static` >>> functions (and as a byproduct results in a huge volume of warnings). >...

...manifest as spammy warnings when > applying profile data with IRPGO (these affect FEPGO also I believe, but we > looked in depth at IRPGO): > > 1. The main concerning one is that getPGOFuncName mangles the filename > into the counter name. This causes us to get > instrprof_error::unknown_function when the pgo-use build is done in a > different build directory from the training build (which is a reasonable > thing to support). In this situation, PGO data is useless for all `static` > functions (and as a byproduct results in a huge volume of warnings). > This can be enhanced w...

...as spammy warnings when > applying profile data with IRPGO (these affect FEPGO also I believe, but we > looked in depth at IRPGO): > > > > 1. The main concerning one is that getPGOFuncName mangles the filename > into the counter name. This causes us to get > instrprof_error::unknown_function when the pgo-use build is done in a > different build directory from the training build (which is a reasonable > thing to support). In this situation, PGO data is useless for all `static` > functions (and as a byproduct results in a huge volume of warnings). > > > > This can...

...pammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): >>>> > >>>> > 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings). >>>> > >>>> >...

...ses of issues which manifest as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): > > 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings). > > This can be enhanced with an use...

...gt; when applying profile data with IRPGO (these affect FEPGO also I believe, >> but we looked in depth at IRPGO): >> > >> > 1. The main concerning one is that getPGOFuncName mangles the filename >> into the counter name. This causes us to get >> instrprof_error::unknown_function when the pgo-use build is done in a >> different build directory from the training build (which is a reasonable >> thing to support). In this situation, PGO data is useless for all `static` >> functions (and as a byproduct results in a huge volume of warnings). >> > &g...

...sues which manifest as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): > > > > 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings). > > > > This can be enhanced wi...

Let's say I have a list called the_list consisting of three components: the_list$component_1 the_list$component_2 the_list$component_3 Now, I want to access it using a variable called comp. comp <- "component_1" I'm looking for some function that let's me do this: unknown_function(the_list, comp) Which should do the same thing as: the_list$component_1 Any ideas? I'd be open to other ways of doing this, too. I explored this way, but it didn't seem to get me anywhere: the_list$"component_1" I possibly could have gotten further along if I knew how to...

...ils.h" +#include "actions.h" + guestfs_h *g; -extern ETERM *dispatch (ETERM *message); -extern int atom_equals (ETERM *atom, const char *name); -extern ETERM *make_error (const char *funname); -extern ETERM *unknown_optarg (const char *funname, ETERM *optargname); -extern ETERM *unknown_function (ETERM *fun); -extern ETERM *make_string_list (char **r); -extern ETERM *make_table (char **r); -extern ETERM *make_bool (int r); -extern char **get_string_list (ETERM *term); -extern int get_bool (ETERM *term); -extern int get_int (ETERM *term); -extern int64_t get_int64 (ETERM *term); - /* Th...

...ch manifest as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): >> > >> > 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings). >> > >> > This can be enh...

...est as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): >>> > >>> > 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a reasonable thing to support). In this situation, PGO data is useless for all `static` functions (and as a byproduct results in a huge volume of warnings). >>> > >>> > This ca...

...O also I believe, >>>>> but we looked in depth at IRPGO): >>>>> > >>>>> > 1. The main concerning one is that getPGOFuncName mangles the >>>>> filename into the counter name. This causes us to get >>>>> instrprof_error::unknown_function when the pgo-use build is done in a >>>>> different build directory from the training build (which is a reasonable >>>>> thing to support). In this situation, PGO data is useless for all `static` >>>>> functions (and as a byproduct results in a huge v...

...lieve, but we looked in depth at IRPGO): >>>>>>> > >>>>>>> > 1. The main concerning one is that getPGOFuncName mangles the >>>>>>> filename into the counter name. This causes us to get >>>>>>> instrprof_error::unknown_function when the pgo-use build is done in a >>>>>>> different build directory from the training build (which is a reasonable >>>>>>> thing to support). In this situation, PGO data is useless for all `static` >>>>>>> functions (and as a bypro...

...t;>>>>> but we looked in depth at IRPGO): >>>>>> > >>>>>> > 1. The main concerning one is that getPGOFuncName mangles the >>>>>> filename into the counter name. This causes us to get >>>>>> instrprof_error::unknown_function when the pgo-use build is done in a >>>>>> different build directory from the training build (which is a reasonable >>>>>> thing to support). In this situation, PGO data is useless for all `static` >>>>>> functions (and as a byproduct results...

...pr "\ @@ -480,7 +480,7 @@ dispatch (ETERM *message) pr "if (atom_equals (fun, \"%s\"))\n" name; pr " return run_%s (message);\n" name; pr " else "; - ) all_functions_sorted; + ) external_functions_sorted; pr "return unknown_function (fun); } diff --git a/generator/fish.ml b/generator/fish.ml index 077a0b4..411cf11 100644 --- a/generator/fish.ml +++ b/generator/fish.ml @@ -31,6 +31,9 @@ open Prepopts open C open Events +let fish_functions_and_commands_sorted = + List.sort action_compare (fish_functions_sorted @ fish_co...

By splitting up large C files we can make parallel compiles a bit faster. Rich.