Re: AW: Wonly-top-basic-asm

[Bernd Schmidt <bschmidt@redhat.com>]

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