This is the mail archive of the
mailing list for the GCC project.
Re: Deprecating basic asm in a function - What now?
- From: Andrew Haley <aph at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Michael Matz <matz at suse dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 22 Jun 2016 11:45:40 +0100
- 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> <43d3f7ea-b62f-f035-fa4d-6986d324a223 at redhat dot com>
On 22/06/16 09:59, Florian Weimer wrote:
> On 06/20/2016 07:40 PM, Andrew Haley wrote:
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn. What would be the
>>> advantage again?
>> Correctness. It is very likely that many of these basic asms are not
>> robust in the face of compiler changes because they don't declare
>> their dependencies and therefore work only by accident.
> But the correctness problem is much more severe with extended asm. With
> basic asm, the compiler can be conservative. With extended asm, there
> is an expectation that it is not, and yet many of the constraints out
> there are slightly wrong and can lead to breakage any time.
Yes, that's true. However, at least in the case of extended asm there
is a chance that the programmer has thought about it.
But anyway, the decision has been made. None of this matters.