On 02/12/2016 08:05 AM, David Wohlferd wrote:
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 doc patch (minus mentioning the warning) could go in now, but for
gcc-6 we're at a stage where we're only accepting regression fixes with
very few exceptions. If you can convince a RM that this is important
enough then it could still go in.
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.
I'm actually not convinced that we'll want to change much in asm
behaviour. Clobbering memory, maybe, but I can't see much beyond that -
there's just no gain and some risk. So I'm a little more relaxed about
the whole thing.
"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.
This is what I mean when I say "too verbose" - the second sentence
essentially says exactly the same thing as the first. The repetition is
unnecessary, and I'd drop it.
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}.
Other than that they look quite similar, and I think your new suggestion
is good too. Let's let Sandra have the last word.
Bernd
