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
