On 01/24/2016 11:23 PM, David Wohlferd wrote:
+Wonly-top-basic-asm
+C ObjC ObjC++ C++ Var(warn_only_top_basic_asm) Warning
+Warn on unsafe uses of basic asm.
Maybe just -Wbasic-asm?
+ /* Warn on basic asm used inside of functions,
+ EXCEPT when in naked functions. Also allow asm(""). */
Two spaces after a sentence.
+ if (warn_only_top_basic_asm && (TREE_STRING_LENGTH (str) != 1) )
Unnecessary parens, and extra space before closing paren.
+ if (warn_only_top_basic_asm &&
+ (TREE_STRING_LENGTH (string) != 1))
Extra parens, and && goes first on the next line.
+ warning_at(asm_loc, OPT_Wonly_top_basic_asm,
Space before "(".
+ "asm statement in function does not use extended syntax");
Could break that into ".." "..." over two lines so as to keep indentation.
-asm ("");
+asm ("":::);
Is that necessary? As far as I can tell we're treating these equally.
@@ -7487,6 +7490,8 @@
consecutive in the output, put them in a single multi-instruction @code{asm}
statement. Note that GCC's optimizers can move @code{asm} statements
relative to other code, including across jumps.
+Using inputs and outputs with extended @code{asm} can help correctly position
+your asm.
Not sure this is needed either. Sounds a bit like advertising :) In
general the doc changes seem much too verbose to me.
+Extended @code{asm}'s @samp{%=} may help resolve this.
Same here. I think the block that recommends extended asm is good
enough. I think the next part could be shrunk significantly too.
-Here is an example of basic @code{asm} for i386:
+Basic @code{asm} statements within functions do not perform an implicit
+"memory" clobber (@pxref{Clobbers}). Also, there is no implicit clobbering
+of @emph{any} registers, so (other than "naked" functions which follow the
"other than in"? Also @code{naked} maybe. I'd place a note about
clobbering after the existing "To access C data, it is better to use
extended asm".
+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. Also, lacking inputs and
+outputs means that GCC's optimizers may have difficulties consistently
+positioning the basic @code{asm} in the generated code.
The existing text already mentions ordering issues. Lose this block.
+The concept of ``clobbering'' does not apply to basic @code{asm} statements
+outside of functions (aka top-level asm).
Stating the obvious?
+@strong{Warning!} This "clobber nothing" behavior may be different than how
Ok there is precedent for this, but it's spelt "@strong{Warning:}" in
all other cases. Still, I'd probably also shrink this paragraph and put
a note about lack of C semantics and possibly different behaviour from
other compilers near the top, where we say that extended asm is better
in most cases.
+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. Also, there is discussion underway about changing GCC to
+have basic @code{asm} clobber at least memory and perhaps some (or all)
+registers. If implemented, this change may fix subtle problems with
+existing @code{asm} statements. However it may break or slow down ones that
+were working correctly.
How would such a change break anything? I'd also not mention discussion
underway, just say "Future versions of GCC may treat basic @code{asm} as
clobbering memory".
+If your existing code needs clobbers that GCC's basic @code{asm} is not
+providing, or if you want to 'future-proof' your asm against possible
+changes to basic @code{asm}'s semantics, use extended @code{asm}.
Recommending it too often. Lose this.
+Extended @code{asm} allows you to specify what (if anything) needs to be
+clobbered for your code to work correctly.
And again.
You can use @ref{Warning
+Options, @option{-Wonly-top-basic-asm}} to locate basic @code{asm}
I think just plain @option is usual.
+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.
A link is probably good if we have such a page.
+Here is an example of top-level basic @code{asm} for i386 that defines an
+asm macro. That macro is then invoked from within a function using
+extended @code{asm}:
The updated example also looks good.
I think I'm fine with the concept but I'd like to see an updated patch
with better docs.
Bernd
