On Mon, Jun 20, 2016 at 08:01:24PM +0200, Michael Matz wrote: > You see, the experiment shows that there's a gazillion uses of basic asms > out there.
I applied the proposed patch and built myself an allyesconfig AArch64 linux kernel, the results were not pretty... make | grep "warning: Deprecated: asm" | wc -l 8911 You could say I'm cheating as the asm in question appears in header files, but this would be more than enough noise to guarantee the kernel will be built with your warning disabled (and when the Linux kernel switches a warning off, history suggests it won't be coming back on!). Remember that while you might convince people to apply the proper fix for kernel version N, you might struggle to get that fix backported across stable releases, vendor releases, private releases etc. particularly when the alternative fix of silencing the warning will appear to work fine. There are 11 unique warnings for an arm64 Linux kernel build, 7 unique warnings for an arm kernel build and 369 unique warnings for an x86_64 kernel build. Just for fun I counted how many warnings I get with x86_64 allyesconfig without filtering for unique; 14,697. I haven't audited them to see which would be safe with the minimal changes given in https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended (that document looks buggy, should it not reccommend that you always add a volatile when moving from basic to extended?). The sorts of things I see in the arm/arm64 port are sleep loops for CPUs guarded by a conditional, asm guarded by other asm barriers, text added to mergeable read-only section for common strings, other things that are not obviously broken uses of basic asm. On the other hand, some of the the x86_64 examples in lib/raid6/sse2.c are super scary and have back-to-back instructions with hard-coded registers... asm volatile("pcmpgtb %xmm4,%xmm5"); asm volatile("paddb %xmm4,%xmm4"); asm volatile("pand %xmm0,%xmm5"); I can't defend them, and they look very fragile! Fixing this code would require more substantial work. I'm only looking at one consumer of our compiler here, but I think anything that would cause the kernel community this much pain is a risky move, and is indicative of how frequently we'd see this warning fire in the wild. Permanently removing basic asm in a future GCC version is certainly not a workable solution. So what is the value of a noisy warning? Jeff and others have already come out against this patch, I'd like to add my vote against it too. Thanks, James
