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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 9 May 2016 05:51:50 -0700
- 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> <87a8k0wdf7 dot fsf at mid dot deneb dot enyo dot de>
On Sun, May 8, 2016 at 12:35 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * 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.
Any other comments, feedbacks, objections?
--
H.J.