Hans-Peter Nilsson <hans-peter.nils...@axis.com> writes: >> * Again, I noticed an unused target file, >> config/cris/cris_abi_symbol.c. I assume it's a leftover from the >> cris-aout port and can go. > > As obvious from its contents, yes, put it to rest if you please.
Ok, will do. >> * config/cris/arit.c, config/cris/cris_abi_symbol.c: Move to >> ../libgcc/config/cris. >> * config/cris/cris.h: Remove obsolete comment. > > Not so obsolete IMO. Parentheses are still hard to pass through > shells :) though maybe there's just one layer now? But we have better mechanisms than passing arbitrary macros through several layers of make, cf. libgcc/config.host (tm_file), which used to be gcc/config.gcc (libgcc_tm_file). > IIUC, this file *is* still included when building libgcc2? Of course, my patches primarily handled build issues so far, dealing with the libgcc-only macros in gcc/config is future work. >> crisv32-*-linux* | cris-*-linux*) >> tm_file="dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h glibc-stdint.h >> cris/linux.h" >> - # We need to avoid using t-linux, so override default tmake_file >> - tmake_file="cris/t-cris cris/t-linux t-slibgcc" >> extra_options="${extra_options} cris/linux.opt" >> case $target in >> cris-*-*) > > Here there was an assignment, not append, to tmake_file. Right, but the only thing left in tmake_file is t-slibgcc, so no need to override that. >> diff --git a/gcc/config/cris/cris.h b/gcc/config/cris/cris.h >> --- a/gcc/config/cris/cris.h >> +++ b/gcc/config/cris/cris.h >> @@ -84,11 +84,7 @@ extern int cris_cpu_version; >> /* Changing the order used to be necessary to put the fourth __make_dp >> argument (a DImode parameter) in registers, to fit with the libfunc >> parameter passing scheme used for intrinsic functions. FIXME: Check >> - performance and maybe remove definition from TARGET_LIBGCC2_CFLAGS now >> - that it isn't strictly necessary. We used to do this through >> - TARGET_LIBGCC2_CFLAGS, but that became increasingly difficult as the >> - parenthesis (that needed quoting) travels through several layers of >> - make and shell invocations. */ >> + performance. */ >> #ifdef IN_LIBGCC2 >> #define __make_dp(a,b,c,d) __cris_make_dp(d,a,b,c) >> #endif > > ...well, as long as cris.h is still included and it's truly > obsolete due to the libgcc move. As stated above, it is until I (or someone else :-) starts tackling the macro move to libgcc. >> diff --git a/libgcc/config.host b/libgcc/config.host > >> *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | >> *-*-gnu* | *-*-kopensolaris*-gnu) >> - tmake_file="$tmake_file t-crtstuff-pic t-eh-dw2-dip t-slibgcc >> t-slibgcc-gld t-slibgcc-elf-ver t-linux" >> + tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip >> t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-linux" >> extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o" > > Hm... [...] >> cris-*-linux* | crisv32-*-linux*) >> - tmake_file="$tmake_file t-fdpbit cris/t-linux" >> + tmake_file="$tmake_file cris/t-cris t-fdpbit cris/t-linux" >> ;; > > But here you append to tmake_file. Is the new "generic" linux > tmake_file really safe? What was I was trying to avoid... oh, > the "SHLIB_MAPFILES += $(srcdir)/config/libgcc-glibc.ver"? > Should have been safe all along; none of those symbols were > defined. Anyway looks like I could need that config/t-linux This should be dealt with by the shlib patch http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00915.html that deals with this in libgcc/config/cris/t-linux: # Override t-linux default. SHLIB_MAPFILES = libgcc-std.ver $(srcdir)/config/cris/libgcc-glibc.ver > so... ok? But why don't I see a libgcc/config/cris/t-linux at > r177764 so I can check? It should be pre-existing before your > previous patch. Is this on top of more than the previous two > patches? Yep, all those patches are on top of each other, as I think I state in the submissions. > Ok, I'm confused. I want to wait until the other two patches > are committed, then look again. (They are independent if > serialized, right?) Yep, that's the intention at least. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University