On Fri, Mar 26, 2021 at 2:49 PM Florian Weimer <f...@deneb.enyo.de> wrote: > > * Jakub Jelinek via Gcc-patches: > > > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote: > >> How can we move forward with it? I'd like to resolve it in GCC 11. > > > > I think it is too late for GCC 11 for this. > > Especially if the solution would be that we change the behavior of existing > > attribute, we would need enough time to test everything in the wild that > > we don't break it badly, even if we add new attributes that cover the > > previous behavior. Only if we keep the behavior of existing attribute > > and add a new one with the new behavior it would be something that could > > be considered for GCC 11 IMNSHO but then you'd need to change the glibc > > headers in time too to buy into the new attribute. > > We need analysis of all GCC targets with target attribute support and > > handle them consistently. > > I think H.J. needs this for a function that isn't even always_inline, > just extern inline __attribute__ ((gnu_inline)). Is that aspect > something that could be solved for GCC 11?
But that should already work, no? Yes, it won't inline but also not error. Unless glibc lacks the out-of-line definition, that is. Richard.
