This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: error linking lto1 for target avr
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
>> that like to use c_addr_space_name?
>
> It's fine for avr-c.c to include rtl.h, tree.h, etc. (though including
> tree.h is unusual). It's fine for avr-c.c to call functions in avr.c.
I need it the other way round: With a wrapper for c_addr_space_name located in
avr-c.c that wrapper (or any other code moved to avr-c.c) needs to be called
from avr.c. Is that ok? If the answer is "yes": I don't quite understand why
that works and at what stage the otherwise missing function/object is dragged
in. If the answer is "no": This means I have to copy-paste the code from
c-common to avr.c? If such hack is actually needed, there must be a design flaw
somewhere.
> The point is that functions that are C/C++ specific need to not be in
> avr.c, because they will break for languages other than C/C++. In this
> terminology, LTO counts as a language.
>
>> Is is legitimate to use MEM_ADDR_SPACE in avr.c?
>
> Yes.
Again I don't understand. MEM_ADDR_SPACE does not make sense when compiling
Ada, say. 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 purpose so that using the accessors
get funny results?
Moreover, I don't get the difference between c_addr_space_name on the one side
and MEM_ADDR_SPACE, TYPE_ADDR_SPACE, ADDR_SPACE_GENERIC and addr_space_t on the
other side. I mean on the conceptual level, not on the technical
(macro/function/typedef) level.
They all make sense in C only, not even in C++ because named addresses are not
available in C++.
>> Is is legitimate to use TYPE_ADDR_SPACE in avr.c?
>
> Yes.
>
>> Must all this put into avr-c.c?
>
> Not for that reason, no.
>
> To a first approximation, anything that refers to something declared in
> c-common.h must be in avr-c.c, not in avr.c.
>
> Ian
Johann