6 ms·
Yeah I know I get it, it's me more being wishful, but I more seriously wish at least compilers could emit a warning when they optimize something after UB: %
by mzs 5y ago
Yeah I know I get it, it's me more being wishful, but I more seriously wish at least compilers could emit a warning when they optimize something after UB:
% cat foo.c
#include <stdlib.h>
int
foo(int *bar)
{
int baz = *bar;
if (bar == NULL) exit(2);
return (baz);
}
% cc -O3 -Wall -Wextra -c foo.c
% objdump -dr foo.o
foo.o: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 _foo:
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 8b 07 movl (%rdi), %eax
6: 5d popq %rbp
7: c3 retq
% cc -O0 -Wall -Wextra -c foo.c
% objdump -dr foo.o
foo.o: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 _foo:
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 48 83 ec 10 subq $16, %rsp
8: 48 89 7d f8 movq %rdi, -8(%rbp)
c: 48 8b 45 f8 movq -8(%rbp), %rax
10: 8b 08 movl (%rax), %ecx
12: 89 4d f4 movl %ecx, -12(%rbp)
15: 48 83 7d f8 00 cmpq $0, -8(%rbp)
1a: 0f 85 0a 00 00 00 jne 10 <_foo+0x2a>
20: bf 02 00 00 00 movl $2, %edi
25: e8 00 00 00 00 callq 0 <_foo+0x2a>
0000000000000026: X86_64_RELOC_BRANCH _exit
2a: 8b 45 f4 movl -12(%rbp), %eax
2d: 48 83 c4 10 addq $16, %rsp
31: 5d popq %rbp
32: c3 retq
%
That's very similar to something that bit me in embedded except it was with pointer to structure. Compiler realizes I've derefed NULL and that's UB anyway so no need to do the NULL check later and merrily scribble exc vectors or whatever.
- foxfluff 5y agoThat's a nice example. It'd definitely be nice to have a warning for this one. Fwiw GCC does have a related warning flag (-Wnull-dereference) but I'm not sure it's made exactly for this. I believe it works based on functions being annotated for possibly returning NULL, e.g. malloc. It's also not enabled by -Wall or -W because apparently there were too many false positives: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554 I imagine patches would be welcome. I'm guessing there are more people who like to wish for more compiler features than there are people who like to develop compilers :)
- mzs 5y agoedit: Thanks, I just checked and the warning doesn't work https://godbolt.org/z/4TP1hfx4j https://godbolt.org/z/4TP1hfx4j But your hint found -fno-delete-null-pointer-checks which does the trick https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html And -fno-delete-null-pointer-checks made it into LLVM too. It's a good to know but a little late for when I needed it, cheers :) % cc -O3 -fno-delete-null-pointer-checks -Wall -Wextra -c foo.c % objdump -dr foo.o foo.o: file format Mach-O 64-bit x86-64 Disassembly of section __TEXT,__text: 0000000000000000 _foo: 0: 55 pushq %rbp 1: 48 89 e5 movq %rsp, %rbp 4: 48 85 ff testq %rdi, %rdi 7: 74 04 je 4 <_foo+0xd> 9: 8b 07 movl (%rdi), %eax b: 5d popq %rbp c: c3 retq d: bf 02 00 00 00 movl $2, %edi 12: e8 00 00 00 00 callq 0 <_foo+0x17> 0000000000000013: X86_64_RELOC_BRANCH _exit
- astrange 5y agoIf you want a general approach you can turn on ubsan in trap-only mode and see what traps have ended up in your output.
- zajio1am 5y agoBut such code might be generated by macros (or some code generator), in which case silent elimination of unnecessary code is expected and wanted behavior.
- MauranKilom 5y ago(Or templates, in the C++ case. Think of all the inlined iterator functions...)
- Too 5y agoIn this particular case the code is wrong and can be fixed easily by swapping the assignment and the comparison. Likewise, code generators shouldn’t be generating this faulty code. Raising compiler error here is the only right thing to do. There are of course more ambiguous examples, though obvious examples like the one above are sadly way too common.
- UncleMeat 5y agoWhy can't we say that the original code is wrong then? The whole point of having something be UB rather than implementation defined is because the language committee believes that it represents a bug in your program.