Hi Dale,
While that's nonstandard, it's hard to imagine a memcpy
implementation that would screw it up.
But they can partially overlap:
how does mainline handle this? I know it used to get it
wrong (the testcase I sent was filched from gcc bugzilla),
but the bug was marked as resolved,
Hi Bill, the following testcase shows another problem:
struct A
{
int a[1024];
};
void g(struct A *a, struct A *b)
{
*a = *b;
}
struct A c;
int main(void)
{
g(c, c);
}
Note that llvm-gcc generates a memcpy for the *a = *b
assignment, but it should be memmove since *a and *b
may be the same
Hi Bill,
Does this help? :-)
the tree dumps weren't very informative! :) Here is a testcase that
seems to show the same kind of problem, and works on my machine:
struct A
{
int a[11];
};
void Qux() {
static struct A C = {0};
struct A __attribute__ ((aligned (1))) Bar;
Bar = C;
}
On Nov 7, 2007, at 1:20 AM, Duncan Sands wrote:
Hi Bill,
Does this help? :-)
the tree dumps weren't very informative! :)
Yeah...there weren't that many that were dumped. :-)
Here is a testcase that seems to show the same kind of problem, and
works on my machine:
struct A
{
int
Hi Bill,
Can you please confirm that this is the problem you are talking about?
No, this doesn't give the assert. :-(
the memcpy seems to have the wrong alignment in the LLVM IR. This may or may
not
lead to an assert later I suppose. I meant: is the memcpy getting the wrong
alignment for
Hi Duncan,
No, this doesn't give the assert. :-(
the memcpy seems to have the wrong alignment in the LLVM IR. This
may or may not
lead to an assert later I suppose.
That's what's wrong here. We're using the alignment from the source
pointer as the alignment for the memcpy, which is
On Nov 7, 2007, at 12:46 AM, Duncan Sands wrote:
Hi Bill, the following testcase shows another problem:
struct A
{
int a[1024];
};
void g(struct A *a, struct A *b)
{
*a = *b;
}
struct A c;
int main(void)
{
g(c, c);
}
Note that llvm-gcc generates a memcpy for the *a = *b
On 10/26/07, Duncan Sands [EMAIL PROTECTED] wrote:
I've only seen this problem on PPC64. In particular, it's writing this
information into the redzone because this is a leaf function, and
thus the destination may be unaligned.
Can you please send me the gcc tree dumps, and also what
Author: void
Date: Fri Oct 26 15:27:28 2007
New Revision: 43399
URL: http://llvm.org/viewvc/llvm-project?rev=43399view=rev
Log:
Port of r43394:
There are situations where the source and destination alignments differ. This
can cause havoc with memcpy. In this case, memcpy is using the alignment of
Hi Bill, I must say that I don't like this patch at all. Is there
no better way? I started to work on something better myself, but
unfortunately on my machine (x86-32) the testcase doesn't lead to
a memcpy with llvm-gcc-4.2 at all, only a memset. Can you please
suggest a testcase that shows the
Hi Duncan,
Hi Bill, I must say that I don't like this patch at all. Is there
no better way?
I'm open to suggestions. :-) What part do you object to? I reasoned
that we needed to make the memcpy intrinsic have the correct
alignment. It is getting its alignment information from the source
Hi Bill, I must say that I don't like this patch at all. Is there
no better way?
I'm open to suggestions. :-) What part do you object to?
All of it! But let's not go there :)
I've only seen this problem on PPC64. In particular, it's writing this
information into the redzone because
On 10/26/07, Duncan Sands [EMAIL PROTECTED] wrote:
Hi Bill, I must say that I don't like this patch at all. Is there
no better way?
I'm open to suggestions. :-) What part do you object to?
All of it! But let's not go there :)
I've only seen this problem on PPC64. In particular,
13 matches
Mail list logo
