gmane.comp.lib.glibc.alpha

Re: [PATCH] Suppress sign-conversion warning from FD_SET

Paul Pluzhnikov — 2012-05-26T00:31:59


Sounds good to me. I'll send an updated patch.

Thanks,

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

David Miller — 2012-05-26T00:16:32

From: "Joseph S. Myers" <joseph< at >codesourcery.com>
Date: Sat, 26 May 2012 00:12:41 +0000 (UTC)

Ok, now we're getting somewhere.

What's interesting is "ldbl_min / 4" using glibc's current soft-fp
generates the underflow exception on sparc 64-bit not sparc 32-bit.

The only difference is that sparc 32-bit uses _FP_DIV_MEAT_4_udiv()
and sparc 64-bit uses _FP_DIV_MEAT_2_udiv() for it's _FP_DIV_MEAT_Q()
definition.

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

Joseph S. Myers — 2012-05-26T00:12:41


It's quite possible one of the several FP_DIV implementations has a bug, 
but if they return results that don't have the highest set bit in the 
standard position I'd say that's a bug in the relevant implementation, and 
should be fixed there.  The ones I looked at compared the two mantissas at 
the start to work out the desired exponent, but maybe they get the case of 
equality wrong, or something like that.

I basically did not touch FP_DIV at all in my 2005-6 changes.


I just cleared that from my todo list, see my previous message - it was 
GCC bug 44631 (closed as invalid when it was found to be a kernel bug) and 
was fixed by my 2005-6 changes.

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

Joseph S. Myers — 2012-05-26T00:04:40


glibc and libgcc are kept in sync; local changes are not made to the 
libgcc copy (by GNU project policy) but instead updated files are imported 
verbatim from glibc.


