Bug#855692: glibc: Please backport patch to fix 64-bit atomics on m68k

2017-02-21 Thread John Paul Adrian Glaubitz 
Source: glibc
Version: 2.24-9
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

glibc upstream recently merged a patch by Andreas Schwab to fix
64-bit atomics on m68k [1]. We have had multiple issues with
atomics on m68k in the past with packages like openjdk-8 and
firebird3.0 which I was able to resolve by downgrading glibc.

I therefore highly suspect that we need this patch to get these
aforementioned packages build properly on m68k again. I'm attaching
the cherry-picked patch for inclusion in the glibc package.

Thanks,
Adrian

> [1] 
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=64ae9fe45662c8994b0e56ab469b01967408a154

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix 64-bit atomics on m68k
Author: Andreas Schwab 
Last-Update: 2017-02-20

--- glibc-2.24.orig/sysdeps/m68k/m680x0/m68020/atomic-machine.h
+++ glibc-2.24/sysdeps/m68k/m680x0/m68020/atomic-machine.h
@@ -73,7 +73,7 @@ typedef uintmax_t uatomic_max_t;
  __typeof (mem) __memp = (mem);  \
  __asm __volatile ("cas2%.l %0:%R0,%1:%R1,(%2):(%3)" \
   : "=d" (__ret) \
-  : "d" (newval), "r" (__memp),  \
+  : "d" ((__typeof (*(mem))) (newval)), "r" (__memp),\
 "r" ((char *) __memp + 4), "0" (oldval)  \
   : "memory");   \
  __ret; })
@@ -101,8 +101,9 @@ typedef uintmax_t uatomic_max_t;
 __asm __volatile ("1: cas2%.l %0:%R0,%1:%R1,(%2):(%3);"  \
   "   jbne 1b"   \
   : "=d" (__result)  \
-  : "d" (newvalue), "r" (__memp),\
-"r" ((char *) __memp + 4), "0" (__result)\
+  : "d" ((__typeof (*(mem))) (newvalue)),\
+"r" (__memp), "r" ((char *) __memp + 4), \
+"0" (__result)   \
   : "memory");   \
} \
  __result; })
@@ -144,7 +145,7 @@ typedef uintmax_t uatomic_max_t;
   "   cas2%.l %0:%R0,%1:%R1,(%3):(%4);"  \
   "   jbne 1b"   \
   : "=d" (__result), "=&d" (__temp)  \
-  : "d" (value), "r" (__memp),   \
+  : "d" ((__typeof (*(mem))) (value)), "r" (__memp), \
 "r" ((char *) __memp + 4), "0" (__result)\
   : "memory");   \
} \
@@ -175,8 +176,9 @@ typedef uintmax_t uatomic_max_t;
  "   cas2%.l %0:%R0,%1:%R1,(%3):(%4);"   \
  "   jbne 1b"\
  : "=d" (__oldval), "=&d" (__temp)   \
- : "d" (value), "r" (__memp),\
-   "r" ((char *) __memp + 4), "0" (__oldval) \
+ : "d" ((__typeof (*(mem))) (value)),\
+   "r" (__memp), "r" ((char *) __memp + 4),  \
+   "0" (__oldval)\
  : "memory");\
  }   \
})

Bug#855606: sqrt() regression on powerpc/jessie

2017-02-21 Thread James Cloos 
It may be a bit more informative to add:

   printf("0X %A\n", r);

to that main() to see exactly what is different between the two.

The only ppc I have access to are those in the gcc farm and those (the
online ones anyway) only run fedora and aix, so I cannot test it
myself.

Except that everything else reports:

  0X 0X1.C48C6001F0ACP+3

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#854821: Reverting 29be63fd restores the old behavior

2017-02-21 Thread Nish Aravamudan 
On 14.02.2017 [20:30:52 +0100], Aurelien Jarno wrote:
> On 2017-02-10 11:50, Nish Aravamudan wrote:
> > Just ran a quick test using a PPA build of glibc with 29be63fd
> > ("debian/patches/localedata/locale-C.diff: switch back transliterations
> > to combining. Closes: #840199" [0] reverted and the test passes in a
> > 17.04 (Zesty) container again.
> 
> This change is intentional, and was done to revert an unintentional
> change (see #840199). Now the behaviour is consistent between jessie
> and stretch/sid.

I understand that, the above revert was mostly informational. Reading
the other bug, I see the reasoning behind not changing behavior. But it
seems like this also changes behavior, even if only within Unstable, and
needs some follow-up as phpmyadmin in Unstable will fail to rebuild
(verified just now in the chroot).

Given that this appears in an upstream test that is making an assumption
about \\TRANSLIT support from iconv (meaning that the behavior they are
testing for might be consistent across distributions), I'm not sure what
the best next step would be. Note that the phpmyadmin tests were only
relatively recently enabled at build-time, so that may be why this
wasn't noticed.

Any advice would be greatly appreciated!

Thanks,
Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd