Re: [RFC] -Weverything

[Marc Glisse]

On Wed, 23 Jan 2019, Jakub Jelinek wrote:


We have that, gcc -Q --help=warning
Of course, for warnings which do require arguments (numerical, or
enumeration/string), one still needs to pick up his choices of those
arguments; no idea what -Weverything would do here, while some warnings
have different levels where a higher (or lower) level is a superset of
another level, what numbers would you pick for e.g. warnings where the
argument is bytes?


For most of them, there is a value that maximizes the number of warnings, 
so the same superset argument applies. -Wframe-larger-than=0 so it shows 
the estimated frame size on every function, -Walloca-larger-than=0 so it 
is equivalent to -Walloca, etc.


--
Marc Glisse

Re: [RFC] -Weverything

[Jonathan Wakely]

On Wed, 23 Jan 2019 at 07:17, Thomas König  wrote:

>
>
> > Am 23.01.2019 um 01:53 schrieb Martin Sebor :
>
> > I often wish GCC supported it -- not in the hopes of finding every
> > conceivable bug or transgression against known coding styles but
> > as a tool to discover warnings that have to be explicitly enabled
> > either by using their own options or by specifying a higher level
> > than the default.
>
> So, maybe an option to list every warning would be better?
>
>
Yes, if the idea is to add something to help debug GCC itself, or help GCC
devs, please don't spell it -Wxxx so it doesn't look like something that
users should care about.

As someone doing lots of support via gcc-help, #gcc@freenode, stackoverflow
and elsewhere, I really don't want to have to keep explaining that
-Weverything was not meant to be used on user code.

__builtin_dynamic_object_size

[Jonathan Wakely]

There's a patch to add __builtin_dynamic_object_size to clang:
https://reviews.llvm.org/D56760

It was suggested that this could be done via a new flag bit for
__builtin_object_size, but only if GCC would support that too
(otherwise it would be done as a separate builtin).

Is there any interest in adding that as an option to __builtin_object_size?

I know Jakub is concerned about arbitrarily complex expressions, when
__builtin_object_size is supposed to always be efficient and always
evaluate at compile time (which would imply the dynamic behaviour
should be a separate builtin, if it exists at all).

Re: [RFC] -Weverything

[Franz Sirl]

Am 2019-01-22 um 19:56 schrieb Jonathan Wakely:

On Tue, 22 Jan 2019 at 18:46, Marc Glisse  wrote:


On Tue, 22 Jan 2019, Thomas Koenig wrote:


Hi,

What would people think about a -Weverything option which turns on
every warning there is?

I think that could be quite useful in some circumstances, especially
to find potential bugs with warnings that people, for some reason
or other, found too noisy for -Wextra.

The name could be something else, of course. In the best GNU tradition,
-Wkitchen-sink could be another option :-)


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and duplicates already
list quite a few arguments. Basically, it could be useful for debugging
gcc or to discover warnings, but gcc devs fear that users will actually
use it for real.


Every LLVM dev I've spoken to thinks their -Weverything was a mistake
and hates it. It was meant to be for option discovery by automated
tools, but users started using it.



The LLVM devs may hate it, but as maintainer of a multi-platform 
multi-compiler automated build framework I _love_ -Weverything. It's 
much easier to handle a compiler upgrade this way without missing any 
new warnings not enabled by -Wall -Wextra. When a new warning shows up 
due to the changed compiler I can immediately decide if I want to 
disable it, leave it as a warning or turn it into an error. Longterm 
maintenance of a -Wno-* list is also a lot less error prone than a 
positive -W* list in my experience.


Franz

Re: __builtin_dynamic_object_size

[Jakub Jelinek]

On Wed, Jan 23, 2019 at 10:40:43AM +, Jonathan Wakely wrote:
> There's a patch to add __builtin_dynamic_object_size to clang:
> https://reviews.llvm.org/D56760
> 
> It was suggested that this could be done via a new flag bit for
> __builtin_object_size, but only if GCC would support that too
> (otherwise it would be done as a separate builtin).
> 
> Is there any interest in adding that as an option to __builtin_object_size?
> 
> I know Jakub is concerned about arbitrarily complex expressions, when
> __builtin_object_size is supposed to always be efficient and always
> evaluate at compile time (which would imply the dynamic behaviour
> should be a separate builtin, if it exists at all).

