This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Multilib mips build question
On Wed, 26 Sep 2012, Steve Ellcey wrote:
> On Tue, 2012-09-25 at 22:15 +0000, Joseph S. Myers wrote:
> > On Tue, 25 Sep 2012, Steve Ellcey wrote:
> >
> > > Before rebuilding to a single sysroot I looked at the usr/include directories
> > > for each of these builds and while the include files for the two mips64r2
> > > builds match, the usr/include/huge_vall.h and usr/include/ieee754.h files in
> > > the mips32r2 include directory are different then the mips64r2 ones. I think
> > > this is due to the Implies files.
> >
> > I advise working out what is correct for MIPS (possibly headers with ABI
> > conditionals) and then creating appropriate MIPS-specific versions of
> > these headers
>
> While investigating huge_vall.h I found that neither of the copies of
> this header file are coming from a mips specific directory. One is
> coming from bits/huge_vall.h and one from
> sysdeps/ieee754/ldbl-128/bits/huge_vall.h. The one under sysdeps has
> support for the 2.96 and older GCC compilers. If we removed this then
> the two files would be identical. Could we do this? Or if the two
> would then be identical could we get rid of one of them entirely?
For any IEEE platform, the HUGE_VAL* macros are infinities and a cast of
HUGE_VAL to long double is a correct definition of HUGE_VALL as long as
the HUGE_VAL definition itself was correct[*]. On that basis alone, I
don't think the ldbl-128 version of the header is needed. But considering
the issue further:
For MIPS, GCC gained mips64-linux support in version 3.4, so the support
for older compilers is irrelevant.
All the other architectures using ldbl-128 are using ldbl-64-128 because
support for 128-bit long double was only added in glibc 2.4. The GCC
versions potentially affected by the difference in headers are those
before 3.3. In 3.2, Alpha only had 128-bit long double support for OSF,
S390 didn't have it at all and SPARC has its own bits/huge_vall.h header
so should be unaffected by this issue anyway. The lack of Linux support
for 128-bit long double for Alpha and S390 in older GCC means that a
header doing anything special for it wouldn't be right with pre-3.3
compilers on those architectures anyway.
So I believe you can propose removal of the ldbl-128 version of
huge_vall.h on libc-alpha, for the above reasons. In fact, for the same
reason about the generic version being correct for any platform with IEEE
floating point, I believe it would be OK to remove the x86, sparc, ia64
and m68k versions of this header as well, leaving just the generic one.
[*] Ignoring any questions about the definitions in terms of a constant
0x1.0p2047 that overflows double but not long double - if excess precision
means that the constant is actually evaluated as long double then the cast
might not give correct results. But GCC didn't implement that aspect of
excess precision at all until 4.5, so it's irrelevant to the code for GCC
versions 2.96 to 3.2.
--
Joseph S. Myers
joseph@codesourcery.com