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: Michael Matz <matz at suse dot de>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 21 Jun 2016 10:00:23 +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> <alpine dot LSU dot 2 dot 20 dot 1606201941340 dot 13156 at wotan dot suse dot de>
On 20/06/16 19:01, Michael Matz wrote:
> 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).
Well, yes. That's exactly why we've agreed to change basic asms to
make them clobber memory, i.e. to make GCC more 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 registers.
Well, maybe. It's also fairly likely that many work by accident. IMO
this is more of a statement of hope than any kind of reasonable
>> 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 basic asms.
Repeat, repeat: the change being made is to make gcc MORE
> 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
That's what we're doing.