On Mon, 2019-12-16 at 15:45 +0100, Martin Jambor wrote:
> Hi Jeff,
>
> On Sat, Dec 07 2019, Jeff Law wrote:
> > [...]
> > The whole point behind the uninitialized warning is to capture cases
> > where objects may not be properly initialized. For modern code the
> > simple cases typically "just wo
On 12/16/19 2:45 PM, Martin Jambor wrote:
> On Sat, Dec 07 2019, Jeff Law wrote:
>> [...]
> I'm afraid I that -Wmaybe-uninitialized is getting out of hand. I bet
> that some users regularly get these warnings coming from c++ header
> "libraries" (like they sometimes come out our vec.h which recen
Hi Jeff,
On Sat, Dec 07 2019, Jeff Law wrote:
> [...]
> The whole point behind the uninitialized warning is to capture cases
> where objects may not be properly initialized. For modern code the
> simple cases typically "just work". What is by far the most
> interesting cases are those with compl
Hi,
On Tue, Nov 26 2019, Michael Witten wrote:
> [...]
> From what I've read, `-Wmaybe-uninitialized' is essentially
> customized for `-O2',
I don't think that is true. It can be perfectly useful -O1 and there
are many nasty false positives at -O2 too.
> [...]
> * If `-Wmaybe-uninitia
On Tue, 2019-11-26 at 19:33 +, Michael Witten wrote:
> 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).
>
> Theref
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
Hi,
On Wed, 20 Feb 2019, Jeff Law wrote:
> No, I'm saying the distinction between maybe and always uninitialized is
> a false distinction. Code duplication can easily take something that
> triggers a "maybe" warning and turn it into a "always" warning. The
> distinction between them is just bog
On 2/20/19, Jeff Law wrote:
> On 2/1/19 1:31 PM, Marc Glisse wrote:
>>
>> I am not surprised, but I had to at least start the conversation. Would
>> you mind providing a patch that changes the definition of -Wall, since
>> the current one doesn't quite match reality anymore? Also, what do you
>> r
On 2/1/19 1:31 PM, Marc Glisse wrote:
>
> I am not surprised, but I had to at least start the conversation. Would
> you mind providing a patch that changes the definition of -Wall, since
> the current one doesn't quite match reality anymore? Also, what do you
> recommend people do when they hit fa
On 2/2/19 1:20 PM, Segher Boessenkool wrote:
> On Fri, Feb 01, 2019 at 12:27:57PM -0700, Jeff Law wrote:
>> On 2/1/19 7:01 AM, Marek Polacek wrote:
>>> On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> My opin
On 2/3/19 3:02 AM, Marc Glisse wrote:
> On Sat, 2 Feb 2019, Martin Sebor wrote:
>
>> I don't feel too strongly about whether -Wmaybe-uninitialized should
>> be in -Wall or in -Wextra, and I might even be somewhat more inclined
>> to expect to find it in the latter. But since you sound like you ar
On 2/20/19 8:11 AM, Martin Sebor wrote:
> On 2/20/19 7:25 AM, Jeff Law wrote:
>> On 2/20/19 5:36 AM, Pedro Alves wrote:
>>> On 02/05/2019 05:07 PM, Jeff Law wrote:
FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
Not everything builds with -Wall -Werror, but lots
On 2/20/19 7:25 AM, Jeff Law wrote:
On 2/20/19 5:36 AM, Pedro Alves wrote:
On 02/05/2019 05:07 PM, Jeff Law wrote:
FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
Not everything builds with -Wall -Werror, but lots of packages do.
I've only seen one maybe-uninit warning
On 2/20/19 5:36 AM, Pedro Alves wrote:
> On 02/05/2019 05:07 PM, Jeff Law wrote:
>> FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
>> Not everything builds with -Wall -Werror, but lots of packages do.
>> I've only seen one maybe-uninit warning cause problems -- it was
>> s
On 02/05/2019 05:07 PM, Jeff Law wrote:
> FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
> Not everything builds with -Wall -Werror, but lots of packages do.
> I've only seen one maybe-uninit warning cause problems -- it was
> spurious and for a memory object. I didn't di
On 2/4/19 3:52 PM, Martin Jambor wrote:
> Hi,
>
> On Mon, Feb 04 2019, Marc Glisse wrote:
>> On Mon, 4 Feb 2019, Martin Sebor wrote:
>>>
>
> ...
>
>>> You're right that this is hard to imagine without first hand experience
>>> with the problem. If this is a common pattern with the warning in C+
On 2/14/19 7:23 AM, Tom Tromey wrote:
>> "Marc" == Marc Glisse writes:
>
>>> Lastly, in the case of uninitialized variables, the usual solution
>>> of initializing them is trivial and always safe (some coding styles
>>> even require it).
>
> Marc> Here it shows that we don't work with the sa
> "Marc" == Marc Glisse writes:
>> Lastly, in the case of uninitialized variables, the usual solution
>> of initializing them is trivial and always safe (some coding styles
>> even require it).
Marc> Here it shows that we don't work with the same type of code at all. If
Marc> I am using a bo
On 2/4/19 11:24 PM, Marc Glisse wrote:
> On Mon, 4 Feb 2019, Martin Jambor wrote:
>
>>> Looking for "optional" and "-Wmaybe-uninitialized" shows
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
>>>
>>> Google also gives
>>> https://www.b
On Mon, 4 Feb 2019, Martin Jambor wrote:
Looking for "optional" and "-Wmaybe-uninitialized" shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Google also gives
https://www.boost.org/doc/libs/1_69_0/libs/optional/doc/html/boost_optional/t
On 2/4/19, Martin Jambor wrote:
> Hi,
>
> On Mon, Feb 04 2019, Marc Glisse wrote:
>> On Mon, 4 Feb 2019, Martin Sebor wrote:
>>>
>
> ...
>
>>> You're right that this is hard to imagine without first hand experience
>>> with the problem. If this is a common pattern with the warning in C++
>>> clas
On 2/4/19, Martin Sebor wrote:
>>> In practice, false positives (and negatives) of both kinds, whether
>>> they fit the formal definition or the informal one, are the nature
>>> of virtually all non-trivial static diagnostics, certainly all those
>>> that depend on control or data flow analysis.
Hi,
On Mon, Feb 04 2019, Marc Glisse wrote:
> On Mon, 4 Feb 2019, Martin Sebor wrote:
>>
...
>> You're right that this is hard to imagine without first hand experience
>> with the problem. If this is a common pattern with the warning in C++
>> class templates in general, a representative test c
On Mon, 4 Feb 2019, Martin Sebor wrote:
In practice, false positives (and negatives) of both kinds, whether
they fit the formal definition or the informal one, are the nature
of virtually all non-trivial static diagnostics, certainly all those
that depend on control or data flow analysis. Some
In practice, false positives (and negatives) of both kinds, whether
they fit the formal definition or the informal one, are the nature
of virtually all non-trivial static diagnostics, certainly all those
that depend on control or data flow analysis. Some are due to bugs
or limitations in the impl
On Fri, Feb 1, 2019 at 8:28 PM Jeff Law wrote:
>
> On 2/1/19 7:01 AM, Marek Polacek wrote:
> > On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> >> Hi Marc,
> >>
> >> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> >>> -Wmaybe-uninitialized generates false positi
On Sat, Feb 2, 2019 at 9:20 PM Segher Boessenkool
wrote:
>
> On Fri, Feb 01, 2019 at 12:27:57PM -0700, Jeff Law wrote:
> > On 2/1/19 7:01 AM, Marek Polacek wrote:
> > > On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> > >> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse
On Sat, 2 Feb 2019, Martin Sebor wrote:
I don't feel too strongly about whether -Wmaybe-uninitialized should
be in -Wall or in -Wextra, and I might even be somewhat more inclined
to expect to find it in the latter. But since you sound like you are
gearing up for proposing other changes in the s
On 2/1/19 4:32 AM, Marc Glisse wrote:
Hello,
first, I expect this to be controversial, so feel free to complain.
I don't feel too strongly about whether -Wmaybe-uninitialized should
be in -Wall or in -Wextra, and I might even be somewhat more inclined
to expect to find it in the latter. But s
On Fri, Feb 01, 2019 at 12:27:57PM -0700, Jeff Law wrote:
> On 2/1/19 7:01 AM, Marek Polacek wrote:
> > On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> >> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> >>> My opinion is that -Wmaybe-uninitialized would serve it
On Fri, 1 Feb 2019, Jeff Law wrote:
On 2/1/19 7:01 AM, Marek Polacek wrote:
On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
Hi Marc,
On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
-Wmaybe-uninitialized generates false positives, we can tweak the compiler
to
On 2/1/19 7:01 AM, Marek Polacek wrote:
> On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
>> Hi Marc,
>>
>> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
>>> -Wmaybe-uninitialized generates false positives, we can tweak the compiler
>>> to reduce them, but there
On Fri, Feb 01, 2019 at 09:01:53AM -0500, Marek Polacek wrote:
> On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> > > Some people tend to consider that
> > > if a warning is not part of -Wall, it might as well not exist. Obviously
> > > I
> > > disagree with that.
> >
> > I
On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> Hi Marc,
>
> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> > -Wmaybe-uninitialized generates false positives, we can tweak the compiler
> > to reduce them, but there will always be some, that's in the nature of
Hi Marc,
On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> -Wmaybe-uninitialized generates false positives, we can tweak the compiler
> to reduce them, but there will always be some, that's in the nature of
> this warning.
That is true for *every* warning; if not, it should be an e
Hello,
first, I expect this to be controversial, so feel free to complain.
The description of -Wall says "This enables all the warnings about
constructions that some users consider questionable, and that are easy
to avoid (or modify to prevent the warning), even in conjunction with
macros."
And
36 matches
Mail list logo
