Re: Issues of the latest trunk with LTO merges
On Mon, Oct 12, 2009 at 4:31 PM, Bingfeng Mei b...@broadcom.com wrote: Hello, I ran into an issue with the LTO merges when updating to current trunk. The problem is that my target calls a few functions/uses some data structures in the gcc directory: c_language, paragma_lex, c_register_pragma, etc. gcc -m32 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -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-elf.o attribs.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L/projects/firepath/tools/work/bmei/packages/gmp/4.3.0/lib -L/projects/firepath/tools/work/bmei/packages/mpfr/2.4.1/lib -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz -L/projects/firepath/tools/work/bmei/packages/libelf/lib -lelf ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lelf When compiling for lto1 in above step, I have many linking errors consequently. I tried to add some extra object files like c-common.o, c-pragma.o, etc into lto/Make-lang.in. More linking errors are produced. One problem is that lto code redefines some data exist in the main code: flag_no_builtin, flag_isoc99 lang_hooks, etc, which prevent it from linking with object files in main directory. What is the clean solution for this? Thanks in advance. You should not use C frontend specific stuff when not building the C frontend. Richard. Cheers, Bingfeng Mei
RE: Issues of the latest trunk with LTO merges
Richard, Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we want to specify target-specific pragma? It becomes part of libbackend.a, which is linked to lto1. One solution I see is to put them into a separate file so the linker won't produce undefined references when they are not actually used by lto1. Thanks, Bingfeng -Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: 12 October 2009 15:34 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Issues of the latest trunk with LTO merges On Mon, Oct 12, 2009 at 4:31 PM, Bingfeng Mei b...@broadcom.com wrote: Hello, I ran into an issue with the LTO merges when updating to current trunk. The problem is that my target calls a few functions/uses some data structures in the gcc directory: c_language, paragma_lex, c_register_pragma, etc. gcc -m32 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -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-elf.o attribs.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L/projects/firepath/tools/work/bmei/packages/gmp/4.3.0/lib -L/projects/firepath/tools/work/bmei/packages/mpfr/2.4.1/lib -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz -L/projects/firepath/tools/work/bmei/packages/libelf/lib -lelf ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lelf When compiling for lto1 in above step, I have many linking errors consequently. I tried to add some extra object files like c-common.o, c-pragma.o, etc into lto/Make-lang.in. More linking errors are produced. One problem is that lto code redefines some data exist in the main code: flag_no_builtin, flag_isoc99 lang_hooks, etc, which prevent it from linking with object files in main directory. What is the clean solution for this? Thanks in advance. You should not use C frontend specific stuff when not building the C frontend. Richard. Cheers, Bingfeng Mei
Re: Issues of the latest trunk with LTO merges
On Mon, Oct 12, 2009 at 08:09:48AM -0700, Bingfeng Mei wrote: Richard, Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we want to specify target-specific pragma? It becomes part of libbackend.a, which is linked to lto1. One solution I see is to put them into a separate file so the linker won't produce undefined references when they are not actually used by lto1. Yes. Take a look at config/arm/arm-c.c, which does not go into libbackend.a. -- Daniel Jacobowitz CodeSourcery
