This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Deprecating basic asm in a function - What now?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]