diff mbox

document -Winvalid-memory-model

Message ID 568B0B08.7000206@gmail.com
State New
Headers show

Commit Message

Martin Sebor Jan. 5, 2016, 12:15 a.m. UTC 
> We just had a patch a month or so ago (r231022) to sort this table into
> something approaching alphabetical order, module no- prefixes, I guess.
>   Can you please insert the new entry into a less random place?

Sure.  It was meant to be inserted in the right place, my brain
just filtered out the "invalid" part in the name of the option.
Fixed in the updated patch.

>> @@ -4305,6 +4306,26 @@
>>  computations may be deleted by data flow analysis before the warnings
>>  are printed.
>>
>> +@item -Winvalid-memory-model
>> +@opindex Winvalid-memory-model
>> +@opindex Wno-invalid-memory-model
>> +Warn for invocations of @ref{__atomic Builtins}, @ref{__sync Builtins},
>> +and the C11 atomic generic functions with a memory consistency argument
>> +that is either invalid for the operation or outside the range of values
>> +of the @code{memory_order} enumeration.  For example, since the
>> +@code{__atomic_store} and @code{__atomic_store_n} built-ins are only
>
> s/built-ins/builtins/ (like in the @refs you used previously)

I thought the @refs were an inconsistency and built-in was
the preferred spelling.  That's what someone else pointed
out to me sometime ago and what I see documented in the GCC
Coding Conventions (and what I also noticed used elsewhere
in this section of the manual).

But looking more closely, there are quite a few uses of both
builtins and built-ins, on this manual page as well as on
others.  Which makes me wonder which of the two is prevalent.

I count 68 occurrences of the words builtin and builtins in
the manual (separated by space and ignoring capitalization)
and 481 occurrences of the words built-in and built-ins.

I also count 50 occurrences of built-in in the gcc.pot file
and 33 occurrences of builtin.

This seems to confirm my understanding of the recommended
convention (though it also shows how inconsistently it is
being followed).  Please let me know if I missed something.

>> +defined for the relaxed, relase, and sequentially consistent memory
>
> s/relase/release/

Fixed, thanks.

I will go ahead and commit this version of the patch tomorrow
unless you have objections.

Martin

Comments

Sandra Loosemore Jan. 5, 2016, 12:34 a.m. UTC | #1 
On 01/04/2016 05:15 PM, Martin Sebor wrote:

>> s/built-ins/builtins/ (like in the @refs you used previously)
>
> I thought the @refs were an inconsistency and built-in was
> the preferred spelling.  That's what someone else pointed
> out to me sometime ago and what I see documented in the GCC
> Coding Conventions (and what I also noticed used elsewhere
> in this section of the manual).
>
> But looking more closely, there are quite a few uses of both
> builtins and built-ins, on this manual page as well as on
> others.  Which makes me wonder which of the two is prevalent.
>
> I count 68 occurrences of the words builtin and builtins in
> the manual (separated by space and ignoring capitalization)
> and 481 occurrences of the words built-in and built-ins.
>
> I also count 50 occurrences of built-in in the gcc.pot file
> and 33 occurrences of builtin.
>
> This seems to confirm my understanding of the recommended
> convention (though it also shows how inconsistently it is
> being followed).  Please let me know if I missed something.

Sorry, my bad.  "Built-in", hyphenated, is correct as an adjective, as 
in "built-in function".  It's not clear what we're supposed to use as a 
noun, but it seems "builtin" isn't it, either.  :-S  I think that a 
couple years ago I changed a bunch of other instances to "built-in 
function" to avoid this trouble, but I won't insist on that here.

> I will go ahead and commit this version of the patch tomorrow
> unless you have objections.

Looks OK to me now.

-Sandra
diff mbox

Patch

gcc/ChangeLog:
2016-01-04  Martin Sebor  <msebor@redhat.com>

	* doc/invoke.texi (Warning Options): Document -Winvalid-memory-model.

Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi	(revision 232047)
+++ doc/invoke.texi	(working copy)
@@ -260,7 +260,7 @@ 
 -Wignored-qualifiers  -Wincompatible-pointer-types @gol
 -Wimplicit  -Wimplicit-function-declaration  -Wimplicit-int @gol
 -Winit-self  -Winline  -Wno-int-conversion @gol
--Wno-int-to-pointer-cast -Wno-invalid-offsetof @gol
+-Wno-int-to-pointer-cast -Winvalid-memory-model -Wno-invalid-offsetof @gol
 -Winvalid-pch -Wlarger-than=@var{len} @gol
 -Wlogical-op -Wlogical-not-parentheses -Wlong-long @gol
 -Wmain -Wmaybe-uninitialized -Wmemset-transposed-args @gol
@@ -4305,6 +4305,26 @@ 
 computations may be deleted by data flow analysis before the warnings
 are printed.
 
+@item -Winvalid-memory-model
+@opindex Winvalid-memory-model
+@opindex Wno-invalid-memory-model
+Warn for invocations of @ref{__atomic Builtins}, @ref{__sync Builtins},
+and the C11 atomic generic functions with a memory consistency argument
+that is either invalid for the operation or outside the range of values
+of the @code{memory_order} enumeration.  For example, since the
+@code{__atomic_store} and @code{__atomic_store_n} built-ins are only
+defined for the relaxed, release, and sequentially consistent memory
+orders the following code is diagnosed:
+
+@smallexample
+void store (int *i)
+@{
+  __atomic_store_n (i, 0, memory_order_consume);
+@}
+@end smallexample
+
+@option{-Winvalid-memory-model} is enabled by default.
+
 @item -Wmaybe-uninitialized
 @opindex Wmaybe-uninitialized
 @opindex Wno-maybe-uninitialized