diff mbox

Make basic asm implicitly clobber memory

Message ID AM4PR07MB1571C3933F336F16269EF703E44F0@AM4PR07MB1571.eurprd07.prod.outlook.com
State New
Headers show

Commit Message

Bernd Edlinger May 24, 2016, 7:47 a.m. UTC 
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:



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


Thanks
Bernd.
diff mbox

Patch

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