[Bug c++/94025] New: Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025
Bug ID: 94025
Summary: Expected-to-fail compilation goes through by not
detecting mutable-specifier on lambda
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leonleon77 at gmail dot com
Target Milestone: ---
From a small thread on the gcc-help mailing list
https://gcc.gnu.org/ml/gcc-help/2020-03/msg3.html
( btw thanks to Jonathan for clearing up various considerations
https://gcc.gnu.org/ml/gcc-help/2020-03/msg00011.html )
there could be a small bug in GCC (albeit not exclusive to GCC :) in that it
doesn't consider the non-const (mutable) nature of lambda's function call
operator when dealing with const objects which are stateless (e.g. lambda
captures nothing).
In the following example:
template
void foo(T const f)
{
f();
}
int main()
{
foo([]() mutable {});
}
the compilation would probably be expected to fail if one is to follow the
standard definition for lambda expressions, i.e. "... function call operator
... is declared const if and only if the lambda-expression’s
parameter-declaration-clause is not followed by mutable."
Even though one could ponder the inconsequential nature of the above when being
applied to stateless (captures-nothing) lambdas, for the sake of
standard-compliance and even semantic consistency with explicit, yet
equivalent(?), stateless types such as:
struct S {
void operator()()
{
}
};
int main()
{
foo(S());
}
... which dutifully *fails* to compile unless the function call operator is
const-qualified, perhaps lambda with mutable-specifier should also be
consistent and also fail to compile.
Sorry if I'm splitting hairs here :) (so far from my experiments with various
compilers on godbolt.org MSVC was the only one to detect the above and diagnose
the issue, with gcc and clang allowing it to go through).
[Bug libstdc++/91910] New: Debug mode: there is a racing condition between destructors of iterator and the associated container.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910
Bug ID: 91910
Summary: Debug mode: there is a racing condition between
destructors of iterator and the associated container.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: leonleon77 at gmail dot com
Target Milestone: ---
When in Debug Mode (-D_GLIBCXX_DEBUG) there is a racing condition between
destructor of a non-singular iterator and the associated container.
Given the following code (exemplifying concurrent destruction of iterator and
container):
#include
#include
#include
int main(int, char *[]) {
auto s(::std::make_unique<::std::set>());
s->emplace(3);
auto i(::std::make_unique<::std::set::iterator>(s->begin()));
::std::thread t([i(::std::move(i))]() mutable {
i.reset(); // iterator nuked
});
s.reset(); // container nuked
t.join();
}
... a number of safe-iterators' destructors will check-then-use the
pointer-to-container in a non-atomic fashion:
in trunk/libstdc++-v3/include/debug/safe_base.h:100
~_Safe_iterator_base() { this->_M_detach(); }
in trunk/libstdc++-v3/src/c++11/debug.cc:380
void
_Safe_iterator_base::
_M_detach()
{
if (_M_sequence)
{
_M_sequence->_M_detach(this);
_M_reset();
}
}
It is possible for the container to get destroyed in-between the 'if
(_M_sequence)' and '_M_sequence->_M_detach(this)' phases in the above
_M_detach().
[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910
--- Comment #2 from leon ---
(In reply to Andrew Pinski from comment #1)
> Seems like this is a bug in the testcase rather than libstdc++.
>
> >exemplifying concurrent destruction of iterator and container
> That seems like a disaster waiting to happen. Because once the container is
> gone, the iterator is also considered gone. If you did this in a normal
> code without threads it would be invalid to do in that order anyways.
I've checked the above with both: Jonathan Wakely and François Dumont. They
appear to agree that it is a bug in libstdc++ debug mode (they have asked me to
submit the bug report).
On the subject of "normal code without threads"... my understanding is that it
is valid to destroy iterator after the container has been destroyed (we are
talking about just dtor as part of the object going out of scope, not
dereferencing iterator in any way).
Jonathan was very kind to provide an example of valid use (unless I
misunderstood it -- he can correct me of course)... :)
This (destroying iterator after the container) is valid:
{
std::set::iterator iter;
{
std::set s;
iter = s.begin();
} // s.~set() runs here
} // iter.~iterator() runs here
... keeping in mind -- the bug is *not* about deref/using the iterator object
-- just destroying it.
[Bug c++/42446] New: gcc crash (internal compiler error) during the build of C++ code
Whatever the gcc should do, I don't think it should crash in the following case
(I shall try to re-build the latest 4.4.2 series to reproduce it there as well,
if I'll find the time):
Start of code:
template
struct boo {
};
template class Base>
struct goo : Base {
};
int
main()
{
goo goo1;
return 0;
}
Start of command-line which causes the crash:
gcc main.cc
Start of gcc-output as it crashes:
main.cc: In function 'int main()':
main.cc:13: internal compiler error: in dependent_type_p, at
cc1plus/../../../../contrib/gcc/cp/pt.c:12777
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Start of gcc --version output:
%gcc --version
gcc (GCC) 4.2.1 20070719 [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Start of uname -a output:
%uname -a
FreeBSD localhost 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC
2009 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
--
Summary: gcc crash (internal compiler error) during the build of
C++ code
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: leonleon77 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42446
