https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005
--- Comment #16 from Alejandro Colomar <alx at kernel dot org> --- (In reply to Andrew Pinski from comment #13) > We have been warning about noinline and inline since the noinline attribute > was added back in r0-37987-g9162542e3d0cd2 . > > When noipa was added (r8-2213-g036ea39917b0ef) we had the same warning there. I was using -Wno-attributes in the past, and didn't notice that. > > Since it is documented that noipa implies noinline attribute I am not sure > if there is anything to be done for this diagnostic either. The wording of the diagnostic is just minor (caused me some confusion for a short time, but eventually understood it). I'm okay leaving it as is. > As far as the original thing dealing with boundaries go, having an function > in a public header even though marked as noipa and inline, the boundary does > not exist then because folks will do stuff to cause the noipa NOT being > added. I don't mind users removing that boundary, as long as they do it knowingly. I welcome they trying to optimize if they have that need. However, by default I want to have the boundary, to not be blamed when a bug is found in my library and that means recompiling other stuff. (In reply to Andrew Pinski from comment #14) > You could put all of the internal functions in a header file which only gets > included for the internal case and not install that header file ... For some time, I had been doing this. I decided the file structure was quite messy and complex to understand, and moved the inline definitions to the exported headers a few days ago (which is when I realized about this diagnostic). The result is orders of magnitude simpler, and more readable.
