[Bug c++/91987] -fstrict-eval-order issues

2020-01-27 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/91987] -fstrict-eval-order issues

2019-10-11 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #11 from Jakub Jelinek --- Partially fixed, the call argument issue is unresolved, and I guess some analysis about say .*/->* is needed too.

[Bug c++/91987] -fstrict-eval-order issues

2019-10-11 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Oct 11 07:36:07 2019 New Revision: 276860 URL: https://gcc.gnu.org/viewcvs?rev=276860&root=gcc&view=rev Log: PR c++/91987 cp/ * decl2.c (grok_array_decl): For -fstron

[Bug c++/91987] -fstrict-eval-order issues

2019-10-05 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #9 from Jakub Jelinek --- Another testcase for the same reason as above: int a[4] = { 1, 2, 3, 4 }; int c; int main () { int *x = a; c = 1; int r = (c = 4, x)[(c *= 2, 3)]; if (c != 8 || r != 3) __builtin_abort (); c =

[Bug c++/91987] -fstrict-eval-order issues

2019-10-05 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #8 from Jakub Jelinek --- Another testcase, another reason: int a[4] = { 1, 2, 3, 4 }; int b[4] = { 5, 6, 7, 8 }; int foo (void) { int *x = a; int r = x[(x = b, 3)]; if (x != b) __builtin_abort (); return r; } int main (

[Bug c++/91987] -fstrict-eval-order issues

2019-10-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #7 from Jakub Jelinek --- So, if clang is right here, we'd need to force arguments not just with is_gimple_reg_type, but also with all other types that are not TREE_ADDRESSABLE, into temporaries (perhaps with a first check we really n

[Bug c++/91987] -fstrict-eval-order issues

2019-10-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #6 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #4) > Probably, but aggregate copy of TREE_ADDRESSABLE aggregates might be a > problem. > For the arguments, I'm not planning to do anything myself, because I don't > u

[Bug c++/91987] -fstrict-eval-order issues

2019-10-04 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #5 from rguenther at suse dot de --- On Fri, 4 Oct 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 > > --- Comment #4 from Jakub Jelinek --- > (In reply to rguent...@suse.de from comment #

[Bug c++/91987] -fstrict-eval-order issues

2019-10-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #4 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #3) > Ick. I'd say we should unconditionally guard the transform > with the appropriate TREE_SIDE_EFFECTS check? See above, wouldn't that mean throwing the optimi

[Bug c++/91987] -fstrict-eval-order issues

2019-10-04 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #3 from rguenther at suse dot de --- On Fri, 4 Oct 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 > > --- Comment #2 from Jakub Jelinek --- > So for the shifts we'd need additionally: > -

[Bug c++/91987] -fstrict-eval-order issues

2019-10-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #2 from Jakub Jelinek --- So for the shifts we'd need additionally: --- gcc/fold-const.c.jj 2019-09-02 15:29:34.548515139 +0200 +++ gcc/fold-const.c2019-10-04 10:44:23.319883187 +0200 @@ -9447,16 +9447,23 @@ fold_binary_loc (locat

[Bug c++/91987] -fstrict-eval-order issues

2019-10-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987 --- Comment #1 from Jakub Jelinek --- To sum up IRC discussion with richi, he doesn't want this to be in the gimplifier, as it is one FE specific, which means cp-gimplify.c is where this needs to be done. Furthermore, if we there have a predicate