[Bug middle-end/37316] New: [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[Bug middle-end/37316] New: [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/931004-1.c  -w  -O0   -lm  
-
o /test/gnu/gcc/objdir/gcc/testsuite/gcc/931004-1.x0    (timeout = 300)
PASS: gcc.c-torture/execute/931004-1.c compilation,  -O0 
Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc::/test/gnu/gcc/objdir/gcc
FAIL: gcc.c-torture/execute/931004-1.c execution,  -O0


-- 
           Summary: [4.4 Regression] Small structs are not passed correctly
                    on hppa64-*-*
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #1 from danglin at gcc dot gnu dot org  2008-09-01 18:28 -------
gcc.c-torture/execute/931004-3.c, gcc.c-torture/execute/931004-7.c and
gcc.c-torture/execute/931005-1.c also fail.  These fails appear related.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #2 from danglin at gcc dot gnu dot org  2008-09-01 20:19 -------
Also, these seem related:

FAIL: gcc.dg/torture/pr30665-2.c  -O0  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O1  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O2  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O3 -g  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -Os  execution test


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|---                         |4.4.0


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #3 from danglin at gcc dot gnu dot org  2008-09-06 01:23 -------
This problem was introduced in revision 137326.  Removing the PARALLEL
breaks argument passing on this target.  See the comment in pa.c,
function_arg, regarding argument justification on a big-endian target.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drow at gcc dot gnu dot org


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2008-09-06 01:43 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

> This problem was introduced in revision 137326.  Removing the PARALLEL
> breaks argument passing on this target.  See the comment in pa.c,
> function_arg, regarding argument justification on a big-endian target.

I also want to add that there are some non BLKMODE cases used in
the 32-bit hppa runtimes.

Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[drow at gcc dot gnu dot org]

------- Comment #5 from drow at gcc dot gnu dot org  2008-09-09 03:16 -------
That patch isn't supposed to make any difference, because of when the parallel
is removed - it's not supposed to be early enough to affect where things are
passed.  It just happens within the function.

Unfortunately I'm not going to have a chance to look at this for a while :-(


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-22 14:28 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

>            Priority|P3                          |P1

I haven't had a chance to look at this any further but this regression
is fixed by reverting the change(s) previously identified.

Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2008-10-22 15:37 -------
Was the "I am reasonably sure it will only affect only E500" comment in
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00255.html
meant for this patch or the other one?
Clearly it makes a big difference.
I think the bug is that emit_group_store is called with NULL_TREE third
argument (the type) in the new assign_parm_remove_parallels function, while
previously
it has been called sometimes with NULL_TREE (if nominal_mode != passed_mode) or
nominal_type (if the modes are the same) or with passed_type in another part of
the routine.  And on PA BLOCK_REG_PASSING depends on the type, particularly has
different results if type is non-NULL and aggregate vs. NULL or non-aggregate.

--- function.c.jj10     2008-09-30 16:57:11.000000000 +0200
+++ function.c  2008-10-22 17:32:26.000000000 +0200
@@ -2436,7 +2436,9 @@ assign_parm_remove_parallels (struct ass
   if (GET_CODE (entry_parm) == PARALLEL && GET_MODE (entry_parm) != BLKmode)
     {
       rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm));
-      emit_group_store (parmreg, entry_parm, NULL_TREE,
+      emit_group_store (parmreg, entry_parm,
+                       data->nominal_mode == data->passed_mode
+                       ? data->passed_type : NULL_TREE,
                        GET_MODE_SIZE (GET_MODE (entry_parm)));
       entry_parm = parmreg;
     }
patch fixes this for me (at least, from eyeballing assembly and/or RTL from a
cross compiler), though I'm not sure if data->passed_type or data->nominal_type
should be used and whether the data->nominal_mode == data->passed_mode guard is
needed or not.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[drow at gcc dot gnu dot org]

------- Comment #8 from drow at gcc dot gnu dot org  2008-10-22 15:48 -------
Subject: Re:  [4.4 Regression] Small structs are not
        passed correctly on hppa64-*-*

On Wed, Oct 22, 2008 at 03:37:09PM -0000, jakub at gcc dot gnu dot org wrote:
> Was the "I am reasonably sure it will only affect only E500" comment in
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00255.html
> meant for this patch or the other one?
> Clearly it makes a big difference.

It was meant for this patch; for the other, I was absolutely sure.
Your explanation makes sense to me.  I have the same questions you do,
too; I got completely lost in the different modes/types being dealt
with here.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2008-10-22 19:00 -------
I think either data->passed_type being passed always, or what I've posted,
should be correct.  emit_group_store is run on the hard register(s) in which it
is passed, so using data->nominal_type would be unexpected.

Eric, what do you think?


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-23 13:25 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

> --- function.c.jj10     2008-09-30 16:57:11.000000000 +0200
> +++ function.c  2008-10-22 17:32:26.000000000 +0200
> @@ -2436,7 +2436,9 @@ assign_parm_remove_parallels (struct ass
>    if (GET_CODE (entry_parm) == PARALLEL && GET_MODE (entry_parm) != BLKmode)
>      {
>        rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm));
> -      emit_group_store (parmreg, entry_parm, NULL_TREE,
> +      emit_group_store (parmreg, entry_parm,
> +                       data->nominal_mode == data->passed_mode
> +                       ? data->passed_type : NULL_TREE,
>                         GET_MODE_SIZE (GET_MODE (entry_parm)));
>        entry_parm = parmreg;
>      }
> patch fixes this for me (at least, from eyeballing assembly and/or RTL from a
> cross compiler), though I'm not sure if data->passed_type or data->nominal_type
> should be used and whether the data->nominal_mode == data->passed_mode guard is
> needed or not.

This fixes the PR.  I will try the version without the guard when the
testsuite run completes this morning.

Thanks,
Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #11 from danglin at gcc dot gnu dot org  2008-10-23 16:04 -------
*** Bug 37320 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #12 from danglin at gcc dot gnu dot org  2008-10-23 16:05 -------
*** Bug 37318 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #13 from danglin at gcc dot gnu dot org  2008-10-23 16:15 -------
Looking at the test results with the fix proposed in comment #10,
I see we still have the failure of the following two tests:

FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-by-value-12 c_compat_x_tst.o-c_compat_y_tst.o
execute 

See <http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01604.html>.

This didn't happen with Daniel's changes reverted.  See for example
<http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01144.html>. 


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

------- Comment #14 from jakub at gcc dot gnu dot org  2008-10-23 20:25 -------
Can you please look at the testcases why they fail (what is passed differently)
and try to minimize them as much as possible?  Finding a bug in RTL or assembly
without knowing what you are looking for is certainly harder than when you have
a debugger and can see what is passed differently...

Thanks.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-23 20:47 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

> Can you please look at the testcases why they fail (what is passed differently)
> and try to minimize them as much as possible?  Finding a bug in RTL or assembly
> without knowing what you are looking for is certainly harder than when you have
> a debugger and can see what is passed differently...

Will do.

Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-25 01:11 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

> Can you please look at the testcases why they fail (what is passed differently)
> and try to minimize them as much as possible?  Finding a bug in RTL or assembly
> without knowing what you are looking for is certainly harder than when you have
> a debugger and can see what is passed differently...

The following is a simplification of the first failure in
gcc.dg/compat/scalar-by-value-4.

_Complex char g01cc;

void
initcc (_Complex char *p, _Complex char v)
{
  *p = v + (0 + 1 * __extension__ 1i);
}

void
checkcc (_Complex char x, _Complex char v)
{
  if (x != v + (0 + 1 * __extension__ 1i)) abort ();
}

void
checkgcc (void)
{
  checkcc (g01cc, 1);
}

int
main ()
{
  initcc (&g01cc, 1);
  checkgcc ();
  return 0;
}

The first argument passed to checkcc is wrong.  The value passed in
r26 (the first argument register) is 1.  4.3.2 passed 0x101.  The value
passed for v is 0x100 in both versions.

Now, as I understand the 64-bit runtime specification for hppa64-hpux,
neither GCC version is correct.  However, I don't believe HP cc or aCC
supports integer complex values, so I can't check for consistency.
My understanding is that small structs and aggregates should be left
justified.  This unfortunately differs from the right justification
used on most big endian targets.  I believe tha correct value for
x and v should be 0x0101000000000000 and 0x010000000000000, respectively.

I have checked that the struct { byte x; byte y } is correctly left
justified.

Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2008-10-25 10:47 -------
I'd say this is a bug in emit_group_store, but I'd fear how many ports will
break
if we touch it.

emit_group_store clearly doesn't care about BLOCK_REG_PADDING if dst is CONCAT,
I think the code pretty much assumes that GET_MODE_SIZE (dest_mode) ==
GET_MODE_SIZE (tmps[i]).  If bytepos, adj_bytelen pair pick up just the first
or second register of the CONCAT, then it is I think fine, the code falls
through
into the optional down shift depending on BLOCK_REG_PADDING and store_bit_field
which always takes lsb bits from tmps[i].
But for the case where both regs of the CONCAT need to be set, nothing
considers BLOCK_REG_PADDING at all.  In the GET_MODE_ALIGNMENT (dest_mode) <
GET_MODE_ALIGNMENT (tmp_mode) case, it would be enough just to add some offset
to the address depending on BLOCK_REG_PADDING, but in the other case we might
be even allocating a stack slot smaller than needed.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-25 16:53 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

> emit_group_store clearly doesn't care about BLOCK_REG_PADDING if dst is CONCAT,
> I think the code pretty much assumes that GET_MODE_SIZE (dest_mode) ==
> GET_MODE_SIZE (tmps[i]).  If bytepos, adj_bytelen pair pick up just the first
> or second register of the CONCAT, then it is I think fine, the code falls
> through
> into the optional down shift depending on BLOCK_REG_PADDING and store_bit_field
> which always takes lsb bits from tmps[i].
> But for the case where both regs of the CONCAT need to be set, nothing
> considers BLOCK_REG_PADDING at all.  In the GET_MODE_ALIGNMENT (dest_mode) <
> GET_MODE_ALIGNMENT (tmp_mode) case, it would be enough just to add some offset
> to the address depending on BLOCK_REG_PADDING, but in the other case we might
> be even allocating a stack slot smaller than needed.

Regarding BLOCK_REG_PADDING, there is a bug in function_arg_padding in pa.c.
It is not handling complex and vector types.  This explains the incorrect
padding.  The test in comment #16 passes with the following change:

Index: config/pa/pa.c
===================================================================
--- config/pa/pa.c      (revision 141361)
+++ config/pa/pa.c      (working copy)
@@ -5888,7 +5888,11 @@
 function_arg_padding (enum machine_mode mode, const_tree type)
 {
   if (mode == BLKmode
-      || (TARGET_64BIT && type && AGGREGATE_TYPE_P (type)))
+      || (TARGET_64BIT
+         && type
+         && (AGGREGATE_TYPE_P (type)
+             || TREE_CODE (type) == COMPLEX_TYPE
+             || TREE_CODE (type) == VECTOR_TYPE)))
     {
       /* Return none if justification is not required.  */
       if (type
@@ -9277,7 +9281,7 @@
              offset += 8;
            }

-         return gen_rtx_PARALLEL (mode, gen_rtvec_v (ub, loc));
+         return gen_rtx_PARALLEL (BLKmode, gen_rtvec_v (ub, loc));
        }
      }
   else

The latter hunk works around the incorrect argument value passed
from checkgcc to checkcc when downward padding is specified.  The
idea was simply that BLOCK_REG_PADDING applies to blocks.  The
32-bit code already uses BLKmode.

This bug went away when I changed the padding for complex and vector
types to upward.

I'm not sure why Daniel's change exposed this problem, but is
probably a separate issue.

Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-25 17:48 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

> @@ -9277,7 +9281,7 @@
>  	      offset += 8;
>  	    }
>  
> -	  return gen_rtx_PARALLEL (mode, gen_rtvec_v (ub, loc));
> +	  return gen_rtx_PARALLEL (BLKmode, gen_rtvec_v (ub, loc));
>  	}
>       }
>    else

