This is the mail archive of the
mailing list for the GCC project.
Re: Deprecating basic asm in a function - What now?
- From: Michael Matz <matz at suse dot de>
- To: Andrew Haley <aph at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 20 Jun 2016 20:01:24 +0200 (CEST)
- 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>
On Mon, 20 Jun 2016, 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?
As said in the various threads about basic asms, all correctness
problems can be solved by making GCC more conservative in handling them
(or better said: not making it less conservative).
If you talk about cases where basic asms diddle registers expecting GCC to
have placed e.g. local variables into specific ones (without using local
reg vars, or extended asm) I won't believe any claims ...
> It is very likely that many of these basic asms are not
... of them being very likely without proof. They will have stopped
working with every change in compilation options or compiler version. In
contrast I think those that did survive a couple years in software very
likely _are_ correct, under the then documented (or implicit) assumptions.
Those usually are: clobbers and uses memory, processor state and fixed
> in the face of compiler changes because they don't declare their
> dependencies and therefore work only by accident.
Then the compiler better won't change into less conservative handling of
You see, the experiment shows that there's a gazillion uses of basic asms
out there. Deprecating them means that each and every one of them (for us
alone that's 540 something, including testsuite and boehm) has to be
changed from asm("body") into asm("body" : : : "memory") (give and take
some syntax for also clobbering flags). Alternatively rewrite the
body to actually make use of extended asm. I guarantee you that a
non-trivial percentage will be wrong _then_ while they work fine now.
Even if it weren't so it still would be silly if GCC simply could regard
the former as the latter internally. It would just be change for the sake
of it and affecting quite many users without gain.