On 06/07/2017 02:23 AM, Richard Biener wrote: > On Wed, Jun 7, 2017 at 5:26 AM, Martin Sebor 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. Yes I did, sorry. The correct one is attached. Martin > > 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.