This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PR string/19907: Incorrect memcpy tests
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 08 May 2016 21:35:40 +0200
- Subject: Re: [PATCH] PR string/19907: Incorrect memcpy tests
- Authentication-results: sourceware.org; auth=none
- References: <20160405050218 dot GA5157 at gmail dot com> <CAMe9rOr-WhT-RbxvrFNwOh9OiqiF8hJFHm6D18povJJBADB5RQ at mail dot gmail dot com> <87k2j4wjxz dot fsf at mid dot deneb dot enyo dot de> <CAMe9rOqezqjE2_JZuofEr3ZhcbRQg41_U0hAyZm7N02QMULD=w at mail dot gmail dot com>
* H. J. Lu:
> On Sun, May 8, 2016 at 10:14 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * H. J. Lu:
>>
>>> + /* Must clear the destination buffer set by the previous run. */
>>> + for (i = 0; i < len; i++)
>>> + dst[i] = 0;
>>
>> Doesn't this need some sort of compiler barrier so that GCC will not
>> eliminate the dead stores if it recognizes a memset-style loop?
>
> The code looks like:
>
> /* Must clear the destination buffer set by the previous run. */
> for (i = 0; i < len; i++)
> dst[i] = 0;
>
> if (CALL (impl, dst, src, len) != MEMCPY_RESULT (dst, len))
> {
>
> Compiler doesn't know what CALL (impl, dst, src, len) does
> and won't optimize it out.
I looked at the underlying mechanism and there's an indirection
through the âimplsâ section. You are right that it's going to take a
while until the compiler will see through that. In any case, it's a
pre-existing problem, not related to your change.