| Summary: | [8/9 Regression] Different results between gcc-9 and gcc-6 | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Karine EM <karine.even_mendoza> |
| Component: | tree-optimization | Assignee: | Jakub Jelinek <jakub> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 141242068, amonakov, jakub, karine.even_mendoza |
| Priority: | P2 | Keywords: | wrong-code |
| Version: | 9.2.1 | ||
| Target Milestone: | 8.5 | ||
| Host: | Target: | ||
| Build: | Known to work: | 6.5.0 | |
| Known to fail: | 10.0, 7.5.0, 8.4.0, 9.3.0 | Last reconfirmed: | 2020-04-27 00:00:00 |
| Attachments: | gcc10-pr94809.patch | ||
With -fsanitize=undefined the result is correct. Regression started with r236882 PR tree-optimization/71289 * match.pd (-1 / B < A, A > -1 / B): New transformations. That folds it into IMAGPART_EXPR <.MUL_OVERFLOW ((long long unsigned int) a++ , one)> != 0 which looks correct, but somewhere later the side-effect is dropped. Created attachment 48390 [details] gcc10-pr94809.patch Untested fix. LGTM The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:34f6b14ff33e0c64b3a4a1a2cd871df715d69151 commit r10-8009-g34f6b14ff33e0c64b3a4a1a2cd871df715d69151 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Apr 28 11:26:56 2020 +0200 tree: Fix up TREE_SIDE_EFFECTS on internal calls [PR94809] On the following testcase, match.pd during GENERIC folding changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y), but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on the call. There is the process_call_operands function that non-internal call creation calls and it is usable for internal calls too, e.g. TREE_SIDE_EFFECTS is derived from checking whether the call has side-effects (non-ECF_{CONST,PURE}; we have those for internal calls) and from whether any of the arguments has TREE_SIDE_EFFECTS. 2020-04-28 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/94809 * tree.c (build_call_expr_internal_loc_array): Call process_call_operands. * gcc.c-torture/execute/pr94809.c: New test. Fixed for 10.1 for now. The releases/gcc-9 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:522022361984407ebc84cde22bdbd199261d0443 commit r9-8888-g522022361984407ebc84cde22bdbd199261d0443 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Apr 28 11:26:56 2020 +0200 tree: Fix up TREE_SIDE_EFFECTS on internal calls [PR94809] On the following testcase, match.pd during GENERIC folding changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y), but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on the call. There is the process_call_operands function that non-internal call creation calls and it is usable for internal calls too, e.g. TREE_SIDE_EFFECTS is derived from checking whether the call has side-effects (non-ECF_{CONST,PURE}; we have those for internal calls) and from whether any of the arguments has TREE_SIDE_EFFECTS. 2020-04-28 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/94809 * tree.c (build_call_expr_internal_loc_array): Call process_call_operands. * gcc.c-torture/execute/pr94809.c: New test. (cherry picked from commit 34f6b14ff33e0c64b3a4a1a2cd871df715d69151) Fixed for 8.5 in r8-10494-g1831242824752a6c51f513759830a8667a97f7f2 and by the above commit for 9.4+ too. *** Bug 104983 has been marked as a duplicate of this bug. *** |
Seen on: 18.04.4 LTS kar@kar-VirtualBox:~/ex1$ gcc-9 ex2.c -o ex kar@kar-VirtualBox:~/ex1$ ./ex 0 kar@kar-VirtualBox:~/ex1$ gcc-6 ex2.c -o ex kar@kar-VirtualBox:~/ex1$ ./ex 1 kar@kar-VirtualBox:~/ex1$ more ex2.c #include <stdio.h> int main() { int a = 0; unsigned long long one = 1; ((18446744073709551615UL / one) < a++, one); printf("%d\n", a); } === 1. Output shall be 1 instead of 0. 2. GCC-7, GCC-8, GCC-9 and HEAD 562bfb1 produce 0. gcc-9 (Ubuntu 9.2.1-17ubuntu1~18.04.1) 9.2.1 20191102 gcc-8 (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0 gcc-7 (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 gcc-6 (Ubuntu 6.5.0-2ubuntu1~18.04) 6.5.0 20181026 compiled: gcc-9 ex2.c -o ex 3. Explanation: ((18446744073709551615UL / one) < a++, one); the part before "," is skipped including the increase of "a" by "1" (a++). As a result the printf outputs 0 instead of 1. 4. GCC-6 and LLVM (for example) produce 1. Note: You can try to compile the code with GCC-6 or llvm to observe the behaviour where the output is 1.