Denis Chertykov wrote:
> 2011/11/29 Georg-Johann Lay :
>> Ian Lance Taylor wrote:
>>> 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.
Steven Bosscher writes:
> On Tue, Nov 29, 2011 at 6:04 PM, Georg-Johann Lay wrote:
>> I attached a patch but I fail to find the right configure options for
>> gcc/binutils as the testsuite complains
>>
>> ./avr/bin/ld: bad -plugin option
>>
>> Configured gcc with --enable-lto and binutils 2.21 w
On Tue, Nov 29, 2011 at 6:04 PM, Georg-Johann Lay wrote:
> I attached a patch but I fail to find the right configure options for
> gcc/binutils as the testsuite complains
>
> ./avr/bin/ld: bad -plugin option
>
> Configured gcc with --enable-lto and binutils 2.21 with --enable-plugin.
Huh, wait. I
Georg-Johann Lay writes:
> I just can't find the right configure options to get the LTO stuff
> work, i.e. how to enable plugins in binutils and LTO in gcc.
For binutils: configure with --enable-plugins (note: not
--enable-plugin).
For gcc: should be on by default, or configure with --enable-lt
Denis Chertykov wrote:
2011/11/29 Georg-Johann Lay:
I attached a patch but I fail to find the right configure options for
gcc/binutils as the testsuite complains
./avr/bin/ld: bad -plugin option
Configured gcc with --enable-lto and binutils 2.21 with --enable-plugin.
Maybe the patch can be
2011/11/29 Georg-Johann Lay :
> Ian Lance Taylor wrote:
>> 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
Ian Lance Taylor wrote:
> 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 mus
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
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.
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
> 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...).
> 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
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
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 -
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-prototypes
-Wmissing-format-a
18 matches
Mail list logo