It's effectively two copies, not three.  It was noted by RTH in 
<http://sourceware.org/ml/libc-alpha/2006-02/msg00075.html> that the 
changes should be merged into the kernel; I don't know if any kernel 
people ever actually tried doing that (I only follow kernel development to 
a very limited extent; if it's not on the linux-api list, which *should* 
get all things relevant to the kernel/userspace interface but doesn't 
always, I'm likely to miss it).

I've just followed up on an item that's been on my glibc todo list for a 
while, to check if GCC bug 44631 - a bug in the Linux kernel's copy of 
soft-fp - was applicable to the glibc version.  It's not; it's the same 
off-by-one error I mentioned as the fourth bullet point in 
<http://sourceware.org/ml/libc-alpha/2006-02/msg00028.html>, so fixed by 
my 2005-6 changes.

Re: [PATCH] Fix for logb/logbf/logbl (bz 13954/13955/13956)

Adhemerval Zanella — 2012-05-26T00:00:12

Yes, it passed the make check for on POWER7 for ppc32 and ppc64.

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

David Miller — 2012-05-25T23:57:30

From: "Joseph S. Myers" <joseph< at >codesourcery.com>
Date: Fri, 25 May 2012 23:43:18 +0000 (UTC)

I think part of all of these problems is that things come out a little
bit differently from the FP_DIV macro.  For example, for double
operation:

    000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE

FP_DIV generates:

    sign:         0
    mantissa: 01000000 00000000
    exp:         -1023 (0)

So we're exact before rounding.

There's a lot more information and discussion in the commit logs
messages of Linux kernel commits:

405849610fd96b4f34cd1875c4c033228fea6c0f

and

930cc144a043ff95e56b6888fa51c618b33f89e7

BTW, kernel commit f8324e20f8289dffc646d64366332e05eaacab25 fixes
another bug that we might have in the glibc and libgcc copies.  I
haven't looked more deeply at this yet, but it is on my TODO list.

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

David Miller — 2012-05-25T23:51:59

From: "Joseph S. Myers" <joseph< at >codesourcery.com>
Date: Fri, 25 May 2012 23:43:18 +0000 (UTC)

Did I ever tell you how extremely unfortunate it is that we have three
copies of this soft-fp code base and no real synchronization between
them?

I warned way back when libgcc got a copy of the soft-fp code that this
would happen, and those warnings fell on deaf ears.

I'll try to minimize my patch so that the sparc testsuite stops
regressing.

Longer term we need to rectify the situation that we have three
copies of the soft-fp code base, each has different bugs fixed
and different performance improvements.

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

Joseph S. Myers — 2012-05-25T23:43:18


For what operation on what inputs does it trigger?  As I understand the 
code, on entry to this macro (for a finite nonzero value) the exponent 
should always be the correct exponent for an infinite-precision 
calculation, and the mantissa should always be shifted so that the 
overflow bit is not set but the bit to the right of it (the most 
significant bits of the mantissa that's implicit in the actual 
floating-point binary format) is set.  So the patch seems overly 
complicated to me without an explanation of where the above description 
goes wrong.


Did the Linux kernel version ever get updated for all the performance 
improvements and bug fixes I made in 2005-6?  Unless it did, I'm not 
convinced keeping the two in sync is very meaningful; those were pretty 
substantial changes to a lot of the code.

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

David Miller — 2012-05-25T23:12:02

From: "Joseph S. Myers" <joseph< at >codesourcery.com>
Date: Fri, 25 May 2012 22:53:52 +0000 (UTC)

Yes, it triggers, we've seen it happen in the Linux kernel copy
of the soft-fp code.

And I'm trying to make this code match as close as possible what we
use there since this bug has been fixed in the Linux kernel copy for
almost 5 years and that code has been rigorously tested against
TestFloat by the powerpc folks.

Note that the FP_ROUND() macro can set the inexact exception, that's
another reason why it's placement is important.

Re: [PATCH] PowerPC - Add a faster way to read the Time Base register

Roland McGrath — 2012-05-25T23:11:11

Some simple nits below.  Fix those up and then it's OK to commit.
The manual bits are still imperfect, but we can improve them later.


Throughout this section, say "header file", not "header".


Drop that blank line since there isn't one after < at >itemize.


It's not a summary, it's the only documentation there is.


This is a part of the manual for users, who may have no interest in ever
working on libc.  I don't think it should have an xref to something maint.texi.


Not a summary.


Two spaces between sentences.  Use proper grammar (that sentence no verb).
Use < at >cite.


Period at the end of that sentence.


We don't usually break the line after the ( like that.
This whole thing could be on line, so just do that.


Likewise, here put "0..." right after the (.


Thanks,
Roland

Re: X32 is almost done

Roland McGrath — 2012-05-25T23:00:56

As I've already said, I think this is doing things in a fundamentally
wrong way.  But the really right way will involve a substantial revamp
of shlib-versions and so forth.  I don't think we should attempt to do
all that before 2.16, and I don't want to give the time and effort
necessary to push on the subject immediately anyway.

So I think this approach is probably acceptable for the 2.16 cycle
with the proviso that we must clean it up thoroughly afterwards.
There should be comments mentioning that the use of soname variables
in makefiles is duplicative and wrong, that the presumption that most
sonames will match in the multi-arch cases is wrong, and a bugzilla
item filed for cleaning it all up correctly before 2.17.

With those things done and if Joseph, Dave (for sparc), and Ryan (for
powerpc) all think it's OK, then I won't object to it going in.


Thanks,
Roland

Re: [PATCH] Fix underflow and inexact signalling in soft-fp when packing.

Joseph S. Myers — 2012-05-25T22:53:52


I think _FP_PACK_SEMIRAW needs a similar fix.


Is this "if" case now possible, with the rounding no longer happening 
here?


Equivalently, this looks like it might be a bigger change than necessary - 
as if the substance of what you are doing is really just removing the 
underflow exception setting from the existing "else" case, and putting the 
code after it that properly checks for "inexact".

X32 is almost done

H.J. Lu — 2012-05-25T22:22:34

Hi,

Thanks for everyone, x32 is almost done.  The last remaining issue is

http://sourceware.org/bugzilla/show_bug.cgi?id=14112

I have a proposal on hjl/abi branch.  I updated x32 wiki page:

http://sourceware.org/glibc/wiki/x32

to describe how to bootstrap x32 GCC and GLIBC.  I verified the procedure
on openSUSE 12.1:

hjl< at >gnu-32:/tmp> cat /etc/os-release
NAME=openSUSE
VERSION = 12.1 (Asparagus)
VERSION_ID="12.1"
PRETTY_NAME="openSUSE 12.1 (Asparagus) (x86_64)"
ID=opensuse
hjl< at >gnu-32:/tmp> cat x.c
#include <stdio.h>

int
main (void)
{
  printf ("hello\n");
  return 0;
}
hjl< at >gnu-32:/tmp> /usr/gcc-x32-4.7/bin/x86_64-linux-gcc -mx32 x.c
hjl< at >gnu-32:/tmp> file a.out
a.out: ELF 32-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.39, not
stripped
hjl< at >gnu-32:/tmp> ./a.out
hello
hjl< at >gnu-32:/tmp> uname -a
Linux gnu-32 3.4.0-1.9-desktop+ #3 SMP PREEMPT Fri May 25 05:30:28 PDT
2012 x86_64 x86_64 x86_64 GNU/Linux
hjl< at >gnu-32:/tmp>

Re: Remove __ASSUME_NEW_GETRLIMIT_SYSCALL

Roland McGrath — 2012-05-25T22:17:18

Looks fine to me.

[PATCH] Fix underflow and inexact signalling in soft-fp when packing.

David Miller — 2012-05-25T22:09:16

This fixes the long double math testsuite regressions that started
showing up on Sparc with Joseph's recent change to check underflow.

The corresponding changes needed in glibc-ports for powerpc/nofp,
mips, and alpha should be pretty straightforward.

In the main glibc tree, sparc is the only consumer of this code.

Ok to commit?

* soft-fp/op-common.h (_FP_PACK_CANONICAL): Only set underflow if
the underflow exception is enabled and the non-zero result is
tiny, or the non-zero result is tiny and there will be a loss of
accuracy.  Set inexact if overflow is detected after rounding, but
not if it is detected before.
* soft-fp/soft-fp.h (FP_CUR_EXCEPTIONS): Define.
(FP_TRAPPING_EXCEPTIONS): Provide default define.
* sysdeps/sparc/sparc32/soft-fp/sfp-machine.h (_FP_DECL_EX):
Initialize _fcw to zero.
(FP_TRAPPING_EXCEPTIONS): Define.
(FP_HANDLE_EXCEPTIONS): Add dummy use of _fcw.
* sysdeps/sparc/sparc64/soft-fp/sfp-machine.h (_FP_DECL_EX):
Initialize _fcw to zero.
(FP_TRAPPING_EXCEPTIONS): Define

Re: PATCH: Don't use header files in glibc configure

Thomas Schwinge — 2012-05-25T21:34:52

Hi!

On Fri, 25 May 2012 20:58:14 +0000 (UTC), "Joseph S. Myers" <joseph< at >codesourcery.com> wrote:


That sort of already has happened/blessed -- that is, the asking/idea,
not the implementation -- when I once proposed the exactly same thing:
<http://news.gmane.org/find-root.php?message_id=%3c87bougerfb.fsf%40kepler.schwinge.homeip.net%3e>.
I have not yet gotten around to implementing this on the Autoconf side.


On Fri, 25 May 2012 13:27:32 -0700, "H.J. Lu" <hongjiu.lu< at >intel.com> wrote:

Interesting -- didn't know about that one.


Grüße,
 Thomas

Remove __ASSUME_NEW_GETRLIMIT_SYSCALL

Joseph S. Myers — 2012-05-25T21:29:10

__ASSUME_NEW_GETRLIMIT_SYSCALL is defined in kernel-features.h for x86
and powerpc, and in ports for arm, for m68k (>= 2.4.12) and tile.  It
is used in sysdeps/unix/sysv/linux/i386/getrlimit.c and
sysdeps/unix/sysv/linux/i386/setrlimit.c.  Those files are in turn
included for powerpc, s390-32, sh and (in ports) am33, arm and m68k.

This relates to system calls now called ugetrlimit and setrlimit.  As
of 2.4.0-test1, s390, sh and m68k all have those syscalls wired up
(this is about the syscall tables rather than what's in asm/unistd.h,
since we already require >= 2.6.19.1 kernel headers).  So although
those architectures do not define __ASSUME_NEW_GETRLIMIT_SYSCALL (at
all, or for 2.4.0 in the case of m68k) it's nevertheless safe to
assume the syscalls to be present for those architectures.  Finally,
am33 (mn10300) support was added in 2.6.25, and when added the support
for those syscalls was present (and kernel versions before support for
an architecture was officially added to Linux are not of concern to
gl

Re: [PATCH] Suppress sign-conversion warning from FD_SET

Paul Eggert — 2012-05-25T21:23:40

As a general rule I'd rather avoid unnecessary casts.
The patch does not fix a bug, as the implicit conversion from
D's type 'int' to 'unsigned long int' has well-defined
behavior.  And the patch may mask a later bug if someone
mistakenly invokes the macro with D being a pointer.

Instead, how about using 'long int', since that's guaranteed
to work without munging the sign?  Something like this:

#define__FD_ELT(d) \
  __extension__    \
  ({ long int __d = (d);    \
     (__builtin_constant_p (__d)    \
      ? (0 <= __d && __d < __FD_SETSIZE    \
 ? __d / __NFDBITS : __fdelt_warn (__d))    \
      : __fdelt_chk (__d)); })

with a similar change to fdelt_chk's implementation, and
with the signatures of __fdelt_warn and __fdelt_chk
changed to use 'long int' rather than 'unsigned long int'.
The generated code should be identical.

Re: PATCH: Don't use header files in glibc configure

Joseph S. Myers — 2012-05-25T20:58:14


Is it really necessary to use autoconf internals like this, or can it be 
done with documented interfaces?  For example, I fixed one case with

2012-03-07  Joseph Myers  <joseph< at >codesourcery.com>

        * sysdeps/i386/configure.in (cpuid.h): Use AC_CHECK_HEADER with no
        default includes instead of AC_HEADER_CHECK.
        * sysdeps/i386/configure: Regenerated.

 - do other macros using the defaults have similar ways of fixing this?

If we do need to use autoconf internals, you should ask the autoconf 
maintainers to add an official supported way of changing the defaults so 
that when we move to a new autoconf release we no longer need to use 
internals like that.

Re: roland/systemtap branch

Ryan S. Arnold — 2012-05-25T20:57:02

We'll send a patch for the powerpc probe points early next week.

Ryan S. Arnold

Re: PATCH: Don't use header files in glibc configure

Roland McGrath — 2012-05-25T20:51:00

That looks fine to me.

Thanks,
Roland