[Bug c/38969] [4.3/4.4 Regression] -foptimize-sibling-calls generates wrong code on alpha

[ubizjak at gmail dot com]

------- Comment #3 from ubizjak at gmail dot com  2009-01-26 17:20 -------
Following patch fixes this problem:

--cut here--
Index: calls.c
===================================================================
--- calls.c     (revision 143671)
+++ calls.c     (working copy)
@@ -992,7 +992,6 @@ initialize_argument_information (int num
            && targetm.calls.split_complex_arg (argtype))
          {
            tree subtype = TREE_TYPE (argtype);
-           arg = save_expr (arg);
            args[j].tree_value = build1 (REALPART_EXPR, subtype, arg);
            j += inc;
            args[j].tree_value = build1 (IMAGPART_EXPR, subtype, arg);
--cut here--

This testcase triggered sibcall_failure in the loop inside expand_call
function. We expanded complex argument during sibcall sequence expansion and
due to sibcall_failure, we throw produced sequence away.

Since the complex argument was wrapped in SAVE_EXPR, we were not able to
correctly expand function argument during second pass. The argument was already
expanded to a temporary, but the initialization of a temporary was discarded...

This worked in gcc-4.2 (it produces the same initial RTL sequence as unpatched
gcc-4.3/gcc-4.4) since no later pass initializes unintialized registers to
zero. This functionality was introduced by dataflow merge and this bug was
_exposed_ by the merge.

Regression test is in progress...


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|-foptimize-sibling-calls    |[4.3/4.4 Regression] -
                   |generates wrong code on     |foptimize-sibling-calls
                   |alpha                       |generates wrong code on
                   |                            |alpha
   Target Milestone|---                         |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38969