Re: AW: Wonly-top-basic-asm

[David Wohlferd <dw at LimeGreenSocks dot com>]

> I don't think this is a patch we're considering for gcc-6, at least 
> not for the initial release - I imagine it could be backported from 
> gcc-7 at some point.

Actually, it was my intent that this apply to v6.  It's not like there 
is a significant change here.  We're documenting long-time behavior, and 
adding a (disabled) warning.

The reasons I think this is needed for v6 are:

1) We have become aware of places where basic asm's existing behavior is 
a problem.  This patch provides a way for users to locate these issues 
with a minimal, non-intrusive change.
2) There is a significant change to this behavior being proposed for 
v7.  When this happens, having a way to locate affected statements with 
features from a stable release seems desirable.

> Like the other Bernd I have a preference for just -Wbasic-asm. I'd 
> make the analogy with -Wparentheses - we don't warn about every 
> parenthesis, but the name of an option is not the place for detailed 
> explanations of how it works. Less typing and less to remember is 
> preferrable IMO.

While I still prefer Wbasic-asm-in-function, I really don't have strong 
feelings here.  Since both you and Bernd prefer this, I have changed it.

> > +          /* Warn on basic asm used inside of functions,
> > +         EXCEPT when in naked functions.  Also allow asm (""). */
>
> No all-caps.

Fixed.

> >   @subsubheading Remarks
> > -Using extended @code{asm} typically produces smaller, safer, and more
> > +Using extended @code{asm} (@pxref{Extended Asm}) typically produces 
> > smaller,
> > +safer, and more
> >   efficient code, and in most cases it is a better solution than basic
>
> Rewrap the paragraph?

I could, but then people get cranky about how hard the patch is to review.

> > -Here is an example of basic @code{asm} for i386:
> > +Basic @code{asm} statements do not perform an implicit "memory" clobber
> > +(@pxref{Clobbers}).  Also, there is no implicit clobbering of 
> > @emph{any}
> > +registers, so (other than in @code{naked} functions which follow the 
> > ABI
> > +rules) changed registers must be restored to their original value 
> > before
> > +exiting the @code{asm}.  While this behavior has not always been
> > +documented, GCC has worked this way since at least v2.95.3.
> >
> > +@strong{Warning:} This "clobber nothing" behavior may be different 
> > than how
> > +other compilers treat basic @code{asm}, since the C standards for the
> > +@code{asm} statement provide no guidance regarding these semantics.  
> > As a
> > +result, @code{asm} statements that work correctly on other compilers 
> > may not
> > +work correctly with GCC (and vice versa), even though they both compile
> > +without error.
> > +
> > +Future versions of GCC may change basic @code{asm} to clobber memory 
> > and
> > +perhaps some (or all) registers.  This change may fix subtle 
> > problems with
> > +existing @code{asm} statements.  However it may break or slow down ones
> > +that were working correctly.  To ``future-proof'' your asm against 
> > possible
> > +changes to basic @code{asm}'s semantics, use extended @code{asm}.
> > +
> > +You can use @option{-Wbasic-asm-in-function} to locate basic @code{asm}
> > +statements that may need changes, and refer to
> > +@uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to 
> > convert
> > +from basic asm to extended asm} for information about how to perform 
> > the
> > +conversion.
>
> I still think this is too verbose and would serve to confuse rather 
> than enlighten in practice. (If anyone feels otherwise, feel free to 
> overrule me.) 

I assume you mean someone besides me...

> I'm also no longer sure about references to the wiki.

This is not the first reference to the gcc wiki in the docs (looks like 
the 6th for gcc, plus 10 for other wikis).

> Let's look at this existing paragraph from the manual:
>
>   Since GCC does not parse the @var{AssemblerInstructions}, it has
>   no visibility of any symbols it references. This may result in GCC
>   discarding those symbols as unreferenced.
>
> I think extending this would be better. Something like
>
> "Since the C standards does not specify semantics for @code{asm}, it 
> is a potential source of incompatibilities between compilers. GCC does 
> not parse the @var{AssemblerInstructions}, which means there is no way 
> to communicate to the compiler what is happening inside them.  GCC has 
> no visibility of any symbols referenced in the @code{asm} and may 
> discard them as unreferenced. It also does not know about side effects 
> that may occur, such as modifications of memory locations or 
> registers. GCC assumes that no such side effects occur, which may not 
> be what the user expected if code was written for other compilers.
>
> Since basic @code{asm} cannot easily be used in a reliable way, 
> @option{-Wbasic-asm} should be used to warn about the use of basic asm 
> inside a function. See 
> @uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to 
> convert from basic asm to extended asm} for information about how to 
> convert code to use extended @code{asm}."

Hmm.  Yes, that's better.  But there are some things that got lost here 
that I think are important.  How about:

------------
@strong{Warning:} The C standards do not specify semantics for 
@code{asm}, making it a potential source of incompatibilities between 
compilers.  @code{asm} statements that work correctly on other compilers 
may not work correctly with GCC (and vice versa), even though both 
compile without error.

GCC does not parse basic @code{asm}'s @var{AssemblerInstructions}, which 
means there is no way to communicate to the compiler what is happening 
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 occur.  This assumption may change in a future release.

To avoid complications from future changes to the semantics and the 
compatibility issues between compilers, use @option{-Wbasic-asm} to warn 
about the use of basic asm inside a function.  See 
@uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to convert 
from basic asm to extended asm} for information about how to convert 
code to use extended @code{asm}.
------------

dw