public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* middle-end/6241: bad code gen on ppc (C++ only)
@ 2002-04-09 17:26 dalej
  0 siblings, 0 replies; 2+ messages in thread
From: dalej @ 2002-04-09 17:26 UTC (permalink / raw)
  To: gcc-gnats


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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: middle-end/6241: bad code gen on ppc (C++ only)
@ 2002-08-30 12:46 dje
  0 siblings, 0 replies; 2+ messages in thread
From: dje @ 2002-08-30 12:46 UTC (permalink / raw)
  To: dalej, dje, gcc-bugs, gcc-prs, nobody

Synopsis: bad code gen on ppc (C++ only)

Responsible-Changed-From-To: unassigned->dje
Responsible-Changed-By: dje
Responsible-Changed-When: Fri Aug 30 12:35:10 2002
Responsible-Changed-Why:
    PPC
State-Changed-From-To: open->closed
State-Changed-By: dje
State-Changed-When: Fri Aug 30 12:35:10 2002
State-Changed-Why:
    http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01788.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6241


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-08-30 19:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-09 17:26 middle-end/6241: bad code gen on ppc (C++ only) dalej
2002-08-30 12:46 dje

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).