Bug#680100: Re[4]: [Gc] Alpha issue running test_stack (Debian Bug #680100)

2012-12-14 Thread gregor herrmann
Control: tag -1 + patch

On Fri, 09 Nov 2012 14:10:37 +0400, Ivan Maidanski wrote:

 I've committed the workaround (avoiding __builtin_expect in 
 AO_stack_pop_explicit_aux_acquire for gcc-4/alpha): 
 https://github.com/ivmai/libatomic_ops/commit/00d7cb807015b109df11b9227fbc7f35babdee16
 (But, of course, it would be good if someone report/fix bug in gcc.)

Hi Ian,

this bug should also be closed in testing, and since the version in
unstable won't migrate due to it being a newer version, we need to go
through t-p-u.

I've prepared a debdiff where I tried to backport the 00d7cb8 commit
to the version in testing (attached).

Could you please take a look at it and if possible upload it after
checking back with the release team?

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles
diff -u libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog
--- libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog
+++ libatomic-ops-7.2~alpha5+cvs20101124/debian/changelog
@@ -1,3 +1,13 @@
+libatomic-ops (7.2~alpha5+cvs20101124-1+deb7u1) testing-proposed-updates; urgency=low
+
+  * Non-maintainer upload.
+  * Fix libatomic-ops/powerpc: FTBFS: eats all disk space in the known
+universe (almost, anyway): nackport patch from upstream git repo:
+https://github.com/ivmai/libatomic_ops/commit/00d7cb8#diff-0
+(Closes: #680100)
+
+ -- gregor herrmann gre...@debian.org  Fri, 14 Dec 2012 15:00:16 +0100
+
 libatomic-ops (7.2~alpha5+cvs20101124-1+deb7u0) testing-proposed-updates; urgency=low
 
   * Non-maintainer upload with maintainer's permission.
only in patch2:
unchanged:
--- libatomic-ops-7.2~alpha5+cvs20101124.orig/src/atomic_ops_stack.c
+++ libatomic-ops-7.2~alpha5+cvs20101124/src/atomic_ops_stack.c
@@ -193,13 +193,25 @@
   /* We need to make sure that first is still the first entry on the*/
   /* list.  Otherwise it's possible that a reinsertion of it was*/
   /* already started before we added the black list entry.  */
-  if (first != AO_load(list)) {
+# if defined(__alpha__)  (__GNUC__ == 4)
+if (first != AO_load(list))
+/* Workaround __builtin_expect bug found in */
+/* gcc-4.6.3/alpha causing test_stack failure.  */
+# else
+if (AO_EXPECT_FALSE(first != AO_load(list)))
+# endif
+  {
 AO_store_release(a-AO_stack_bl+i, 0);
 goto retry;
   }
   first_ptr = AO_REAL_NEXT_PTR(first);
   next = AO_load(first_ptr);
-  if (!AO_compare_and_swap_release(list, first, next)) {
+# if defined(__alpha__)  (__GNUC__ == 4)
+if (!AO_compare_and_swap_release(list, first, next))
+# else
+if (AO_EXPECT_FALSE(!AO_compare_and_swap_release(list, first, next)))
+# endif
+  {
 AO_store_release(a-AO_stack_bl+i, 0);
 goto retry;
   }
only in patch2:
unchanged:
--- libatomic-ops-7.2~alpha5+cvs20101124.orig/src/atomic_ops.h
+++ libatomic-ops-7.2~alpha5+cvs20101124/src/atomic_ops.h
@@ -156,6 +156,13 @@
 # define AO_INLINE static
 #endif
 
+#if __GNUC__ = 3  !defined(LINT2)
+# define AO_EXPECT_FALSE(expr) __builtin_expect(expr, 0)
+  /* Equivalent to (expr) but predict that usually (expr) == 0. */
+#else
+# define AO_EXPECT_FALSE(expr) (expr)
+#endif /* !__GNUC__ */
+
 #if defined(__GNUC__)  !defined(__INTEL_COMPILER)
 # define AO_compiler_barrier() __asm__ __volatile__( : : : memory)
 #elif defined(_MSC_VER) || defined(__DMC__) || defined(__BORLANDC__) \


signature.asc
Description: Digital signature


Bug#680100: Re[4]: [Gc] Alpha issue running test_stack (Debian Bug #680100)

2012-12-14 Thread Ian Wienand
On Fri, Dec 14, 2012 at 03:29:23PM +0100, gregor herrmann wrote:
 I've prepared a debdiff where I tried to backport the 00d7cb8 commit
 to the version in testing (attached).
 
 Could you please take a look at it and if possible upload it after
 checking back with the release team?

Thanks for doing this.  As discussed, this looks correct to me and I'd
really appreciate if you could do the NMU on-top of the existing
package in t-p-u

Thanks,

-i


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#680100: Re[4]: [Gc] Alpha issue running test_stack (Debian Bug #680100)

2012-12-14 Thread gregor herrmann
On Fri, 14 Dec 2012 13:33:22 -0800, Ian Wienand wrote:

 On Fri, Dec 14, 2012 at 03:29:23PM +0100, gregor herrmann wrote:
  I've prepared a debdiff where I tried to backport the 00d7cb8 commit
  to the version in testing (attached).
  
  Could you please take a look at it and if possible upload it after
  checking back with the release team?
 
 Thanks for doing this.  As discussed, this looks correct to me and I'd
 really appreciate if you could do the NMU on-top of the existing
 package in t-p-u

Thank you, will file a t-p-u bug in a minute.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Johnny Cash: I Hung My Head


signature.asc
Description: Digital signature


Bug#680100: Re[4]: [Gc] Alpha issue running test_stack (Debian Bug #680100)

2012-11-09 Thread Ivan Maidanski
Hi Michael,

I've committed the workaround (avoiding __builtin_expect in 
AO_stack_pop_explicit_aux_acquire for gcc-4/alpha): 
https://github.com/ivmai/libatomic_ops/commit/00d7cb807015b109df11b9227fbc7f35babdee16
(But, of course, it would be good if someone report/fix bug in gcc.)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680100#15

Regards,
Ivan

Tue, 23 Oct 2012 11:37:33 +1300 Michael Cree mc...@orcon.net.nz:
   








On 22/10/2012, at 8:08 PM, Ivan Maidanski wrote:

 I guess you haven't got time to inspect assembly of broken code 

 (Alpha target).


I was busy at the time but then I totally forgot about this!


 I think it would be ok for now, just to find which use of 

 AO_EXPECT_FALSE results in broken code and create a workaround 

 avoiding AO_EXPECT_FALSE exactly at that place.


Interestingly doing any one of options 2 or 3 result in the test suite 

passing.


 2. AO_stack_pop_explicit_aux_acquire:

   if (AO_EXPECT_FALSE(first != AO_load(list))) {

 -

   if (first != AO_load(list)) {



 3. AO_stack_pop_explicit_aux_acquire:

   if (AO_EXPECT_FALSE(!AO_compare_and_swap_release(list, first, 

 next))) {

 -

   if (!AO_compare_and_swap_release(list, first, next)) {


They are quite close together in the code.  I wonder if there is some 

interaction between them.  I really must look at the generated 

assembly to see if the compiler is at fault but that will probably 

have to wait another day or two.


Cheers

Michael.



___

Gc mailing list
g...@linux.hpl.hp.com
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/