The current modes (0-3) certainly must not be changed and must return a
constant, that is what huge amounts of code in the wild relies on.

The reason to choose constants only was the desire to make _FORTIFY_SOURCE
cheap at runtime.  For the dynamically computed expressions, the question
is how far it should go, how complex expressions it wants to build and how
much code and runtime can be spent on computing that.

The rationale for __builtin_dynamic_object_size lists only very simple
cases, where the builtin is just called on result of malloc, so that is
indeed easy, the argument is already evaluated before the malloc call, so
you can just save it in a temporary and use later.  Slightly more complex
is calloc, where you need to multiply two numbers (do you handle overflow
somehow, or not?).  But in real world, it can be arbitrarily more complex,
there can be pointer arithmetics with constant or variable offsets,
there can be conditional adjustments of pointers or PHIs with multiple
"dynamic" expressions for the sizes (shall the dynamic expression evaluate
as max over expressions for different phi arguments (that is essentially
what is done for the constant __builtin_object_size, but for dynamic
expressions max needs to be computed at runtime, or shall it reconstruct
the conditional or remember it and compute whatever ? val1 : val2),
loops which adjust pointers, etc. and all that can be done many times in
between where the objects are allocated and where the builtin is used.

Jakub

Re: [RFC] -Weverything

[Jonathan Wakely]

On Wed, 23 Jan 2019 at 11:21, Franz Sirl wrote:
> The LLVM devs may hate it, but as maintainer of a multi-platform
> multi-compiler automated build framework I _love_ -Weverything. It's
> much easier to handle a compiler upgrade this way without missing any
> new warnings not enabled by -Wall -Wextra.

When there are new warnings that aren't enabled by -Wall -Wextra,
there's probably a reason they aren't enabled by default.

"Gotta catch 'em all" is for Pokemon, not compiler warnings ;-)

Re: [RFC] -Weverything

[Thomas König]

> Am 23.01.2019 um 12:36 schrieb Jonathan Wakely :
> 
> When there are new warnings that aren't enabled by -Wall -Wextra,
> there's probably a reason they aren't enabled by default.

-Wconversion-extra is an example of such a warning.

It catches a very common error people make in Fortran, see 
https://gcc.gnu.org/ml/fortran/2019-01/msg00178.html for a false bug report 
which it would have caught early.

We left it out of -Wextra because people felt it was too noisy.

Re: [RFC] -Weverything

[Paul Richard Thomas]

Hi Thomas,

Thanks for initiating this discussion. The responses are very useful.

That said, wouldn't a -ffix-everything option be more useful? :-)

Cheers

Paul

On Wed, 23 Jan 2019 at 13:27, Thomas König  wrote:
>
>
>
> > Am 23.01.2019 um 12:36 schrieb Jonathan Wakely :
> >
> > When there are new warnings that aren't enabled by -Wall -Wextra,
> > there's probably a reason they aren't enabled by default.
>
> -Wconversion-extra is an example of such a warning.
>
> It catches a very common error people make in Fortran, see 
> https://gcc.gnu.org/ml/fortran/2019-01/msg00178.html for a false bug report 
> which it would have caught early.
>
> We left it out of -Wextra because people felt it was too noisy.
>
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: About GSOC.

[Joseph Myers]

On Wed, 23 Jan 2019, Tejas Joshi wrote:

> But I really dont know how to inspect a file like real.h (real_value)/real.c?

Use cc1 to build a test program with selected floating-point constants in 
it.  Set breakpoints on appropriate functions in real.c (e.g. related to 
converting strings for real constants into the internal representation).  
Look at the representation produced for those constants to determine the 
particular conventions being used.

-- 
Joseph S. Myers
jos...@codesourcery.com

ANN: gcc-python-plugin 0.17

[David Malcolm]

gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the
CPython interpreter within GCC, allowing you to write new compiler
warnings in Python, generate code visualizations, etc.

This release adds support for gcc 9 (along with continued support for
gcc 4.6, 4.7, 4.8, 4.9, 5, 6, 7, and 8).

Unfortunately, the reference-count checker no longer works for gcc 7
onwards, so it is disabled when embedded in those builds of gcc.

Additionally, this release contains the following improvements:

* the plugin can now be built in a separate build directory from the
  source directory (thanks to Tom de Vries)

* gcc-with-cpychecker gained a --cpychecker-verbose option

Tarball releases are available at:
  https://github.com/davidmalcolm/gcc-python-plugin/releases

Prebuilt-documentation can be seen at:
  http://gcc-python-plugin.readthedocs.org/en/latest/index.html

The plugin is Free Software, licensed under the GPLv3 or later.

Enjoy!
Dave Malcolm

Annoying silly warning emitted by gcc?

[Warren D Smith]

x = x^x;

The purpose of the above is to load "x" with zero.
For very wide types, say 256 bits wide, explicitly loading 0
is deprecated by Intel since taking too much memory.
XORing x with itself always yields 0 and is allegedly
a better thing to do.

But the problem is, gcc complains:
variable 'x' is uninitialized when used here [-Wuninitialized]
note: initialize the variable 'x' to silence this warning

Well, the thing is, it DOES NOT MATTER that x is not initialized,
or initialized with wrong data.  No matter what was in x, it becomes 0.

So, how to get Gcc to shut up and quit whining about this?
I do not want to actually load 0.

-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

Re: Annoying silly warning emitted by gcc?

[Paul Koning]

> On Jan 23, 2019, at 7:15 PM, Warren D Smith  wrote:
> 
> x = x^x;
> 
> The purpose of the above is to load "x" with zero.
> For very wide types, say 256 bits wide, explicitly loading 0
> is deprecated by Intel since taking too much memory.
> XORing x with itself always yields 0 and is allegedly
> a better thing to do.
> 
> But the problem is, gcc complains:
> variable 'x' is uninitialized when used here [-Wuninitialized]
> note: initialize the variable 'x' to silence this warning
> 
> Well, the thing is, it DOES NOT MATTER that x is not initialized,
> or initialized with wrong data.  No matter what was in x, it becomes 0.
> 
> So, how to get Gcc to shut up and quit whining about this?
> I do not want to actually load 0.

The way to tell gcc that you don't want to hear about x being uninitialized is 
to write the declaration as an initialization to itself:

int x = x;
/* then you can do what you wanted: */
x = x ^ x;

But it seems that GCC should be able to tell expressions that do not depend on 
x and suppress the complaint about uninitialized x if so.

But furthermore: the "too much memory" argument makes no sense.  You should 
write what you mean in the plainest terms, in other words: "x = 0".  It is then 
up to the optimizer to generate the best code for it.  If xor is the better 
code that's what should come out.  Does it already?  If so, Intel's advice is 
simply wrong, ignore it and write the simple code.  If the compiler actually 
generates a transfer from a (potentially big) zero, that might be a missed 
optimization bug.  In that case, Intel's advice may possibly be useful as a 
temporary workaround for this bug.  But only if the small savings is so 
important that obfuscating your source code is justified.

   paul

Re: Annoying silly warning emitted by gcc?

[Andrew Pinski]

On Wed, Jan 23, 2019 at 4:16 PM Warren D Smith  wrote:
>
> x = x^x;
>
> The purpose of the above is to load "x" with zero.
> For very wide types, say 256 bits wide, explicitly loading 0
> is deprecated by Intel since taking too much memory.
> XORing x with itself always yields 0 and is allegedly
> a better thing to do.
>
> But the problem is, gcc complains:
> variable 'x' is uninitialized when used here [-Wuninitialized]
> note: initialize the variable 'x' to silence this warning
>
> Well, the thing is, it DOES NOT MATTER that x is not initialized,
> or initialized with wrong data.  No matter what was in x, it becomes 0.
>
> So, how to get Gcc to shut up and quit whining about this?
> I do not want to actually load 0.

I don't see why you think the compiler will not do the right thing and
do the xor trick when there is a zero in the code.

Thanks,
Andrew Pinski


>
> --
> Warren D. Smith
> http://RangeVoting.org  <-- add your endorsement (by clicking
> "endorse" as 1st step)

Re: Annoying silly warning emitted by gcc?

[Joseph Myers]

On Wed, 23 Jan 2019, Warren D Smith wrote:

> x = x^x;
> 
> The purpose of the above is to load "x" with zero.
> For very wide types, say 256 bits wide, explicitly loading 0
> is deprecated by Intel since taking too much memory.
> XORing x with itself always yields 0 and is allegedly
> a better thing to do.

