public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: dalej@apple.com
To: gcc-gnats@gcc.gnu.org
Subject: middle-end/6241: bad code gen on ppc (C++ only)
Date: Tue, 09 Apr 2002 17:26:00 -0000	[thread overview]
Message-ID: <20020410002309.14116.qmail@sources.redhat.com> (raw)


>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:


             reply	other threads:[~2002-04-10  0:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-09 17:26 dalej [this message]
2002-08-30 12:46 dje

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020410002309.14116.qmail@sources.redhat.com \
    --to=dalej@apple.com \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).