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: Patches to remove TREE_COMPLEXITY for C and C++


Per Bothner <per@bothner.com> writes:

> Mark Mitchell wrote:
>
>> The Eclipse compiler is source->bytecode, right?
>
> Yes.  It is obvious integrated into Eclipse, but it can also
> be run as a standalone executable.  It is said to be quite fast.
>
> Anthony did a "port" of ecj to RHUG, allowing it to be built
> using gcj, but it hasn't been updated in a year.

This doesn't exactly fill me with confidence about what will happen in
the 3.5 timeframe.

> Boostrapping shouldn't be a problem.  We or Eclipse can provide
> ecj as a .jar, and our bytecode->native compiler can compile that.

That sounds workable.  We'd need most of libgcj as well as ecj.jar,
though, wouldn't we?  So we'd need a story for bootstrapping that,
too.

I would feel better about the prospects of doing this for 3.5 if
top-level bootstrap were *right now* the only way it worked (thus
allowing us to cycle out of the gcc subdir and go build bits of libgcj
during the bootstrap).  As it's still an experimental thing that no
one's done much work on in the last while...

>> You definitely have no obligation here, and I don't think Zack or I
>> meant to imply that you did.  It was just like "wow, it would sure
>> be cool if Per would do this."
>
> It would be nice if we could make --enable-mapped-location the default
> for 3.5/4.0, but that does require fixing the other frontends.

Yes, I'd really like to see that happen too.  Maybe I can even find
time to help.  Can't promise anything right now, though.

zw


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