This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: gcj optimizations


>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> I would like to see a more "generic" framework for doing
Bryce> this. That is, instead of having identifiers in
Bryce> JTI_GLOBAL_TREES

I agree.  Modifying JTI_GLOBAL_TREES and the like is a pain.
I've updated my patch to do this.  It's not quite ready to send yet
though.

Bryce> I thought things like __builtin_cos would fall back on the
Bryce> library function if the builtin wasn't implemented? In any case
Bryce> it ought to be possible for GCJ to find out if a given builtin
Bryce> has been registered.

Yes, you're right.

But as it stands right now the builtins are never registered.  The
registration is only done for the C family of front ends.  The whole
builtin mechanism seems tied pretty closely to the C view of the world
:-(.  For instance you have to read builtin-types.def to process
builtins.def.  But the former references stuff that is unknown and
useless to Java, like `complex_long_double_type_node'.  We can fix or
work around this, I think.  In doing this I've duplicated an
uncomfortably large amount of code.  Ideally we'd share with the C
front ends, but there are enough minor differences that this may not
be possible.  It's a mess.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]