This is the mail archive of the
mailing list for the GCC project.
Re: Deprecating basic asm in a function - What now?
- From: David Wohlferd <dw at LimeGreenSocks dot com>
- To: Jeff Law <law at redhat dot com>, Andrew Haley <aph at redhat dot com>, matz at suse dot de
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 22 Jun 2016 02:28:57 -0700
- Subject: Re: Deprecating basic asm in a function - What now?
- Authentication-results: sourceware.org; auth=none
- References: <dc3ca16c-3521-757f-fcf0-50061f510f75 at LimeGreenSocks dot com> <alpine dot LSU dot 2 dot 20 dot 1606201931460 dot 13156 at wotan dot suse dot de> <57682A85 dot 4060803 at redhat dot com> <alpine dot LSU dot 2 dot 20 dot 1606201941340 dot 13156 at wotan dot suse dot de> <57690227 dot 2050501 at redhat dot com> <alpine dot LSU dot 2 dot 20 dot 1606211401150 dot 13156 at wotan dot suse dot de> <57696C45 dot 5000309 at redhat dot com> <c23d921a-5546-ea81-0367-cfc1a18de876 at redhat dot com>
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
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
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...