From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-17098-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14449 invoked by alias); 10 Apr 2002 00:26:01 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 14425 invoked by uid 71); 10 Apr 2002 00:26:00 -0000
Resent-Date: 10 Apr 2002 00:26:00 -0000
Resent-Message-ID: <20020410002600.14424.qmail@sources.redhat.com>
Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer)
Resent-To: nobody@gcc.gnu.org
Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Resent-Reply-To: gcc-gnats@gcc.gnu.org, dalej@apple.com
Received:(qmail 14117 invoked by uid 61); 10 Apr 2002 00:23:09 -0000
Message-Id:<20020410002309.14116.qmail@sources.redhat.com>
Date: Tue, 09 Apr 2002 17:26:00 -0000
From: dalej@apple.com
Reply-To: dalej@apple.com
To: gcc-gnats@gcc.gnu.org
X-Send-Pr-Version:gnatsweb-2.9.3 (1.1.1.1.2.31)
Subject: middle-end/6241: bad code gen on ppc (C++ only)
X-SW-Source: 2002-04/txt/msg00561.txt.bz2
List-Id: <gcc-prs.sourceware.org>


>Number:         6241
>Category:       middle-end
>Synopsis:       bad code gen on ppc (C++ only)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 09 17:26:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Dale Johannesen
>Release:        GNU C++ version 3.2 20020409 (experimental) (powerpc-apple-darwin1.4)
>Organization:
>Environment:
Darwin and, I suspect, other PowerPc
>Description:
ppc parameter passing is incorrect in certain C++ cases.   The executable example below illustrates.  
The testcase is compilable as either C or C++.
It works as C, not as C++.  The difference is that
the struct-valued parameter to foo is passed as a TARGET_EXPR in C++.   This causes the following sequence of events:
store_one_arg for foo() marks the appropriate cells of stack_usage_map as dirty, then calls expand_expr on the TARGET_EXPR.  This maps onto a memcpy() call, which gets back into store_one_arg, which carefully saves and restores the garbage on the stack around =the memcpy.  Not good.  I'm not sure which phase of this is wrong.

This works if the struct size is a multiple of 4.
It can probably be fixed by tweaking MUST_PASS_IN_STACK, and that should be done,
but I suspect a similar case with a constructor call could be, um, constructed that cannot be fixed that way.
This bug existed as far back as 2.95.

extern 
#ifdef __cplusplus
"C" 
#endif
void abort();
struct FSSpec { unsigned char name[70]; };
typedef struct FSSpec FSSpec;
extern void ResolveAlias (const FSSpec*, void** , FSSpec*, unsigned char*);
extern void foo(void*, FSSpec);
int main() {
  FSSpec fs;
  ResolveAlias(0, 0, &fs, 0);
  foo(0, fs);
  return 0;
}
void ResolveAlias (const FSSpec* a, void** b, FSSpec* c, unsigned char* d)
{
  int i;
  for ( i=0; i<sizeof(c->name); i++ )
    c->name[i] = i;
}
void foo (void* a, FSSpec b)
{
  int i;
  for ( i=0; i<sizeof(b.name); i++ )
    if ( b.name[i] != i )
      abort();
}
>How-To-Repeat:
Compile and run above example.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: