Re: Move -Wmaybe-uninitialized to -Wextra
The problem with false positives is correlated with the degree of optimization; a lot of people have reported problems at only the `-Og' optimization level (even when the code in question is embarrassingly correct). Therefore, the general solution is probably that the implem- entation of `-Wmaybe-uninitialized' be customized for the given level of optimization. However, I get the impression that this is easier said than done. >From what I've read, `-Wmaybe-uninitialized' is essentially customized for `-O2', which means that it will work pretty darn well at that optimization level. So, in the interim, I propose a simple approximation of the general solution: At an optimization level below `-O2' (or other than `-O2'): * `-Wmaybe-uninitialized' is moved to `-Wextra'. If `-Wall' has been specified, then gcc emits an informational note stating that `-Wmaybe-uninitialized' (or any other warning that has similar problems) has been disabled. * Provide a command-line option to disable such a note. * The user may always enable `-Wmaybe-uninitialized' either explicitly or as part of `-Wextra'. * If `-Wmaybe-uninitialized' is enabled by the user, then it implies `-O2' computations. That is to say, when the user specifies: -Og -Wmaybe-uninitialized or: -Og -Wextra then the user is explicitly telling the compiler to do all the optimizations of `-O2', but ONLY for the purpose of implementing `-Wmaybe-uninitialized' (or whichever warning requires those optimizations to function well); all those optimizations are to be thrown out after they have been used to good effect by `-Wmaybe-uninitialized'. The Code generation, etc., shall be performed at the optimization level the user specified (namely, `-Og' in this case). In other words, save the user from gcc's foibles, but let the user pay for the extra computation if so desired! What do you think? Sincerely, Michael Witten PS All of this trouble indicates that C (and other languages) are just not expressive enough with regard to initialization. Initialization semantics are basically a matter of API contract specification; the programmer needs the tools to write it down. Surely, gcc could provide `__builtin_assume_initialized(x);' and parameter attributes to help inform the reader (i.e., to help inform the compiler) about the code; a function parameter attribute could specify whether the given argument can be considered initialized after a call, and maybe specify further constraints, such as whether the guarantee is made only when the function return value is nonzero (or a certain value), etc. We need the language to write our thoughts down!
Re: [PATCH 1/4] Docs: extend.texi: Add missing semicolon for consistency
On Wed, 8 Apr 2015 21:13:10 +0200 (CEST), Gerald Pfeifer wrote: On Wed, 27 Apr 2011, Michael Witten wrote: --- trunk/gcc/doc/extend.texi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi index eddff95..c154958 100644 --- a/trunk/gcc/doc/extend.texi +++ b/trunk/gcc/doc/extend.texi @@ -3997,7 +3997,7 @@ @smallexample __attribute__((noreturn)) void d0 (void), __attribute__((format(printf, 1, 2))) d1 (const char *, ...), - d2 (void) + d2 (void); @end smallexample @noindent Hi Michael, and big apologies for this falling through a lot of cracks apparently. I just committed your patch with the ChangeLog below. If there are any other patches that have not been committed (nor NACKed yet, I know there were some as well), please let us know and I will look into getting at least documentation patches addressed swiftly going forward. Thank you, and sorry again, Gerald 2015-04-08 Michael Witten mfwit...@gmail.com * doc/extend.texi (Attribute Syntax): Add a trailing semicolon to an example. Index: doc/extend.texi === --- doc/extend.texi (revision 221930) +++ doc/extend.texi (working copy) @@ -4771,7 +4771,7 @@ @smallexample __attribute__((noreturn)) void d0 (void), __attribute__((format(printf, 1, 2))) d1 (const char *, ...), - d2 (void) + d2 (void); @end smallexample @noindent Well, now! What a pleasant surprise! I was looking for a reason to crack open a beer, and this shall do nicely. Say, how did you end up coming across this patch after nearly 4 years? Anyway, thanks for letting me know, and thank you and the rest of the GCC team for all of your hard work; you make the world go round. Sincerely, Michael Witten
Re: [google] Linker plugin to do function reordering using callgraph edge profiles (issue5124041)
Re: [google] Linker plugin to do function reordering... Is there a particularly good reason for why you guys slip `[google]' into all of your `Subject:' lines? I was under the impresions that this list is for work on GCC. Consider putting something germane in the brackets instead.
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten mfwit...@gmail.com wrote: See the following emails for a few inlined patches to /trunk/gcc/doc/extend.texi (revision 172911): [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines [3] Docs: extend.texi: Rearrange nodes; no text was removed or added [4] Docs: extend.texi: Reword and rearrange attribute node introductions trunk/gcc/doc/extend.texi | 5449 +++-- 1 files changed, 2730 insertions(+), 2719 deletions(-) CHANGELOG Essentially, I think it would be easiest to squash all of these patches together into one revision; here is a ChangeLog entry for such a revision: 2011-04-27 Michael Witten mfwit...@gmail.com * gcc/doc/extend.texi: Add a `;', remove trailing whitespace, and reorganize nodes to group the discussion of attributes more logically. -- 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: 378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten mfwit...@gmail.com wrote: See the following emails for a few inlined patches to /trunk/gcc/doc/extend.texi (revision 172911): [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines [3] Docs: extend.texi: Rearrange nodes; no text was removed or added [4] Docs: extend.texi: Reword and rearrange attribute node introductions trunk/gcc/doc/extend.texi | 5449 +++-- 1 files changed, 2730 insertions(+), 2719 deletions(-) CHANGELOG Essentially, I think it would be easiest to squash all of these patches together into one revision; here is a ChangeLog entry for such a revision: 2011-04-27 Michael Witten mfwit...@gmail.com * gcc/doc/extend.texi: Add a `;', remove trailing whitespace, and reorganize nodes to group the discussion of attributes more logically. -- 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: 378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
On Thu, Apr 28, 2011 at 01:20, Michael Witten mfwit...@gmail.com wrote: See the following emails for a few inlined patches to /trunk/gcc/doc/extend.texi (revision 172911): [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines [3] Docs: extend.texi: Rearrange nodes; no text was removed or added [4] Docs: extend.texi: Reword and rearrange attribute node introductions trunk/gcc/doc/extend.texi | 5449 +++-- 1 files changed, 2730 insertions(+), 2719 deletions(-) CHANGELOG Essentially, I think it would be easiest to squash all of these patches together into one revision; here is a ChangeLog entry for such a revision: 2011-04-27 Michael Witten mfwit...@gmail.com * gcc/doc/extend.texi: Add a `;', remove trailing whitespace, and reorganize nodes to group the discussion of attributes more logically. -- 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: 378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
Re: [PATCH 0/4] Docs: extend.texi
Message On Thu, Apr 28, 2011 at 01:20, Michael Witten mfwit...@gmail.com wrote: See the following emails for a few inlined patches to /trunk/gcc/doc/extend.texi (revision 172911): [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines [3] Docs: extend.texi: Rearrange nodes; no text was removed or added [4] Docs: extend.texi: Reword and rearrange attribute node introductions trunk/gcc/doc/extend.texi | 5449 +++-- 1 files changed, 2730 insertions(+), 2719 deletions(-) CHANGELOG Essentially, I think it would be easiest to squash all of these patches together into one revision; here is a ChangeLog entry for such a revision: 2011-04-27 Michael Witten mfwit...@gmail.com * gcc/doc/extend.texi: Add a `;', remove trailing whitespace, and reorganize nodes to group the discussion of attributes more logically. -- 1.7.4.18.g68fe8 Please commit these patches, starting here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html Message-ID: 378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com Sincerely, Michael Witten
[PATCH 0/4] Docs: extend.texi
See the following emails for a few inlined patches to /trunk/gcc/doc/extend.texi (revision 172911): [1] Docs: extend.texi: Add missing semicolon for consistency [2] Docs: extend.texi: Remove trailing blanks from lines [3] Docs: extend.texi: Rearrange nodes; no text was removed or added [4] Docs: extend.texi: Reword and rearrange attribute node introductions trunk/gcc/doc/extend.texi | 5449 +++-- 1 files changed, 2730 insertions(+), 2719 deletions(-) CHANGELOG Essentially, I think it would be easiest to squash all of these patches together into one revision; here is a ChangeLog entry for such a revision: 2011-04-27 Michael Witten mfwit...@gmail.com * gcc/doc/extend.texi: Add a `;', remove trailing whitespace, and reorganize nodes to group the discussion of attributes more logically. -- 1.7.4.18.g68fe8
[PATCH 1/4] Docs: extend.texi: Add missing semicolon for consistency
--- trunk/gcc/doc/extend.texi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi index eddff95..c154958 100644 --- a/trunk/gcc/doc/extend.texi +++ b/trunk/gcc/doc/extend.texi @@ -3997,7 +3997,7 @@ @smallexample __attribute__((noreturn)) void d0 (void), __attribute__((format(printf, 1, 2))) d1 (const char *, ...), - d2 (void) + d2 (void); @end smallexample @noindent -- 1.7.4.18.g68fe8
[PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines
sed -i s/[ $(printf '\t')]\{1,\}\$// trunk/gcc/doc/extend.texi
---
trunk/gcc/doc/extend.texi | 82 ++--
1 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index c154958..cdbf69f 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -37,7 +37,7 @@
* Complex:: Data types for complex numbers.
* Floating Types:: Additional Floating Types.
* Half-Precision:: Half-Precision Floating Point.
-* Decimal Float:: Decimal Floating Types.
+* Decimal Float:: Decimal Floating Types.
* Hex Floats:: Hexadecimal floating-point constants.
* Fixed-Point:: Fixed-Point Types.
* Named Address Spaces::Named address spaces.
@@ -455,7 +455,7 @@
safe.
GCC implements taking the address of a nested function using a technique
-called @dfn{trampolines}. This technique was described in
+called @dfn{trampolines}. This technique was described in
@cite{Lexical Closures for C++} (Thomas M. Breuel, USENIX
C++ Conference Proceedings, October 17-21, 1988).
@@ -619,7 +619,7 @@
@}
return open (path, oflag, __builtin_va_arg_pack ());
@}
-
+
if (__builtin_va_arg_pack_len () 1)
return __open_2 (path, oflag);
@@ -942,7 +942,7 @@
@cindex @code{__fp16} data type
On ARM targets, GCC supports half-precision (16-bit) floating point via
-the @code{__fp16} type. You must enable this type explicitly
+the @code{__fp16} type. You must enable this type explicitly
with the @option{-mfp16-format} command-line option in order to use it.
ARM supports two incompatible representations for half-precision
@@ -963,7 +963,7 @@
The @code{__fp16} type is a storage format only. For purposes
of arithmetic and other operations, @code{__fp16} values in C or C++
expressions are automatically promoted to @code{float}. In addition,
-you cannot declare a function with a return value or parameters
+you cannot declare a function with a return value or parameters
of type @code{__fp16}.
Note that conversions from @code{double} to @code{__fp16}
@@ -971,14 +971,14 @@
of rounding, this can sometimes produce a different result than a
direct conversion.
-ARM provides hardware support for conversions between
+ARM provides hardware support for conversions between
@code{__fp16} and @code{float} values
as an extension to VFP and NEON (Advanced SIMD). GCC generates
code using these hardware instructions if you compile with
-options to select an FPU that provides them;
+options to select an FPU that provides them;
for example, @option{-mfpu=neon-fp16 -mfloat-abi=softfp},
in addition to the @option{-mfp16-format} option to select
-a half-precision format.
+a half-precision format.
Language-level support for the @code{__fp16} data type is
independent of whether GCC generates code using hardware floating-point
@@ -1995,7 +1995,7 @@
@cindex @code{alloc_size} attribute
The @code{alloc_size} attribute is used to tell the compiler that the
function return value points to memory, where the size is given by
-one or two of the functions parameters. GCC uses this
+one or two of the functions parameters. GCC uses this
information to improve the correctness of @code{__builtin_object_size}.
The function parameter(s) denoting the allocated size are specified by
@@ -2004,7 +2004,7 @@
of the two function arguments specified. Argument numbering starts at
one.
-For instance,
+For instance,
@smallexample
void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
@@ -2213,7 +2213,7 @@
attribute also implies ``default'' visibility. It is an error to
explicitly specify any other visibility.
-In previous versions of GCC, the @code{dllexport} attribute was ignored
+In previous versions of GCC, the @code{dllexport} attribute was ignored
for inlined functions, unless the @option{-fkeep-inline-functions} flag
had been used. The default behaviour now is to emit all dllexported
inline functions; however, this can cause object file-size bloat, in
@@ -2424,10 +2424,10 @@
are @code{printf_unlocked} and @code{fprintf_unlocked}.
@xref{C Dialect Options,,Options Controlling C Dialect}.
-For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
+For Objective-C dialects, @code{NSString} (or @code{__NSString__}) is
recognized in the same context. Declarations including these format attributes
will be parsed for correct syntax, however the result of checking of such
format
-strings is not yet defined, and will not be carried out by this version of the
+strings is not yet defined, and will not be carried out by this version of the
compiler.
The target may also provide additional types of format checks.
@@ -2752,7 +2752,7 @@
synonyms, and cause the compiler to always call
the function by first loading its address into a register, and then using
the contents of that register. The @code{near}
[PATCH 4/4] Docs: extend.texi: Reword and rearrange attribute node introductions
The rearrangement performed in the previous patch left the text in
somewhat of an inconsistent state in terms of the flow of concepts;
this patch improves the flow of concepts to something more sane by
editing the introductions to these nodes:
Attribute Syntax
Type Attributes
Variable Attributes
Function Attributes
---
trunk/gcc/doc/extend.texi | 53 +++-
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index 3b453e5..a9611de 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -1962,10 +1962,22 @@
@cindex attribute syntax
This section describes the syntax with which @code{__attribute__} may be
-used, and the constructs to which attribute specifiers bind, for the C
+used, and the constructs to which attribute specifiers bind for the C
-language. Some details may vary for C++ and Objective-C@. Because of
+language and (to a limited degree) some of its descendants.
+
+The keyword @code{__attribute__} allows you to specify special
+attributes when making a declaration. This keyword is followed by an
+attribute specification inside double parentheses.
+
+You may also specify attributes with @samp{__} preceding and following
+each keyword. This allows you to use them in header files without
+being concerned about a possible macro of the same name. For example,
+you may use @code{__noreturn__} instead of @code{noreturn}.
+
+GCC plugins may provide their own attributes.
+
-infelicities in the grammar for attributes, some forms described here
-may not be successfully parsed in all cases.
+Because of infelicities in the grammar for attributes, some forms
+described here may not be successfully parsed in all cases.
There are some problems with the semantics of attributes in C++. For
example, there are no manglings for attributes, although they may affect
@@ -2191,6 +2203,9 @@
@cindex attribute of types
@cindex type attributes
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
The keyword @code{__attribute__} allows you to specify special
attributes of @code{struct} and @code{union} types when you define
such types. This keyword is followed by an attribute specification
@@ -2583,6 +2598,9 @@
@cindex attribute of variables
@cindex variable attributes
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
+
The keyword @code{__attribute__} allows you to specify special
attributes of variables or structure fields. This keyword is followed
by an attribute specification inside double parentheses. Some
@@ -3214,14 +3232,17 @@
@cindex functions that have different optimization options
@cindex functions that are dynamically resolved
-In GNU C, you declare certain things about functions called in your program
-which help the compiler optimize function calls and check your code more
-carefully.
+@xref{Attribute Syntax}, for details of the exact syntax for using
+attributes.
-The keyword @code{__attribute__} allows you to specify special
-attributes when making a declaration. This keyword is followed by an
-attribute specification inside double parentheses. The following
-attributes are currently defined for functions on all targets:
+The keyword @code{__attribute__} allows you to specify special attributes
+of function declarations in order to help the compiler optimize function
+calls and check your code more carefully. This keyword is followed by
+an attribute specification inside double parentheses. Other attributes
+are available for types (@pxref{Type Attributes}) and for variables
+(@pxref{Variable Attributes}).
+
+The following attributes are currently defined for functions on all targets:
@code{aligned}, @code{alloc_size}, @code{noreturn},
@code{returns_twice}, @code{noinline}, @code{noclone},
@code{always_inline}, @code{flatten}, @code{pure}, @code{const},
@@ -3237,16 +3258,6 @@
including @code{section} are supported for variables declarations
(@pxref{Variable Attributes}) and for types (@pxref{Type Attributes}).
-GCC plugins may provide their own attributes.
-
-You may also specify attributes with @samp{__} preceding and following
-each keyword. This allows you to use them in header files without
-being concerned about a possible macro of the same name. For example,
-you may use @code{__noreturn__} instead of @code{noreturn}.
-
-@xref{Attribute Syntax}, for details of the exact syntax for using
-attributes.
-
@table @code
@c Keep this table alphabetized by attribute name. Treat _ as space.
--
1.7.4.18.g68fe8
