I don't know the answers to your specific questions, but I do know that
java questions might get faster response if cross posted to java@ (now
CCed).
David Daney
On 09/10/2010 03:50 PM, Steven Bosscher wrote:
Hello,
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. 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.
I could use a little help here... Thoughts?
Ciao!
Steven
