From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 86368] BUILD FAILED: why : forced (dist) upgrade for gcc 3.4.6 over a BIT COUNT, __builtin_ctz Date: Mon, 17 Nov 2014 04:46:19 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1469179097==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 054C96E067 for ; Sun, 16 Nov 2014 20:46:20 -0800 (PST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1469179097== Content-Type: multipart/alternative; boundary="1416199579.c66440.1245"; charset="UTF-8" --1416199579.c66440.1245 Date: Mon, 17 Nov 2014 04:46:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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@lists.freedesktop.org Reporter: johnandsara2@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 +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. --1416199579.c66440.1245 Date: Mon, 17 Nov 2014 04:46:19 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"
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@lists.freedesktop.org
Reporter johnandsara2@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.
--1416199579.c66440.1245-- --===============1469179097== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1469179097==--