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