There is widespread support in WG14 for C semantics being uninitialized 
values being unstable, so that there is no need for the two reads of x to 
return the same value and x^x is also an unspecified value.  See e.g. 
.

-- 
Joseph S. Myers
jos...@codesourcery.com

RE: Annoying silly warning emitted by gcc?

[Joe Buck]

 
On Wed, Jan 23, 2019 at 4:16 PM Warren D Smith  wrote:
>
> x = x^x;
>
> The purpose of the above is to load "x" with zero.

Don't waste your time.  Intel was offering that advice to writers of assembly 
language and compilers.  Gcc already does the right thing.

Try the following on an Intel/AMD machine:

% cat z.c
long long zero() {
long long tmp = 0LL;
return tmp;
}
% gcc -O2 -S z.c
% cat z.s
.file   "z.c"
.text
.p2align 4,,15
.globl  zero
.type   zero, @function
zero:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size   zero, .-zero
.ident  "GCC: (GNU) 4.8.3"
.section.note.GNU-stack,"",@progbits

Re: Annoying silly warning emitted by gcc?

[Warren D Smith]

The x=x "initialization" idea by paulkon...@comcast.net
failed to turn off the warning for me.

Joe Buck may be right that gcc "already does the right thing"
but actually I was dealing with not a 64-bit wide, but
actually a 128-bit-wide type, which might
later become 256-wide or even 512; and to load it with 0s actually needs a lot
of loading of constants from the instruction stream.


-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

Re: __builtin_dynamic_object_size

[Martin Sebor]

On 1/23/19 3:40 AM, Jonathan Wakely wrote:

There's a patch to add __builtin_dynamic_object_size to clang:
https://reviews.llvm.org/D56760

It was suggested that this could be done via a new flag bit for
__builtin_object_size, but only if GCC would support that too
(otherwise it would be done as a separate builtin).

Is there any interest in adding that as an option to __builtin_object_size?

I know Jakub is concerned about arbitrarily complex expressions, when
__builtin_object_size is supposed to always be efficient and always
evaluate at compile time (which would imply the dynamic behaviour
should be a separate builtin, if it exists at all).


I am very interested in doing something like that and handling at
least the simple cases (with minimum runtime overhead).  I haven't
thought about it hard enough to have a clear idea whether it needs
a new built-in or whether the current one can be extended to handle
non-constant cases as well (perhaps by adding a new bit) but I would
certainly want the existing libc infrastructure to make use of
the non-constant sizes without having to change.  The overhead of
handling the more complex cases that Jakub is concerned about could
be controlled by some customizable parameter so I don't think that
should stand in the way.

Besides handling non-constant object sizes I would also like GCC to
get better about detecting and preventing subobject overflow (such
as in strcpy (s.m, "foobar") where GCC transforms the strcpy call
to memcpy which is allowed to overwrite whatever follows s.m).

Martin

Re: Annoying silly warning emitted by gcc?

[Jakub Jelinek]

On Wed, Jan 23, 2019 at 09:05:15PM -0500, Warren D Smith wrote:
> The x=x "initialization" idea by paulkon...@comcast.net
> failed to turn off the warning for me.
> 
> Joe Buck may be right that gcc "already does the right thing"
> but actually I was dealing with not a 64-bit wide, but
> actually a 128-bit-wide type, which might
> later become 256-wide or even 512; and to load it with 0s actually needs a lot
> of loading of constants from the instruction stream.

Do you mean vectors or aggregates or something else?
GCC doesn't support integral scalar types with 256 or higher bit precision.
And we vectors gcc does use xor internally too:
typedef int V __attribute__((vector_size (64)));
struct S { __int128_t x, y; };

V
foo (void)
{
  return (V) {};
}

struct S
bar (void)
{
  return (struct S) {};
}
emits
vpxor   %xmm0, %xmm0, %xmm0
with -O2 -mavx512f in foo and
vpxor   %xmm0, %xmm0, %xmm0
movq%rdi, %rax
vmovaps %xmm0, (%rdi)
vmovaps %xmm0, 16(%rdi)
in bar.

As has been said, the recommendation by Intel is for compiler developers and
assembly writers.

Jakub