https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #36 from Pedro Alves ---
(In reply to Jason Merrill from comment #33)
> (In reply to Pedro Alves from comment #32)
> > Usually maybe-uninit warnings point to false positives involving scalars,
> > and initializing them is practically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #35 from Manuel López-Ibáñez ---
In any case, looking at the uninit dump with -fdump-tree-all-all-lineno it
appears that GCC knows the block where the warning is triggered is never
executed:
;; basic block 13, loop depth 0, count 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #34 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #15)
> I think the following smaller test case independent of libstdc++ captures
> the same issue as the bigger test case in comment #4. Again, declaring f()
> n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #33 from Jason Merrill ---
(In reply to Pedro Alves from comment #32)
> Usually maybe-uninit warnings point to false positives involving scalars,
> and initializing them is practically free. But here the size of T may be
> significan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #32 from Pedro Alves ---
Right, the potentially-sensitive aspect is what I mean to stress here. Usually
maybe-uninit warnings point to false positives involving scalars, and
initializing them is practically free. But here the size o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #31 from Jason Merrill ---
(In reply to Pedro Alves from comment #30)
> I assume so, but do we really want to zero-initialize the buffer? T might
> be large, and I'd think that pessimization to quiet a warning isn't the
> right way t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #30 from Pedro Alves ---
I assume so, but do we really want to zero-initialize the buffer? T might be
large, and I'd think that pessimization to quiet a warning isn't the right way
to go?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #28 from Martin Jambor ---
The RFC did not receive any real negative feedback so I proposed to commit an
updated patch:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #27 from Martin Jambor ---
(In reply to Manuel López-Ibáñez from comment #26)
> Hi Martin,
>
> Wouldn't it be better if the testcase tested that no warning is given for a
> true case? Otherwise if the bug is fixed, no warning will be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #26 from Manuel López-Ibáñez ---
Hi Martin,
Wouldn't it be better if the testcase tested that no warning is given for a
true case? Otherwise if the bug is fixed, no warning will be given, no
matter the option. Or have a testcase that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #25 from Martin Jambor ---
I have posted an RFC patch alleviating the situation somewhat to the mailing
list:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00614.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #24 from Jonathan Wakely ---
From Bug 92092:
The program below gets the following warning message. I think the program is
well-formed (Clang 9.0.0 accepts it without warning).
** Compiler Flags **
-O2 -std=c++17 -Wall
** Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jonathan Wakely changed:
What|Removed |Added
CC||gnu at kosak dot com
--- Comment #23 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #22 from Jonathan Wakely ---
From Bug 92011:
cat > t.cc <
struct Bar
{
int size_;
Bar( int size )
: size_( size )
{}
};
template
Bar get( T const& val )
{
return Bar( __builtin_strlen(val) );
}
class Foo
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jonathan Wakely changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #20 from Evgeniy Dushistov ---
Also if add one line to code `printf("test\n");`
```
struct FooDeleter {
void operator()(FooOpaque *p) {
printf("test\n");
Foo_free(p);
}
};
```
gcc don't report any warning,
and valgrind a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Evgeniy Dushistov changed:
What|Removed |Added
CC||dushistov at mail dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #17 from Martin Sebor ---
The only way to avoid the warning in C (or std::optional) that I can think of
is to somehow obscure the access to the boolean flag. Using volatile works but
looks like it has a cost that users wouldn't be ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #16 from Pedro Alves ---
(In reply to Martin Sebor from comment #15)
> Zero
> initializing A::i first and then setting it to the result of f() also avoids
> the warning and seems like more viable solution/workaround until GCC gets
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #15 from Martin Sebor ---
I think the following smaller test case independent of libstdc++ captures the
same issue as the bigger test case in comment #4. Again, declaring f()
noexcept avoids the warning (but it's not a solution in ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #14 from Tom Tromey ---
(In reply to Jonathan Wakely from comment #8)
> Something like __builtin_unreachable() to say "trust me" would be nice, but
> I can't think how to do it.
How about an attribute that can be attached to the memb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #12 from Eric Gallager ---
(In reply to Marc Glisse from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > Sadly I have no better suggestion than -Wno-error=maybe-uninitialized
>
> Move -Wmaybe-uninitialized from -Wal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #11 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #8)
> Something like __builtin_unreachable() to say "trust me" would be nice, but
> I can't think how to do it.
Some __builtin_unreachable() in _M_get might (?) be us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #10 from Jonathan Wakely ---
(In reply to Pedro Alves from comment #9)
> I had tried that last night, but unfortunately it couldn't get it to work,
> because the warning triggers in A, not optional.
Bah! When we want the warning loca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #9 from Pedro Alves ---
> So maybe we just want to use a #pragma around the std::optional destructor to
> suppress this warning.
I had tried that last night, but unfortunately it couldn't get it to work,
because the warning triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #8 from Jonathan Wakely ---
Something like __builtin_unreachable() to say "trust me" would be nice, but I
can't think how to do it. So maybe we just want to use a #pragma around the
std::optional destructor to suppress this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #7 from Marc Glisse ---
The warning comes from
_Z3setiD.6701 (maybe_a$D6763$m_dummy_6);
which is protected by
_9 = VIEW_CONVERT_EXPR(maybe_a$4_7);
if (_9 != 0)
with
# maybe_a$D6763$m_dummy_6 = PHI
# maybe_a$4_7 = PHI <0(6),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #6 from Pedro Alves ---
That kind of makes sense if you look at optional in isolation, but why does
it _not_ warn if you remove anything related to B and leave only A? That's
what's truly mystifying to me.
Even this change makes the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #5 from Jonathan Wakely ---
(In reply to Pedro Alves from comment #4)
> Looks like I over reduced in the minimal reproducer. std::optional has a
> boolean field to track whether the contained object had been fully
> initialized, whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #4 from Pedro Alves ---
Hi Marc, thanks much for taking a look.
Looks like I over reduced in the minimal reproducer. std::optional has a
boolean field to track whether the contained object had been fully initialized,
which is checke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #3 from Marc Glisse ---
If you mark "get" as noexcept, the warning disappears. If get throws an
exception, you can very well end up running the destructor without having
initialized the members. The warning seems correct to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #2 from Pedro Alves ---
Looks like a regression at some point:
There are no warnings with g++ 5.3.1, either reduced testcase, or with the
obvious change to use std::experimental::optional instead of std::optional.
Also no warnings w
35 matches
Mail list logo
