[Bug 86368] BUILD FAILED: why : forced (dist) upgrade for gcc 3.4.6 over a BIT COUNT, __builtin_ctz

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=86368

            Bug ID: 86368
           Summary: BUILD FAILED: why : forced (dist) upgrade for gcc
                    3.4.6 over a BIT COUNT, __builtin_ctz
           Product: DRI
           Version: DRI git
          Hardware: All
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Radeon
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: johnandsara2 at cox.net

__builtin_ctz

see patch below, at end

just counts a few bits at most.  possibly it's builtin because some plats have
accel asm in their kernel can use.  my mileage is not all accel for i386 are in
linux yet, and the (amd64) ones that are are for tend to be used needlessly and
sparsely in distro installer code - possibly to cause dependancy issues where
they really aren't needed though hardly used.

__builtin_ctz first appears in gcc-3.4.6

https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Other-Builtins.html#Other-Builtins

$ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
# yes, i did build R7.6 w/ i915 on old sarge (target is a few pc's)

the fix below doesn't use any hw accel call, pow or F2XM1 anything elegant, but
it works (and won't ask for fpu if bus busy)

if i upgrade is anyone sending me all new hw ?  gee thanks!  and really i hear
someone is hacking gcc to be c++ "driven" to force c++ typing in C.  wretched. 
the more type info you give c++ the more it requires and fails.  and most
warnings and some errors are K&R C WRONG today.  if default is void or int or
PTR (int) and programmer doesn't say: be quiet the rule already has a default:
a hardware size.  C will convert to size, or not if there is no asm that can:
that is the rule in the book it should be assumed it's what programmer INTENDED
EXACTLY: not a new error.  any breakage and troubled should be had by those
specifying an option looking for such c++ trouble.  don't be adding in forced
c++ brain damage contrived error to what is  correct gcc bison parsed c to
varasm.c then output, right?  thanks for reading that wish.

finally.  i rue everyone compiling against latest libs if earlier ones suffice,
and a policy of never fixing breakage in older libs (which before the 2000's
was not done: they fixed it).  it causes dependancy issue havoc to go another
BIG-OH higher.  as well often minor lib versions cause breakage: they aren't
supposed to, minors are supposed to be still compatible.

the diff below may apply though used on newer version: but it's pretty obvious
what diff suggests

$ cd libdrm-2.4.20/radeon

$ diff -Naru radeon_cs_gem.c.old radeon_cs_gem.c.new
--- radeon_cs_gem.c.old 2014-11-16 23:44:55.000000000 -0500
+++ radeon_cs_gem.c.new 2014-11-16 22:28:53.000000000 -0500
@@ -76,14 +76,29 @@
 /**
  * result is undefined if called with ~0
  */
+  /* __builtin_ctz returns number of trailing zeros. */
 /*
 static uint32_t get_first_zero(const uint32_t n)
 {
-    /* __builtin_ctz returns number of trailing zeros. */
     return 1 << __builtin_ctz(~n);
 }
 */

+#include <limits.h>
+static uint32_t get_first_zero(const uint32_t n)
+{
+   unsigned int x,i, s, nn ;
+   nn=(unsigned int) n;
+   x=0;i=0;s=sizeof(n);
+   for(i=1;i<=sizeof(n)*CHAR_BIT;++i)
+   {
+     if( (nn & 1) == 0 ) ++x; else break;
+     nn=nn>>1;
+   }
+   return (uint32_t) x;
+}
+
+
 /**
  * Returns a free id for cs.
  * If there is no free id we return zero

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/901c56bf/attachment-0001.html>