This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]