Actually, I see that by treating aggregate, complex and vector arguments
as BLKmode, we avoid the conversion of the PARALLEL to a REG (i.e., the
call to emit_group_store in assign_parm_remove_parallels).  Given the
issues Jakub pointed out with emit_group_store, this seems desireable
but I'm not sure.

Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #20 from danglin at gcc dot gnu dot org  2008-10-27 01:17 -------
Subject: Bug 37316

Author: danglin
Date: Mon Oct 27 01:16:13 2008
New Revision: 141380

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141380
Log:

2008-10-26  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

        PR middle-end/37316
        * pa.c (function_arg_padding):  Pad complex and vector types upward in
        64-bit runtime.
        (function_arg): Use BLKmode for PARALLEL in 64-bit runtime.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/pa/pa.c


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

------- Comment #21 from jakub at gcc dot gnu dot org  2008-10-27 07:08 -------
Note that if you pad upward COMPLEX_TYPE (an ABI change), then just the
assign_parm_remove_parallel fix should be enough and you could avoid passing
everything in BLKmode (which pessimizes the code), because the emit_group_store
bug only affects arguments that aren't passed in the first bytes of the
register.


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[ebotcazou at gcc dot gnu dot org]

------- Comment #22 from ebotcazou at gcc dot gnu dot org  2008-10-27 09:53 -------
[Sorry about the delay]

