Georg-Johann Lay writes:
> Ian Lance Taylor wrote:
>
>> Georg-Johann Lay writes:
>>
>>> Suppose avr.c:avr_out_lpm which is used to print insns in final,
>>> e.g. ADJUST_INSN_LENGTH.
>>>
>>> Should avr_out_lpm be moved to avr-c.c? And avr-c.c include all the
>>> rtl.h, tree.h, output.h etc. which
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: Friday, November 25, 2011 11:23 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
> Hi,
>
> On Thu, 24 Nov 2011, Jiangning Liu wrote:
>
> > One more question...
> >
> > C
> Again I don't understand. MEM_ADDR_SPACE does not make sense when
> compiling Ada, say.
Why?
> I'd guess XXX_ADDR_SPACE are just accessors for fields
> in tree or rtx that are reserved by the C front end. How do I know that
> the Ada front end does not reserve these bits for different purpos
Ian Lance Taylor wrote:
> Georg-Johann Lay writes:
>
>> Suppose avr.c:avr_out_lpm which is used to print insns in final,
>> e.g. ADJUST_INSN_LENGTH.
>>
>> Should avr_out_lpm be moved to avr-c.c? And avr-c.c include all the
>> rtl.h, tree.h, output.h etc. which is also needed by the functions
>> t
Georg-Johann Lay writes:
> Suppose avr.c:avr_out_lpm which is used to print insns in final,
> e.g. ADJUST_INSN_LENGTH.
>
> Should avr_out_lpm be moced to avr-c.c? And avr-c.c include all the
> rtl.h, tree.h, output.h etc. which is also needed by the functions
> that like to use c_addr_space_name?
Steven Bosscher schrieb:
In avr.c there is:
...
#include "c-family/c-common.h"
...
That is the problem: avr.c should be language independent. Here you
are trying to link code calling C-family functions in a non-C language
(lto1 is just another front end for gcc, just like
cc1/cc1plus/etc...).
