This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Deprecating basic asm in a function - What now?


Hi,

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).

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.

> 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.

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.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]