Re: error linking lto1 for target avr

2011-11-28 Thread Ian Lance Taylor
Georg-Johann Lay writes: > So if a frontend can define address spaces and it is a generic feature, the > question is how to get the name of an address space in a generic, language > independent way. We could decide that all frontends that use address spaces must define a printable name for each

Re: error linking lto1 for target avr

2011-11-28 Thread Georg-Johann Lay
Ian Lance Taylor wrote: > Georg-Johann Lay writes: >> Ian Lance Taylor wrote: >>> Georg-Johann Lay writes: >>> 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.

Re: error linking lto1 for target avr

2011-11-27 Thread Ian Lance Taylor
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

Re: error linking lto1 for target avr

2011-11-27 Thread Eric Botcazou
> 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

Re: error linking lto1 for target avr

2011-11-27 Thread Georg-Johann Lay
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

Re: error linking lto1 for target avr

2011-11-27 Thread Ian Lance Taylor
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?

Re: error linking lto1 for target avr

2011-11-27 Thread Georg-Johann Lay
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...).

Re: error linking lto1 for target avr

2011-11-26 Thread Steven Bosscher
> 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...). You should use ext

Re: error linking lto1 for target avr

2011-11-26 Thread Georg-Johann Lay
Sean D'Epagnier schrieb: I have the latest gcc from svn, and with "configure --target=avr --enable-languages=c": When building with "make" eventually I get: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-pro

Re: error linking lto1 for target avr

2011-11-26 Thread Wim Lewis
FWIW, I ran into this error today as well. I did some brief bisection to try to narrow down the source; it looks like it broke in r181378: 181736 - undefined reference to c_addr_space_name 181523 - undefined reference to c_addr_space_name 181440 - undefined reference to c_addr_space_name 181395 -