[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at redhat dot com
[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 --- Comment #4 from Martin Sebor --- The show_tx_maxrate and show_trans_timeout functions mentioned in the listing in comment #1 are defined in Linux's net/core/net-sysfs.c. They return "sprintf(buf, "%lu\n", queue->tx_maxrate)" and "sprintf(buf, "%lu", trans_timeout)" respectively. Based on the assembly it looks like GCC determined their argument to be a positive number less than 10 and substituted it for the function's actual return value. I don't see anything wrong with that and it's unlikely that the implementation of integer formatting in the kernel is different than what C specifies, or that there's a bug in this area in GCC. But the printf code in the kernel (x86/boot/printf.c) that formats pointers does look like it will produce significantly different output than GCC expects from Glibc on Linux. Glibc formats non-null pointers the same as integers using the "%#zx" directive, and null as "(nil)". Linux uses "%08zx" for all of them (in LP64). The printf implementation elsewhere in Linux (lib/vsprintf.c) has a comment it follows C99 but has many %p extensions. When that one is used, GCC should probably bail when %p is encountered. Alternatively, GCC could add support for the kernel %p extensions and provide an option to turn them on. I count 2,364 occurrences of %p in Linux .c files, and 4,486 integer directives, with 1,135 format strings containing both. So it seems that to let the kernel fully benefit from the -Wformat-length and -fprintf-return-value options, we should consider adding support for the extended %p directives.
[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-11-24 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- I have yet to look into the details of this issue but just a quick clarifying comment: -fprintf-return-value is almost entirely based on the C requirements, with the exception of %p where it does make use of its knowledge of the underlying implementation. The option cannot match a non-conforming implementation without a corresponding target hook that describes it so when one is being targeted the options should not be used The option should be disabled automatically when either -fno-builtin-sprintf or its equivalent such -ffreestanding is specified (if it isn't it's a bug). That said, I don't think the Linux kernel uses either of these options. That suggests that the Linux printf should be conforming and the miscompilation may be a bug. Otherwise, it the Linux printf isn't conforming and we want it to benefit from the option (as I would expect us to since the request for the related -Wformat-length warning came from someone either contributing to or building the kernel) GCC might want to add a target hook describing the Linux printf specifics and a new option and to let the kernel enable it.
[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The problem with -fprintf-return-value is that it pretty much hardcodes the *printf* implementation details into GCC. And on Linux it hardcodes them for glibc, while the kernel has its own *printf* stuff and could behave slightly differently.
[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 --- Comment #1 from Markus Trippelsdorf --- I run md5sum on the object files with and without -fno-printf-return-value. Looking at a few files that differ they show a common pattern: good vs bad diff: @@ -312,7 +312,7 @@ movq$.LC1, %rsi movq%rax, %rdi callsprintf - cltq + movl$2, %eax ret .size show_tx_maxrate, .-show_tx_maxrate .section.rodata.str1.1 @@ -338,8 +338,8 @@ movq$.LC3, %rsi movq%rbp, %rdi callsprintf + movl$1, %eax popq%rbx - cltq popq%rbp ret .size show_trans_timeout, .-show_trans_timeout @@ -749,7 +749,7 @@ movq$fmt_u64, %rsi movq%rbp, %rdi callsprintf - cltq + movl$2, %eax .L121: movl$-256, %edx etc. Not sure if this a valid transformation or even the root cause of the issue.
[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |7.0
