[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #13 from jakub at gcc dot gnu dot org 2007-06-20 09:24 --- Fixed in SVN, the performance regression caused by PR25550 patch is still present though. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #12 from jakub at gcc dot gnu dot org 2007-06-20 06:50 --- Subject: Bug 32285 Author: jakub Date: Wed Jun 20 06:50:23 2007 New Revision: 125879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125879 Log: PR middle-end/32285 * calls.c (precompute_arguments): Also precompute CALL_EXPR arguments if ACCUMULATE_OUTGOING_ARGS. * gcc.c-torture/execute/20070614-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20070614-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/calls.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #11 from jakub at gcc dot gnu dot org 2007-06-20 06:44 --- Subject: Bug 32285 Author: jakub Date: Wed Jun 20 06:44:26 2007 New Revision: 125877 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125877 Log: PR middle-end/32285 * calls.c (precompute_arguments): Also precompute CALL_EXPR arguments if ACCUMULATE_OUTGOING_ARGS. * gcc.c-torture/execute/20070614-1.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/20070614-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/calls.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #10 from jakub at gcc dot gnu dot org 2007-06-20 06:36 --- Subject: Bug 32285 Author: jakub Date: Wed Jun 20 06:35:55 2007 New Revision: 125873 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125873 Log: PR middle-end/32285 * calls.c (precompute_arguments): Also precompute CALL_EXPR arguments if ACCUMULATE_OUTGOING_ARGS. * gcc.c-torture/execute/20070614-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070614-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #9 from jakub at gcc dot gnu dot org 2007-06-15 11:27 --- *** Bug 30493 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||sam at sambromley dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00973.html Status|NEW |ASSIGNED Last reconfirmed|2007-06-12 10:05:44 |2007-06-15 08:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #8 from jakub at gcc dot gnu dot org 2007-06-14 08:03 --- Yes, I mean performance and size regressions. But your changes to tree-nrv never mentioned you found bugs in it and therefore are making NRV more strict, on the contrary, PR25505 was fixing a performance/size issue where NRV was too strict and your patch was meant to make it less strict, at least that's what I understood from the gcc-patches thread. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #7 from jconner at apple dot com 2007-06-13 17:09 --- (In reply to comment #6) > I see that PR25505 caused a bunch of code generation regressions. > On i?86, with -O2 -m32: > ... When you say regressions, I assume you mean size/performance, not correctness, right? If so, that's to be expected, as the previous tree-nrv implementation was being overly permissive, and the new implementation is conservatively pessimistic, as the comments indicate. If I have introduced anything incorrect, please let me know and I'd be glad to take a look. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #6 from jakub at gcc dot gnu dot org 2007-06-13 15:22 --- I see that PR25505 caused a bunch of code generation regressions. On i?86, with -O2 -m32: _Complex double foo (_Complex double x) { return __builtin_cexp (x); } generated code got much worse, similarly: elemental function specific__exp_c8 (parm) complex (kind=8), intent (in) :: parm complex (kind=8) :: specific__exp_c8 specific__exp_c8 = exp (parm) end function In the above 2 cases, dest_safe_for_nrv_p is called on an SSA_NAME. At least in these cases it should be safe to use SSA_NAME_VAR, shouldn't it? A different testcase that regressed is: struct P { long long l; int a; unsigned int b; P(long long x) : l(x) {} }; P foo (P); P bar (P); P foo (P x) { P y = P (-1LL); y = bar (x); return y; } Here dest_safe_for_nrv_p is passed a RESULT_DECL and is again something that ought to be optimized out, but is not any longer. static bool dest_safe_for_nrv_p (tree dest, location_t *loc) { subvar_t subvar; while (handled_component_p (dest)) dest = TREE_OPERAND (dest, 0); if (! SSA_VAR_P (dest)) return false; if (TREE_CODE (dest) == SSA_NAME) dest = SSA_NAME_VAR (dest); if (is_call_clobbered (dest)) return false; for (subvar = get_subvars_for_var (dest); subvar; subvar = subvar->next) if (is_call_clobbered (subvar->var)) return false; return true; } handles all of these (i.e. doesn't regress on any of them). I have verified that it e.g. refuses to NRV optimize: struct P { long long l; int a; unsigned int b; P(long long x) : l(x) {} }; P foo (P); P bar (P); void baz (P *); P foo (P x) { P y = P (-1LL); baz (&y); y = bar (x); return y; } because the RESULT_DECL escapes. It regresses on the initial testcase from this bugreport, so it would mean writing a different bugfix (most probably in calls.c, check that the target doesn't overlap with the arguments being pushed), but it might very well be worth it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 10:05 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-12 10:05:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #4 from jconner at apple dot com 2007-06-11 18:59 --- Sorry, yes, reading back I wasn't being very clear. I meant to say that the impression I was left with was that it wasn't a result of my change, but of the test environment, an idea which was supported by my own benchmarking results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-11 18:36 --- Actually IIRC the machine's glibc was upgaded at the same time. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #2 from jconner at apple dot com 2007-06-11 16:06 --- (In reply to comment #1) > Looking at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00951.html > I'm slightly worried about backporting this to gcc-4_1-branch though. > Has that been resolved? I recall being told that the problem was most likely the benchmarks, and that I shouldn't worry about it. Unfortunately, it must have been off-list, because I can't find anything in the email archives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #1 from jakub at gcc dot gnu dot org 2007-06-11 15:43 --- Looking at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00951.html I'm slightly worried about backporting this to gcc-4_1-branch though. Has that been resolved? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285