> I think either data->passed_type being passed always, or what I've posted,
> should be correct.  emit_group_store is run on the hard register(s) in which it
> is passed, so using data->nominal_type would be unexpected.

Yes, I think your final patch (always passing data->passed_type) makes sense as
it's the simplest and most consistent approach.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-10-27 09:53:35
               date|                            |


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #23 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-27 13:49 -------
Subject: Re:  [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*

> Note that if you pad upward COMPLEX_TYPE (an ABI change), then just the
> assign_parm_remove_parallel fix should be enough and you could avoid passing
> everything in BLKmode (which pessimizes the code), because the emit_group_store
> bug only affects arguments that aren't passed in the first bytes of the
> register.

Changing the padding introduces an inconsistency between GCC versions,
but it's not really an ABI change as it always required upward padding.
The treatment of complex and vector types in function_arg was written
with this in mind.

I did see that complex types were correctly passed without using BLKmode
with your change installed.  So, it it goes in, I will look at reverting
the BLKmode change.

Dave


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

------- Comment #24 from jakub at gcc dot gnu dot org  2008-10-27 14:19 -------
Ok, I'll ping that patch next week.
Anyway, can this be closed now?  The regressions are gone...


-- 


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

------- Comment #25 from danglin at gcc dot gnu dot org  2008-10-27 15:24 -------
Fixed.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[jakub at gcc dot gnu dot org]

------- Comment #26 from jakub at gcc dot gnu dot org  2008-11-22 08:28 -------
Subject: Bug 37316

Author: jakub
Date: Sat Nov 22 08:27:04 2008
New Revision: 142115

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142115
Log:
        PR middle-end/37316
        * function.c (assign_parm_remove_parallels): Pass
        data->passed_type as third argument to emit_group_store.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/function.c


-- 


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