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-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common
-DHAVE_CONFIG_H -o lto1 \
lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
libbackend.a(avr.o): In function `avr_pgm_check_var_decl':
/home/sean/build/gcc-svn/build-avr-nofixed/gcc/../../gcc/config/avr/avr.c:6652:
undefined reference to `c_addr_space_name'
/home/sean/build/gcc-svn/build-avr-nofixed/gcc/../../gcc/config/avr/avr.c:6649:
undefined reference to `c_addr_space_name'
libbackend.a(avr.o): In function `avr_insert_attributes':
/home/sean/build/gcc-svn/build-avr-nofixed/gcc/../../gcc/config/avr/avr.c:6690:
undefined reference to `c_addr_space_name'
libbackend.a(avr.o): In function `avr_out_lpm':
/home/sean/build/gcc-svn/build-avr-nofixed/gcc/../../gcc/config/avr/avr.c:2352:
undefined reference to `c_addr_space_name'
collect2: ld returned 1 exit status
avr.c uses c_addr_space_name to get the names of address spaces for
diagnostics. GCC's build machinery does not arrange for this symbol
to be available when linking lto1. If configured with --disable-lto,
the compiler builds, but lto is unavailable.
This issue is causing trouble for people building the avr toolchain,
and will likely affect other targets as they adopt the use of
c_addr_space_name. Please suggest a fix.
Sean
In avr.c there is:
...
#include "c-family/c-common.h"
...
/* Sanity check NODE so that all pointers targeting address space
go along with CONST qualifier. Writing to this address spaces should
be detected and complained about as early as possible. */
static bool
avr_pgm_check_var_decl (tree node)
{
const char *reason = NULL;
addr_space_t as = ADDR_SPACE_GENERIC;
gcc_assert (as == 0);
if (avr_log.progmem)
avr_edump ("%?: %t\n", node);
switch (TREE_CODE (node))
{
default:
break;
case VAR_DECL:
if (as = avr_nonconst_pointer_addrspace (TREE_TYPE (node)), as)
reason = "variable";
break;
case PARM_DECL:
if (as = avr_nonconst_pointer_addrspace (TREE_TYPE (node)), as)
reason = "function parameter";
break;
case FIELD_DECL:
if (as = avr_nonconst_pointer_addrspace (TREE_TYPE (node)), as)
reason = "structure field";
break;
case FUNCTION_DECL:
if (as = avr_nonconst_pointer_addrspace (TREE_TYPE (TREE_TYPE
(node))),
as)
reason = "return type of function";
break;
case POINTER_TYPE:
if (as = avr_nonconst_pointer_addrspace (node), as)
reason = "pointer";
break;
}
if (reason)
{
if (TYPE_P (node))
error ("pointer targeting address space %qs must be const in %qT",
c_addr_space_name (as), node);
else
error ("pointer targeting address space %qs must be const in %s
%q+D",
c_addr_space_name (as), reason, node);
}
return reason == NULL;
}
Is the problem some missing dependencies in the build machinery for LTO?
Or must target.c not call functions from c-family/c-common.h?
I configure with --disable-lto because LTO fails in canadian cross
builds, see http://sourceware.org/PR12742
Johann
