On Wed, Jun 7, 2017 at 5:26 AM, Martin Sebor <mse...@gmail.com> wrote:
>> Note I'd be _much_ more sympathetic to simply canonicalizing all of
>> bzero and bcopy
>> to memset / memmove and be done with all the above complexity.
>
>
> Attached is an updated patch along these lines. Please let me
> know if it matches your expectations.
I think you attached the wrong patch.
Richard.
> FWIW, although I don't feel too strongly about bzero et al. I'm
> not sure that this approach is the right one in general. It might
> (slightly) simplify GCC itself, but other than the incidental code
> generation improvement, it offers no benefit to users. In some
> cases, it even degrades user experience by causing GCC issue
> diagnostics that refer to functions that don't appear in the source
> code, such as for:
>
> char d[1];
>
> void* f (const void *p)
> {
> bzero (d, 7);
> }
>
> warning: ‘__builtin_memset’ writing 7 bytes into a region of size 1
> overflows the destination [-Wstringop-overflow=]
>
> For some functions like mempcpy it might even worse code overall
> (slower and bigger).
>
> In other cases (like profiling) it loses interesting information.
>
> I think these types of transformations would be justified f they
> were done based on measurably improved efficiency of the generated
> code, but I'm uneasy about swapping calls to one function for another
> solely because it simplifies the implementation. Not least because
> it doesn't seem like a viable general approach to simplifying the
> implementation.
>
> Martin
>
> PS I stopped short of simplifying GCC to remove the existing special
> handling of these three built-ins. If the patch is approved I'm
> willing to do the cleanup in a subsequent pass.
