[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #17) > Does the kernel boot now with the latest trunk? Yes. (Sorry for the delay.)
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #17 from Jakub Jelinek --- Does the kernel boot now with the latest trunk?
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #16 from Jakub Jelinek --- Author: jakub Date: Mon Jan 15 09:05:59 2018 New Revision: 256686 URL: https://gcc.gnu.org/viewcvs?rev=256686=gcc=rev Log: PR middle-end/82694 * common.opt (fstrict-overflow): No longer an alias. (fwrapv-pointer): New option. * tree.h (TYPE_OVERFLOW_WRAPS, TYPE_OVERFLOW_UNDEFINED): Define also for pointer types based on flag_wrapv_pointer. * opts.c (common_handle_option) : Set opts->x_flag_wrap[pv] to !value, clear opts->x_flag_trapv if opts->x_flag_wrapv got set. * fold-const.c (fold_comparison, fold_binary_loc): Revert 2017-08-01 changes, just use TYPE_OVERFLOW_UNDEFINED on pointer type instead of POINTER_TYPE_OVERFLOW_UNDEFINED. * match.pd: Likewise in address comparison pattern. * doc/invoke.texi: Document -fwrapv and -fstrict-overflow. * gcc.dg/no-strict-overflow-7.c: Revert 2017-08-01 changes. * gcc.dg/tree-ssa/pr81388-1.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/fold-const.c trunk/gcc/match.pd trunk/gcc/opts.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/no-strict-overflow-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81388-1.c trunk/gcc/tree.h
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #15 from Jakub Jelinek --- Created attachment 43116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43116=edit gcc8-pr82694.patch So like this untested patch? Certainly don't have energy to look for all other spots that might need similar treatment, on the other side, not sure how far we really need to go in working around buggy code. If the kernel works with it, perhaps that is enough (and even for the kernel would be if they fix their mess). All the patch does is introduce the new option and revert the patch using the new macros.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #14 from Richard Biener --- (In reply to Jakub Jelinek from comment #13) > Does the kernel still need this workaround? Shall we just add the option > and gradually add the checks? Yes - note I got stuck in the attempt to do the -f[no-]strict-overflow aliasing in common.opt in a way to also cover this new option and then forgot about it. Appearantly we can't have two Aliases nor does EnabledBy work here :/ Also note my remark on not re-introducing POINTER_OVERFLOW_UNDEFINED but instead allowing TYPE_OVERFLOW_* on pointers. Want to give it a try?
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Does the kernel still need this workaround? Shall we just add the option and gradually add the checks?
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #12 from Richard Biener --- Note though that there were _many_ foldings not properly guarded by POINTER_TYPE_OVERFLOW_UNDEFINED. I'd rather fold that into TYPE_OVERFLOW_UNDEFINED / TYPE_OVERFLOW_WRAPS anyway (thus also allow those on pointer types).
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||rguenth at gcc dot gnu.org
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #11 from Richard Biener --- Rather than reverting I'd add fwrapp Common Report Var(flag_wrapp) Optimization Assume pointer arithmetic overflow wraps around. and adjust fstrict-overflow to also enable fwrapp. Maybe we need to change that away from an alias and instead add EnabledBy(fno-strict-overflow) to both fwrapv and fwrapp. So yes, I think we probably need a way to enable pointer wrapping and -fno-strict-overflow should do that.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #10 from amker at gcc dot gnu.org --- (In reply to amker from comment #9) > (In reply to Markus Trippelsdorf from comment #8) > > I think -fno-strict-overflow/-fwrapv should use the old behavior. > > The kernel really needs a flag to control pointer wrapping. > > Well, GCC doesn't provide such a flag now. Before the change, it was > -fno-strict-overflow/-fwrapv. And the support for wrapping pointer is far > from complete, that's one point of the change. Oh, sorry for mis-understanding, now I see you prefer to revert the change :)
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #9 from amker at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #8) > I think -fno-strict-overflow/-fwrapv should use the old behavior. > The kernel really needs a flag to control pointer wrapping. Well, GCC doesn't provide such a flag now. Before the change, it was -fno-strict-overflow/-fwrapv. And the support for wrapping pointer is far from complete, that's one point of the change.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #8 from Markus Trippelsdorf --- I think -fno-strict-overflow/-fwrapv should use the old behavior. The kernel really needs a flag to control pointer wrapping.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-25 Ever confirmed|0 |1
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #7 from amker at gcc dot gnu.org ---
I didn't go through all the differences, but below is an example of using
wrapping behavior for pointers:
int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
unsigned long long num;
char *str, *end;
struct printf_spec spec = {0};
//...
str = buf;
end = buf + size;
if (end < buf) {
end = ((void *)-1);
size = end - buf;
}
//...
}
int vsprintf(char *buf, const char *fmt, va_list args)
{
return vsnprintf(buf, ((int)(~0U>>1)), fmt, args);
}
So vsnprintf get 0x7fff as the second argument, the comparison between end
and buf gets folded with undefined overflow behavior assumption.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #6 from Markus Trippelsdorf --- Created attachment 42458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42458=edit assembly good
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #5 from Markus Trippelsdorf --- Created attachment 42457 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42457=edit assembly bad
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #4 from Markus Trippelsdorf --- Created attachment 42456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42456=edit unreduced testcase The unreduced testcase is attached. % /home/trippels/gcc_bad/usr/local/bin/gcc -fno-strict-overflow -O3 -S vsprintf.i vs. % /home/trippels/gcc_good/usr/local/bin/gcc -fno-strict-overflow -O3 -S vsprintf.i % diff -u vsprintf_good.s vsprintf_bad.s --- vsprintf_good.s 2017-10-24 10:57:50.797502298 +0200 +++ vsprintf_bad.s 2017-10-24 10:57:34.977480296 +0200 @@ -5711,7 +5711,6 @@ pushq %r14 .cfi_def_cfa_offset 24 .cfi_offset 14, -24 - movq%rsi, %r15 pushq %r13 .cfi_def_cfa_offset 32 .cfi_offset 13, -32 @@ -5722,67 +5721,55 @@ pushq %rbp .cfi_def_cfa_offset 48 .cfi_offset 6, -48 - leaq2147483647(%rdi), %rbp pushq %rbx .cfi_def_cfa_offset 56 .cfi_offset 3, -56 - movq%rdx, %r12 - movq%rdi, %rbx + leaq2147483647(%rdi), %r12 subq$40, %rsp .cfi_def_cfa_offset 96 - cmpq%rbp, %rdi - movq$0, 24(%rsp) - jbe .L846 cmpb$0, (%rsi) - movq%rdi, %rax - movq$-1, %rbp - notq%rax - movq%rax, (%rsp) - je .L847 + movq$0, 24(%rsp) + je .L925 + movq%rsi, %r14 + movq%rdx, %rbp + movq%rdi, %rbx .p2align 4,,10 .p2align 3 -.L925: +.L922: leaq24(%rsp), %rsi - movq%r15, %rdi + movq%r14, %rdi callformat_decode movzbl 24(%rsp), %edx movslq %eax, %rcx - leaq(%r15,%rcx), %r14 + leaq(%r14,%rcx), %r15 cmpb$7, %dl - ja .L848 - jmp *.L850(,%rdx,8) + ja .L847 + jmp *.L849(,%rdx,8) .section.rodata .align 8 .align 4 ... etc.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #3 from amker at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #2) > I would not revert without a testcase. Give me a few hours... Thanks very much for helping!
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #2 from Markus Trippelsdorf --- I would not revert without a testcase. Give me a few hours...
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #1 from amker at gcc dot gnu.org --- Sorry for the breakage. As I mentioned when committing the patch, it's kind of an experiment and we can always revert it. I can revert it now, but a test case for further investigation would be highly appreciated. As for the patch, it doesn't change behavior when !flag_wrapv. I assume the difference comes from explicitly specified -fwrapv option. Described by fwrapv document: fwrapv Common Report Var(flag_wrapv) Optimization Assume signed arithmetic overflow wraps around. It indicates wrap behavior for signed arithmetic overflow. This is not accurate before this patch, because apparently it also covers wrap behavior for pointer/memory_object. Unfortunately, it's not always the case because there are lots of code ignoring possible pointer wrap when fwrapv is specified. I can see GCC has the inconsistency issue here, unfortunately no easy way out. Last question is, does the code in kernel really depends on wrapping pointer arithmetic overflow behavior. The code itself can be fixed if not. Anyway, it's hard to tell without a test case. Hi richi, any comment before I revert the patch? Thanks.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Richard Biener changed: What|Removed |Added Component|tree-optimization |middle-end Target Milestone|--- |8.0
