Re: [PATCH]: convert (long)round(d) -> lround(d), etc

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Roger" == Roger Sayle <roger@eyesopen.com> writes:

Roger> The function you want is called "build_common_tree_nodes" in tree.c
Roger> that is responsible for building all of the tree nodes common to the
Roger> different language front-ends.  For example, this function creates
Roger> the tree node for "error_mark_node", etc...

Roger> This function is used by the ada, c, c++, f77, objc and treelang
Roger> front-ends front-ends.  The java front-end, however, currently doesn't
Roger> use this function and instead builds error_mark_node et al. itself in
Roger> java_init_decl_processing.

I'm not an expert on this part of gcj, so please bear with me.  I
looked at decl.c and I think the reason we don't use
build_common_tree_nodes is that gcj has decided that `char_type_node'
should be a 16 bit type.

I don't know why gcj didn't just define `jchar_type_node'; I suppose
one fix would be to run sed over the sources to change this.  (There
might be other reasons gcj doesn't use build_common_tree_nodes, I
didn't look any further.)

For me this does bring up the question of what sorts of assumptions
the middle end might make about types, sizes, semantics, all that sort
of thing.  It isn't just academic, since as you know Java has specific
rules for all sorts of situations that C would leave unspecified.

Roger> But you're right perhaps we should explictly write down that the
Roger> middle-end expects the front-end to either call build_common_tree_nodes
Roger> or to provide the *equivalent* functionality itself.  :>

Yeah, I'd like to see a real contract between the front and middle
ends.  I've been assuming that GENERIC would provide that... but are
things like the meaning of `char_type_node' or the list of required
types specified by GENERIC?

Tom