| 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
