This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: first cut at getting lto to compile.
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, "Hubicha, Jan" <jh at suse dot cz>, "Berlin, Daniel" <dberlin at dberlin dot org>, "Park, Seongbae" <seongbae dot park at gmail dot com>
- Date: Fri, 22 Jun 2007 20:28:51 -0400
- Subject: Re: first cut at getting lto to compile.
- References: <467AE15E.60200@naturalbridge.com> <467C50A0.6000107@codesourcery.com>
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> 2007-06-21 Kenneth Zadeck <zadeck@naturalbridge.com>
>>
>> * lto-tree-flags.def (FIX_CEIL_EXPR, FIX_FLOOR_EXPR,
>> FIX_ROUND_EXPR, section_name, call_clobbered_flag): Removed dead
>> cases.
>> Most of these fixes are obvious.
>>
>
> Thanks!
>
>
>> Mark - the change from include "libelf.h" to include "libelf/libelf.h"
>> is most likely wrong. I remember that the difference between these is
>> versioning that you thought was important. However, I have forgotten the
>> details and this compiles.
>>
>
> OK. There are two different versions of libelf out there; this may be
> one of the differences. I'll look at it and try to get it set up with
> autoconf, or something.
>
>
>> There are two places where I cannot figure out how to fix things:
>>
>> (1) num_parm_types and nth_parm_type seem to have gone away and no one
>> could point me at replacements.
>>
>
> These are the functions that Michael Meissner is working on, as part of
> the TYPE_ARG_TYPES memory-reduction work. It was a mistake (on my part)
> that this was co-mingled with LTO in the first place. I'll rework that
> code to use the current APIs.
>
>
>> (2) There seems to be some problem in langhooks.c with decl_attributes.
>>
>
> OK. I'll look at this tomorrow as well.
>
>
>> Anyway, if you config with --enable-languages=c,lto --disable-bootstrap
>> this patch will make some progress.
>>
>> I also added a ChangeLog.lto in the gcc directory.
>>
>
> We already have an gcc/lto/ChangeLog for changes within the gcc/lto/
> subdirectory, just like gcc/cp/ChangeLog, etc. So, we should use
> gcc/ChangeLog.lto for changes to the gcc subdirectory, and lto/ChangeLog
> for changes to the gcc/lto/ subdirectory.
>
> Thanks,
>
>
thanks for all of the other stuff, i will clean up the change logs this
weekend as you have suggested.
kenny