On Sat, 23 Oct 2010, Thorsten Glaser wrote: > Sadly, not by a number of quick greps. It's something I remember from > some time ago, and I *think* I've seen cases in gcc's source where > calls were explicitly not done for cross compilers, but cannot find > them right now. If this has changed in the meantime, even better, > but recently, people discussing pcc vs. gcc still said that pcc uses > the exact same code paths for native vs. cross (actually, that pcc > doesn't care whether it's a native or cross compiler), whereas gcc > makes big noise about it. > > If this has indeed changed in gcc, I'd like pointers - and will > apologise.
Every relic of formerly sometimes depending on host floating point for target floating-point handling was removed in a series of patches in 2002-3, such as <http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01376.html> and finishing with <http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01055.html> removing configure code that cared about floating-point formats. I removed obsolete references to this from GCC's manuals in <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02630.html>, after which the only listed cross-compiler problem was: At present, the program @file{mips-tfile} which adds debug support to object files on MIPS systems does not work in a cross compile environment. (That program is actually only for alpha*-dec-osf5.1* with non-GNU assembler, not MIPS, now.) Note that the initial support for proper floating-point emulation with cross-compilation came in with GCC 2.4 (released May 17, 1993) - see the old NEWS file. The other cross-compiler issue sometimes cited prehistorically (i.e. about 15 years ago) related to cross-compilers from 32-bit to 64-bit hosts. GCC has used 64-bit host types as needed in such cases since <http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01266.html>. The consequence of such changes was that the CROSS_COMPILE conditional was actually purely a directory structure conditional - indicating whether headers and libraries were to be found in system directories such as /usr/include and /usr/lib, or whether different paths had to be used to find the target's headers, and similarly for assemblers and linkers. To avoid confusion the macro name was changed by <http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00505.html>. It is of course possible to have remaining bugs that manifest as different code generation for native and cross (and I fixed such bugs for decimal floating point in <http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00269.html> - but most architectures don't support decimal floating point at all, as it's a rather specialised feature), but such a bug is no different from any bug in any program that turns out to behave differently on 64-bit and 32-bit hosts, say, or that has a non-portable dependence on the endianness of a particular data type, or that depends on how qsort sorts elements that compare equal, or on the order in which function arguments are evaluated, or on any aspect of C undefined, unspecified or implementation-defined behavior, or that has a conditional on a macro such as CROSS_DIRECTORY_STRUCTURE that is conceptually the wrong condition for the intended purpose. Any such bug can just as easily manifest in native compilers as in cross compilers - and as some targets are mainly used through cross compilers, on many platforms such unportability issues are much more likely to appear with native compilers. -- Joseph S. Myers jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1010231630340.17...@digraph.polyomino.org.uk
