On 6/21/2016 9:43 AM, Jeff Law wrote:
> I think there's enough resistance to deprecating basic asms within a
function that we should probably punt that idea.
I don't disagree that there has been pushback. I just wish less of it
was of the form "Because I don't wanna." A few examples of "Here's
something that has to be in basic asm because..." might have produced a
more interesting discussion. I think if people had to defend (even to
themselves) why they were using BAIF, there might be more converts.
And I *get* that it takes time to re-write this, and people have
schedules, lives, a need for sleep. But even under the most insanely
aggressive schedule I can imagine (if gcc continue to release ~1/year),
it will be at least a year before there's a release that has the
(disable-able) warning, and another year before we could even think
about actually removing this. So someone who plans to use v8.0 in their
production code on the day it is released still has a minimum of *two
years* to get ready.
> I do think we should look to stomp out our own uses of basic asms
within functions just from a long term maintenance standpoint.
Fixes.patch (from the start of this thread) seems mostly uncontested.
Send it to patches?
If someone wanted to clean up a bunch of these, they should take a look
at CRT_CALL_STATIC_FUNCTION in gcc/config. This is defined for nearly
every platform, and most of them do it with basic asm. I gotta wonder
if there's a better way to do this. Isn't there an attribute for 'section'?
> Finally I think we should continue to bring the implementation of
basic asms more in-line with expectations and future proofing them
I believe there are compilers that do safely use inline asm. However it
appears that they accomplish this trick by parsing the asm. Not
something I expect to see added to gcc anytime soon...
> since I'm having a hard time seeing a reasonable path to deprecating
their use.
Umm. Hmm. Seems like the ideal answer here would be something that
prevents new code from using BAIF, without putting the old-timers in an
uproar.
So how about the old "empty threat" gambit? We could *say* we are going
to deprecate it, put the (disable-able) warning into the code and the
stern-sounding text in the docs, and then *leave* it like that for a
decade or so. The idea being that new code won't use it, but old code
will still be supported. Hopefully 10 years from now, there might be so
little code that uses BAIF that finally removing it may no longer be so
controversial. It's not a lie, since deprecate means "express
disapproval of" and yeah, that's about right. And since we don't
specify precisely *when* we intend to remove it...
dw
