Re: [PATCH] Make basic asm implicitly clobber memory

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

On 05/23/16 23:46, David Wohlferd wrote:
> On 5/23/2016 12:46 AM, Richard Biener wrote:
>  > On Sun, 22 May 2016, Andrew Haley wrote:
>  >> On 05/20/2016 07:50 AM, David Wohlferd wrote:
>  >>> I realize deprecation/removal is drastic.  Especially since basic
>  >>> asm (mostly) works as is.  But fixing memory clobbers while leaving
>  >>> the rest broken feels like half a solution, meaning that some day
>  >>> we're going to have to fiddle with this again.
>  >>
>  >> Yes, we will undoubtedly have to fiddle with basic asm again.  We
>  >> should plan for deprecation.
>  >
>  > I think adding memory clobbers is worth having.  I also think that
>  > deprecating basic asms would be a good thing, so can we please
>  > add a new warning for that?  "warning: basic asms are deprecated"
>
> I've still got the -Wbasic-asm patch where I proposed this for v6. I can
> dust it off again and re-submit it.  A couple questions first:
>
> 1) In this patch the warning was disabled by default.  But it sounds
> like you want it enabled by default?  Easy to change, I'm just
> confirming your intent.
>

For practical reasons I would suggest to enable a warning like that,
only with -Wall otherwise you would have to decorate lots of test cases
with dg-warning statements (and it is rather difficult to do that for
all affected targets).

> 2) Is 'deprecated' handled differently than other types of warnings?
> There is a -Wno-deprecated, but it seems to have a very specific meaning
> that does not apply here.
>
> 3) The warning text in the old patch was "asm statement in function does
> not use extended syntax".  The intent was:
>
> a) Don't make it sound like basic asm is completely gone, since it can
> still be used at top level.
> b) Don't make it sound like all inline asm is gone, since extended asm
> can still be used in functions.
> c) Convey all that in as few words as possible.
>

The warning could also mention the changed behavior regarding the memory
clobbers, and recommend using extended asm syntax for that reason.
That was at least my initial thought.

> Now that we want to add the word 'deprecated,' perhaps one of these:
>
> - Basic asm in functions is deprecated in favor of extended syntax
> - asm in functions without extended syntax is deprecated
> - Deprecated: basic asm in function
> - Deprecated: asm in function without extended syntax
>
> I like the last one (people may not know what 'basic' means in this
> context), but any of these would work for me.  Preferences?
>
> In order to avoid conflicts, I'll wait for Bernd to commit his patch first.
>

Maybe we should not deprecate every use case, asm("") was fine, for
certain reasons.

Furthermore I think the ia64 port could still theoretically use
traditional asm to specify the stop bits (see config/ia64/ia64.c,
rtx_needs_barrier).

BTW: My patch still waits to be reviewed in detail by one of the global
reviewers, before I can apply it.

Meanwhile I added this to doc/extend.texi, in response to David's
comments:

--- gcc/doc/extend.texi (revision 231412)
+++ gcc/doc/extend.texi (working copy)
@@ -7508,7 +7508,7 @@
  inside them.  GCC has no visibility of symbols in the @code{asm} and may
  discard them as unreferenced.  It also does not know about side effects of
  the assembler code, such as modifications to memory or registers.  Unlike
-some compilers, GCC assumes that no changes to either memory or registers
+some compilers, GCC assumes that no changes to general purpose registers
  occur.  This assumption may change in a future release.

  To avoid complications from future changes to the semantics and the


Which is just the fact.  Obviously the doc will need further
polishing though, I'd like to leave that to David.


Thanks
Bernd.