On 08/12/2007 02:56 AM, Jesper Juhl wrote: > (whoops, forgot to add maintainer to Cc - now added) Ehm... too late... > On 12/08/07, Jesper Juhl wrote: >> Hi, >> >> I've been building some randconfig kernels lately and I've noticed >> this in a few builds : >> >> drivers/block/cciss.c:2614: warning: right shift count >= width of type >> drivers/block/cciss.c:2615: warning: right shift count >= width of type >> drivers/block/cciss.c:2616: warning: right shift count >= width of type >> >> The code in question is this : >> >> static void do_cciss_request(struct request_queue *q) >> { >> ... >> sector_t start_blk; >> ... >> c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB >> c->Request.CDB[3]= (start_blk >> 48) & 0xff; >> c->Request.CDB[4]= (start_blk >> 40) & 0xff; >> ... >> } >> >> >> The problem stems from these lines in include/linux/types.h : >> ... >> #ifdef CONFIG_LBD >> typedef u64 sector_t; >> #else >> typedef unsigned long sector_t; >> #endif >> ... >> >> So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide. >> Thus it seems gcc is absolutely right in complaining about those >> 56, 48 & 40 bit shifts, since they are indeed wider than the type >> in the "!CONFIG_LBD on a 32bit arch" case. >> >> >> I must admit that I have no idear what the proper way to deal with >> that is, so I'll just report it so hopefully someone else can fix it. >> >> By the way; I'm building current Linus git tree, head at commit >> ac07860264bd2b18834d3fa3be47032115524cea Well, given that it's explicitly treating start_blk as a 64-bit value, the proper fix is probably to cast start_blk to an actual (guaranteed) 64-bit value. Untested, uncompiled, and someone else may disagree: Rene.