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
