https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70458
--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Wed, 30 Mar 2016, fw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70458 > > --- Comment #3 from Florian Weimer <fw at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #2) > > I also seriously question > > > > "The glibc consensus is to keep such calls." > > > > can you provide a reference to the relevant discussion? > > https://sourceware.org/ml/libc-alpha/2016-03/msg00587.html Saying that such calls are not inherently bugs is not the same thing as a consensus they should be kept; that would depend on what people think of the proposed cleaner alternative code in particular cases. I think a more important case for such an attribute is to act as a barrier to type-based aliasing. We definitely *do* wish to be able to implement optimized string functions in generic C working on aligned words, when the type used for those words may not be compatible in aliasing terms with the effective type of the storage in the caller. And so if we're to allow LTO in glibc in future, we need to prevent type-based aliasing optimizations being applied based on the type of storage used in those string functions. But maybe it's possible to do so by using may_alias attributes inside those functions, without needing any new attributes. Similarly, some glibc string functions may read data outside the bounds of their arguments but known to be on the same page. And there mustn't be optimizations in callers based on such code being undefined either. (And aliasing of functions with incompatible types that are ABI-compatible is definitely deliberate and desired in glibc, as a matter of code size reduction.)
