On 7/22/19 9:40 AM, Martin Sebor wrote:
>> Given that they're not allowed to overlap, I would think not. If that
>> were allowed then the code which aggressively transforms strncpy to
>> memcpy would need to be disabled (or at least throttled back) as well.
>
> I think there's some (maybe too muc
On 7/22/19 8:55 AM, Jeff Law wrote:
On 7/22/19 2:01 AM, Richard Biener wrote:
On Fri, Jul 19, 2019 at 7:04 PM Jeff Law wrote:
While looking at BZ 80576 I realized a few things.
First for STRNCPY we know the exact count of bytes written and we can
treat it just like MEMCPY and others, both i
On 7/22/19 2:01 AM, Richard Biener wrote:
> On Fri, Jul 19, 2019 at 7:04 PM Jeff Law wrote:
>>
>>
>> While looking at BZ 80576 I realized a few things.
>>
>> First for STRNCPY we know the exact count of bytes written and we can
>> treat it just like MEMCPY and others, both in terms of removing/tri
On Fri, Jul 19, 2019 at 7:04 PM Jeff Law wrote:
>
>
> While looking at BZ 80576 I realized a few things.
>
> First for STRNCPY we know the exact count of bytes written and we can
> treat it just like MEMCPY and others, both in terms of removing/trimming
> them and in terms of using them to allow r
While looking at BZ 80576 I realized a few things.
First for STRNCPY we know the exact count of bytes written and we can
treat it just like MEMCPY and others, both in terms of removing/trimming
them and in terms of using them to allow removal of other stores.
This patch adds support for those ro
