On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: >> >> $ objdump -S clang-eflag.o >> >> clang-eflag.o: file format elf64-x86-64 >> >> >> Disassembly of section .text: >> >> 0000000000000000 <bar>: >> 0: 55 push %rbp >> 1: 48 89 e5 mov %rsp,%rbp >> 4: 53 push %rbx >> 5: 50 push %rax >> 6: e8 00 00 00 00 callq b <bar+0xb> >> b: ff 0d 00 00 00 00 decl 0x0(%rip) # 11 <bar+0x11> >> 11: 9c pushfq >> 12: 5b pop %rbx >> 13: e8 00 00 00 00 callq 18 <bar+0x18> >> 18: b8 01 00 00 00 mov $0x1,%eax >> 1d: 53 push %rbx >> 1e: 9d popfq >> 1f: 75 07 jne 28 <bar+0x28> > > > Yeah, the above is pure garbage. > >> So, the issue is still alive. >> >> What do you mean by "for the kernel we at a minimum need a way to >> disable that code generation"? >> Can this be fixed in the Linux-kernel? > > No. This will never be fixed in the kernel. It's a compiler bug. > > The compiler generates shit code. It's absolutely atrociously bad even > if you ignore any kernel issues, because that kind of code just > performs badly (the compiler should have used "setcc" or something > similar to just set the comparison value, not save and restore eflags. > > And quite frankly, any compiler writer that thinks it is good code is > not somebody I want touching a compiler that the kernel depends on > anyway. > > But it is not just bad code for the kernel, it's actively buggy code, > since it corrupts the IF. > > Until this gets fixed in LLVM, there's no way in hell that we will > ever have a kernel compiled with that piece of shit. > > Really. If the LLVM developers cannot fix their crap code generation, > it's not worth touching that shit with a ten-foot pole. > > I'd love to be able to compile the kernel with LLVM, but the fact that > the broken eflags code apparently _still_ hasn't been fixed makes me > just go "not worth it". > > And if the LLVM developers don't see this as an obvious bug, it's even > less worth it - because that shows not just that the compiler is > broken, but that the developers involved with it are broken too. > > Linus [ Changed Subject ] [ CC Matthias ] [ CC Michael test-case ] [ CC Chandler ] Hi Linus, Matthias pointed me in [0] to [1] in the LLVM-BTS. ...and I tried again the test-case from Michael from [3] "[LLVMdev] optimizer clobber EFLAGS"... ...with clang-7 (version: 7~svn330207-1~exp1+0~20180417201234.1709~1.gbp6fb10d) from <https://apt.llvm.org/>. [ TEST-CASE ] [ clang-eflag.c ] #include <stdlib.h> #include <stdbool.h> void foo(void); int a; int bar(void) { foo(); bool const zero = a -= 1; asm volatile ("" : : : "cc"); foo(); if (zero) { return EXIT_FAILURE; } foo(); return EXIT_SUCCESS; } - EOF - $ clang-7 -O2 -c -o clang-eflag.o clang-eflag.c [ OBJDUMP ] $ objdump -S clang-eflag.o clang-eflag.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <bar>: 0: 53 push %rbx 1: e8 00 00 00 00 callq 6 <bar+0x6> 6: 83 05 00 00 00 00 ff addl $0xffffffff,0x0(%rip) # d <bar+0xd> d: 0f 95 c3 setne %bl 10: e8 00 00 00 00 callq 15 <bar+0x15> 15: b8 01 00 00 00 mov $0x1,%eax 1a: f6 c3 ff test $0xff,%bl 1d: 74 02 je 21 <bar+0x21> 1f: 5b pop %rbx 20: c3 retq 21: e8 00 00 00 00 callq 26 <bar+0x26> 26: 31 c0 xor %eax,%eax 28: 5b pop %rbx 29: c3 retq Does this now look good? Thanks. Kind regards, - Sedat - [0] https://marc.info/?l=linux-kernel&m=152450535720279&w=2 [1] https://bugs.llvm.org/show_bug.cgi?id=36028 [2] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088766.html [3] https://marc.info/?l=linux-kernel&m=152457089205170&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
