Hi,
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?
>>
>> Correctness.
>
> 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
>> robust
>
> ... 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
expectation.
>> 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
conservative.
> 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.
That's what we're doing.
Andrew.
