On 02/11/2016 12:49 AM, David Wohlferd wrote:
I believe the attached patch addresses all the other outstanding comments.
Bernd Edlinger made some thorough comments; I'll just add a few more. 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.
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.
+ /* Warn on basic asm used inside of functions,
+ EXCEPT when in naked functions. Also allow asm (""). */
No all-caps.
@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?
-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'm also no longer sure about references to the wiki.
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}."
But again, if someone feels the docs patch as posted is preferrable, go
ahead and approve it (for stage1 I assume).
Bernd
