Re: eglibc done, too

["Joseph S. Myers" <joseph@codesourcery.com>]

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
joseph@codesourcery.com