[Bug c++/56914] New: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56914
Bug #: 56914
Summary: internal compiler error: Segmentation fault
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vini.ipsma...@gmail.com
I tried to compile my code (and the code has a few bugs) and GCC segfault. It's
the first time this happen to me.
I use some experimental C++11 features. The command line argument is:
g++ main2.cpp -std=c++0x
The output is:
../main.cpp: In lambda function:
../main.cpp:17:22: internal compiler error: Segmentation fault
QObject::connect(&req, &HttpServerResponse::end, []() {
^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/56914] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56914 --- Comment #1 from Vinícius dos Santos Oliveira 2013-04-11 01:01:55 UTC --- Created attachment 29852 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29852 The preprocessed source file.
[Bug c++/56914] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56914 --- Comment #5 from Vinícius dos Santos Oliveira 2013-05-05 18:32:14 UTC --- I tried to reproduce the bug today and nothing happened. I'm still using GCC 4.8.0, but my system changed a lot (ArchLinux is a rolling release distro) and I can't say what is the difference that could be the bug's reason.
[Bug libstdc++/87493] New: chrono::system_clock unusable with std::tm due to misaligned precisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87493 Bug ID: 87493 Summary: chrono::system_clock unusable with std::tm due to misaligned precisions Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: vini.ipsmaker at gmail dot com Target Milestone: --- This code doesn't work: std::tm cal_time; cal_time.tm_year = year; cal_time.tm_mon = month; cal_time.tm_mday = day; cal_time.tm_hour = hour; cal_time.tm_min = min; cal_time.tm_sec = sec; std::time_t t1, t2; t1 = timegm(&cal_time); auto mydt = std::chrono::system_clock::from_time_t(t1); t2 = std::chrono::system_clock::to_time_t(mydt); assert(t1 == t2); I tracked the problem down to libstdc++ sources codes. system_clock::duration is nanoseconds: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/chrono;h=871c896144a23f37de858668a16388a4bc884d56;hb=HEAD#l830 and nanoseconds is backed by int64_t: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/chrono;h=871c896144a23f37de858668a16388a4bc884d56;hb=HEAD#l605 However, seconds is used to convert between time_t and chrono::system_clock::time_point: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/chrono;h=871c896144a23f37de858668a16388a4bc884d56;hb=HEAD#l855 And seconds is backed by a int64_t too: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/chrono;h=871c896144a23f37de858668a16388a4bc884d56;hb=HEAD#l614 There is no way to preserve time_t value between conversions involving chrono::system_clock::time_point and time_t.
[Bug libstdc++/87493] chrono::system_clock unusable with std::tm due to misaligned precisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87493 Vinícius dos Santos Oliveira changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Vinícius dos Santos Oliveira --- >Recall that, from POSIX, `tm.tm_year` is supposed to be a number counted from >1900. Oh, I made this mistake. `std::chrono::system_clock` precision is probably enough. Thanks. Closing.
[Bug c++/66254] New: Member function shadowing enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66254 Bug ID: 66254 Summary: Member function shadowing enum classes Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vini.ipsmaker at gmail dot com Target Milestone: --- Created attachment 35600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35600&action=edit The test code to trigger the error The attached code compiles fine on clang, but fails with GCC. C++11 mode is required to compile the code.
[Bug libstdc++/98449] New: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Bug ID: 98449 Summary: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: vini.ipsmaker at gmail dot com Target Milestone: --- Details of the issue can be found at: https://cplusplus.github.io/LWG/issue3343 I have a code base affected by this issue.
[Bug libstdc++/108859] New: Exception thrown by std::filesystem::copy() is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108859
Bug ID: 108859
Summary: Exception thrown by std::filesystem::copy() is wrong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vini.ipsmaker at gmail dot com
Target Milestone: ---
std::filesystem::filesystem_error::path1() and
std::filesystem::filesystem_error::path2() should contain the paths for the
most deeply-nested call, not the outermost call. It's discarding information
regarding the error that actually occurred.
#include
#include
int main(int argc, char *argv[])
{
try {
std::filesystem::copy(std::filesystem::path{argv[1]},
std::filesystem::path{argv[2]},
std::filesystem::copy_options::recursive);
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << e.what() << '\n' << e.path1() << '\n' << e.path2() <<
'\n';
}
}
If a file already exists, path1() should not be argv[1], but the file that
failed to copy. Same for path2().
[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 --- Comment #3 from Vinícius dos Santos Oliveira --- LLVM's libcxx already applied this 1-line patchset: https://github.com/llvm/llvm-project/commit/64fc3cd55d586498dd21c5b3cfaa755793913772 Can we have the same here on GCC side (I've already submitted the patch earlier).
[Bug libstdc++/108861] New: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 Bug ID: 108861 Summary: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: vini.ipsmaker at gmail dot com Target Milestone: --- Created attachment 54493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54493&action=edit bugfix Releasing the mutex before the call to notify_all is an optimization. This optimization cannot be used here. The thread waiting on the condition might destroy the associated resources -- mutex + condition variable -- and the notifier thread will access an destroyed variable -- the condition variable. In fact, notify_all_at_thread_exit is meant exactly to join on detached threads, and the waiting thread doesn't expect for the notifier thread to access any further shared resources, making this scenario very likely to happen. The waiting thread might awake spuriously on the release of the mutex lock. The reorder is necessary to prevent this race. LLVM's libcxx already fixed the issue: https://github.com/llvm/llvm-project/commit/64fc3cd55d586498dd21c5b3cfaa755793913772
[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Vinícius dos Santos Oliveira changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #2 from Vinícius dos Santos Oliveira --- > Isn't this just Bug 98449? Why did you close that as FIXED? Nobody is going to fix 98449. The ONE-line patchset fixing the issue was there for YEARS. Why does it take so many years to review ONE line? It's obvious that it'll just hang there forever. Meanwhile I have a code base affected by this issue.
[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #5 from Vinícius dos Santos Oliveira --- > Because there is an open defect report against the C++ standard about this. > Basically until that is resolved, GCC's behavior is considered correct. How clueless of me to miss such obvious fact. So it turns out that notify_all_at_thread_exit() does *not* have any bugs and can be used safely? I reverted the GCC workaround I had in my codebase. We can close the issue already. It was dumb of me to even assume that GCC could have bugs.
[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Vinícius dos Santos Oliveira changed: What|Removed |Added CC||vini.ipsmaker at gmail dot com --- Comment #2 from Vinícius dos Santos Oliveira --- Created attachment 51126 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51126&action=edit bugfix Here's a patch fixing the issue. If you want a codebase affected by the issue, here's the code for a thread joining detached threads through a condition variable: https://gitlab.com/emilua/emilua/-/blob/e5706426305733af02983ecb92a08dd8a00ebf2e/src/main.ypp#L275 Once the condition is met, both resources (mutex + condition variables) are destroyed just before the application exits. Therefore I cannot use notify_all_at_thread_exit (there would be a race there).
