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
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
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 lo
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
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 thi
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
>
> 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 allegedl
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'
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)
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
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 ne
> 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
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 -Wext
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
>
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
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
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
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 differ
18 matches
Mail list logo
