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

[Roger Sayle]

On 29 Apr 2004, Tom Tromey wrote:
> I'm not an expert on this part of gcj, so please bear with me.

My apologies, I was perhaps a little harsh in my last post.


> 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.)


Indeed.  The problem appears to be that there isn't a clear defined
mechanism for the front-end to override the "default" types used by
the c-family languages.  I was initially thinking that java could
call build_common_tree_nodes and then afterwards modify or overwrite
the global trees, forcing 16-bit chars, 32-bit floats, 64-bit doubles
etc...  However thinking about it some more, your proposal of using
jchar_type_node, jfloat_type_node and jdouble_type_node (like the g77
front-end does) looks to be much better.  It allows the front and
middle-ends to call libc functions to implement java runtime routines
without conflicting definitions of char_type_node etc.

Roger
--