[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #20 from Martin Liška --- Then fixed.
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 --- Comment #15 from Marc Glisse --- (In reply to Joost VandeVondele from comment #13) > Shouldn't disabling this be language dependent ? I.e. in Fortran this > transformation is always valid (as integers in conforming programs are > always in the symmetric range). Out of curiosity, does fortran convey this information to the middle-end somehow, maybe assigning a value range to SSA_NAMEs during gimplification?
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- I think it doesn't. Plus, am not sure if it would be safe to use it everywhere in the middle-end (plus, what about LTO, e.g. when you mix C/C++/... and Fortran code), while user code should not end up with this values, I'd artificial compiler generated code could still trigger those.
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 --- Comment #17 from Marc Glisse --- (In reply to Jakub Jelinek from comment #16) > I think it doesn't. Plus, am not sure if it would be safe to use it > everywhere in the middle-end (plus, what about LTO, e.g. when you mix > C/C++/... and Fortran code), Yes, I was thinking about having the front-end add this information when it produces the initial gimple. But value ranges go with SSA_NAMEs, and front-ends are more familiar with variables, so I don't know how hard it would be. > while user code should not end up with this > values, I'd artificial compiler generated code could still trigger those. Is there already a lot of artificial code at that stage (that the front-end does not clearly identify as such)? (just discussing this in passing, I have no particular interest in fortran)
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Sat Jan 9 07:37:04 2016 New Revision: 232188 URL: https://gcc.gnu.org/viewcvs?rev=232188=gcc=rev Log: PR middle-end/50865 PR tree-optimization/69097 * fold-const.h (expr_not_equal_to): New prototype. * fold-const.c: Include stringpool.h and tree-ssanames.h. (expr_not_equal_to): New function. * match.pd (X % -Y is the same as X % Y): Don't optimize unless X is known not to be equal to minimum or Y is known not to be equal to -1. * tree-vrp.c (simplify_div_or_mod_using_ranges): Add GSI argument. fold TRUNC_MOD_EXPR if the second argument is not a power of two. (simplify_stmt_using_ranges): Adjust caller. (vrp_finalize): Call set_value_range on SSA_NAMEs before calling substitute_and_fold. * gcc.c-torture/execute/pr50865.c: New test. * gcc.c-torture/execute/pr69097-1.c: New test. * gcc.c-torture/execute/pr69097-2.c: New test. * gcc.dg/pr69097-1.c: New test. * gcc.dg/pr69097-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr50865.c trunk/gcc/testsuite/gcc.c-torture/execute/pr69097-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr69097-2.c trunk/gcc/testsuite/gcc.dg/pr69097-1.c trunk/gcc/testsuite/gcc.dg/pr69097-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/fold-const.h trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Bug 50865 depends on bug 69097, which changed state. Bug 69097 Summary: [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69097 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 --- Comment #19 from Jakub Jelinek --- Fixed for 6+.
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.5 |---
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added Attachment #34323|0 |1 is obsolete|| --- Comment #14 from Mikael Pettersson mikpelinux at gmail dot com --- Created attachment 34328 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34328action=edit patch revised to always allow the transformation for Fortran Patch revised to not restrict the transformation for Fortran, since the X != INT_MIN condition apparently is an invariant there.
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #12 from Mikael Pettersson mikpelinux at gmail dot com --- Created attachment 34323 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34323action=edit patch restricting the X % -Y - X % Y transformation to when it's safe This proposed patch restricts the X % -Y - X % Y transformation to cases when we can be certain that it doesn't result in undefined behaviour, i.e. when Y != 1 or X != INT_MIN. Passes bootstrap and testsuite on x86_64-linux so far.
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Mikael Pettersson from comment #12) Created attachment 34323 [details] patch restricting the X % -Y - X % Y transformation to when it's safe This proposed patch restricts the X % -Y - X % Y transformation to cases when we can be certain that it doesn't result in undefined behaviour, i.e. when Y != 1 or X != INT_MIN. Passes bootstrap and testsuite on x86_64-linux so far. Shouldn't disabling this be language dependent ? I.e. in Fortran this transformation is always valid (as integers in conforming programs are always in the symmetric range).
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.4 |4.8.5 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 4.8.4 has been released.
[Bug middle-end/50865] Invalid code generation for INT64_MIN % 1 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Component|tree-optimization |middle-end Target Milestone|--- |4.8.4 Severity|blocker |normal
