On Sat, Sep 11, 2010 at 8:48 PM, Andrew Haley <a...@redhat.com> wrote: > On 09/10/2010 11:50 PM, Steven Bosscher wrote: > >> There is just one front-end file left that still has to #undef >> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The >> one remaining file is java/builtins.c. >> >> In java/builtins.c there are (what appear to be) functions that >> generate code for Java builtins, and these functions look at optabs to >> decide what to emit. For example: >> >> static tree >> compareAndSwapInt_builtin (tree method_return_type ATTRIBUTE_UNUSED, >> tree orig_call) >> { >> enum machine_mode mode = TYPE_MODE (int_type_node); >> if (direct_optab_handler (sync_compare_and_swap_optab, mode) >> != CODE_FOR_nothing >> || flag_use_atomic_builtins) >> { >> tree addr, stmt; >> >> >> As a result, java/builtins.c has to include most RTL-specific headers: >> >> /* FIXME: All these headers are necessary for sync_compare_and_swap. >> Front ends should never have to look at that. */ >> #include "rtl.h" >> #include "insn-codes.h" >> #include "expr.h" >> #include "optabs.h" >> >> I would really like to see this go away, and I would work on it if I >> had any idea what to do. > > The test tells us whether the back-end has atomic builtins. If it doesn't > then we generate calls to the libgcj back end. I really don't want gcj > to generate calls to nonexistent __compare_and_swap_4 or somesuch. > >> I thought that the builtins java/builtins.c >> adds here, are generic GCC builtins. For example there is a definition >> of BUILT_IN_BOOL_COMPARE_AND_SWAP_4 in sync-builtins.def, so what is >> the effect of the >> "define_builtin(BUILT_IN_BOOL_COMPARE_AND_SWAP_4,...)" code in >> java/builtins.c:initialize_builtins? Does this re-define the builtin? >> I don't understand how the front-end definition of the builtin and the >> one from sync-builtins.def work together. > > Well, the ones from sync-builtins.def have different names: otherwise > they're the same as the Java ones.
So why can't these be called instead of the Java ones? I suppose there are libgcc versions? Ciao! Steven