[Bug libstdc++/95624] New: std::put_time() and std::strftime() don't recognize %e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95624 Bug ID: 95624 Summary: std::put_time() and std::strftime() don't recognize %e Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: karen.arutyunov at gmail dot com Target Milestone: --- Created attachment 48714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48714=edit Test program For MinGW build of GCC std::put_time() and std::strftime() don't recognize the %e specifier, converting it into the empty string. The attached program demonstrates the issue: $ g++ -std=c++2a test.cxx $ ./a.exe 0 '' 'CD' While the expected output for June 10 should be: 4 'A10B' 'C10D' In case this information helps, the same program produces the correct output on the same host if built with MSVC.
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #8 from Karen --- Thanks for the explanation. In fact it doesn't work even for -D_XOPEN_SOURCE=700 as the latest POSIX edition doesn't specify the aligned_alloc function. On the other hand I don't observe that _XOPEN_SOURCE affects the __cplusplus macro: % cat
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #6 from Karen --- Sorry, you right. gcc version 9.2.0 (Homebrew GCC 9.2.0_2) Target: x86_64-apple-darwin19 Configured with: ../configure --build=x86_64-apple-darwin19 --prefix=/usr/local/Cellar/gcc/9.2.0_2 --libdir=/usr/local/Cellar/gcc/9.2.0_2/lib/gcc/9 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-9 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 9.2.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #4 from Karen --- Here the additional info: GCC version: Apple clang version 11.0.0 (clang-1100.0.33.16) Target: x86_64-apple-darwin19.2.0 Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #3 from Karen --- Created attachment 47723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47723=edit Testcase preprocessed file
[Bug libstdc++/93469] New: memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469
Bug ID: 93469
Summary: memory header fails to compile with _XOPEN_SOURCE
macro defined and -std=c++2a option specified
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: karen.arutyunov at gmail dot com
Target Milestone: ---
While packaging ICU 65.1 for build2 toolchain I end up with the following error
on macOS 10.15.2 with g++ 9.2.0 (Homebrew GCC 9.2.0_2):
In file included from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/stl_algo.h:59,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/string:52,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/stdexcept:39,
from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/array:39,
from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/tuple:39,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/unique_ptr.h:37,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/memory:80,
from
/Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/unicode/localpointer.h:45,
from
/Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/unicode/udata.h:23,
from
/Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/udatamem.h:24,
from
/Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/umapfile.cpp:26:
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/cstdlib:132:11: error:
'::aligned_alloc' has not been declared
132 | using ::aligned_alloc;
| ^
The issue seems to relate to libstdc++ headers and pops up if the C++20
standard is specified on the command line and a program defines the
_XOPEN_SOURCE macro and includes the memory header. It can be reproduced with
the following commands:
% cat <test.cxx
#include
int main (int argc, char* argv[])
{
}
EOF
% g++-9 -D_XOPEN_SOURCE=500 test.cxx
% g++-9 -std=c++2a test.cxx
% g++-9 -D_XOPEN_SOURCE=500 -std=c++2a test.cxx
In file included from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/stl_algo.h:59,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/string:52,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/stdexcept:39,
from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/array:39,
from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/tuple:39,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/unique_ptr.h:37,
from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/memory:80,
from test.cxx:1:
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/cstdlib:132:11: error:
'::aligned_alloc' has not been declared
132 | using ::aligned_alloc;
| ^
[Bug libstdc++/93151] New: system_error header fails to compile with -D_XOPEN_SOURCE=600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151
Bug ID: 93151
Summary: system_error header fails to compile with
-D_XOPEN_SOURCE=600
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: karen.arutyunov at gmail dot com
Target Milestone: ---
Trying to build ICU 65.1 on macOS 10.15.2 with g++ 9.2.0 (Homebrew GCC 9.2.0_2)
ends up with the error:
In file included from
/usr/local/Cellar/gcc/9.2.0_1/include/c++/9.2.0/system_error:39,
from
/usr/local/Cellar/gcc/9.2.0_1/include/c++/9.2.0/bits/std_mutex.h:39,
from
/usr/local/Cellar/gcc/9.2.0_1/include/c++/9.2.0/condition_variable:39,
from ../../common/umutex.h:24,
from ../../common/putil.cpp:68:
/usr/local/Cellar/gcc/9.2.0_1/include/c++/9.2.0/x86_64-apple-darwin19/bits/error_constants.h:135:24:
error: 'EOWNERDEAD' was not declared in this scope
135 | owner_dead = EOWNERDEAD,
|^~
/usr/local/Cellar/gcc/9.2.0_1/include/c++/9.2.0/x86_64-apple-darwin19/bits/error_constants.h:151:34:
error: 'ENOTRECOVERABLE' was not declared in this scope
151 | state_not_recoverable =ENOTRECOVERABLE,
| ^~~
The issue seems to relate to libstdc++ headers and pops up if a program defines
_XOPEN_SOURCE as 600 and includes the system_error header. It can be reproduced
with the following commands:
% cat <test.cxx
#include
int main (int argc, char* argv[])
{
}
EOF
% g++-9 test.cxx
% g++-9 -D_XOPEN_SOURCE=600 test.cxx
In file included from
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/system_error:39,
from test.cxx:1:
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/x86_64-apple-darwin19/bits/error_constants.h:135:24:
error: 'EOWNERDEAD' was not declared in this scope
135 | owner_dead = EOWNERDEAD,
|^~
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/x86_64-apple-darwin19/bits/error_constants.h:151:34:
error: 'ENOTRECOVERABLE' was not declared in this scope
151 | state_not_recoverable =ENOTRECOVERABLE,
| ^~~
[Bug libstdc++/91057] New: Data race in locale(const locale&, Facet*) constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91057
Bug ID: 91057
Summary: Data race in locale(const locale&, Facet*) constructor
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: karen.arutyunov at gmail dot com
Target Milestone: ---
In our build2 toolchain project we instantiate std::basic_regex class template
with a custom character type (line_char) that, in particular, requires
std::regex_traits specialization and defining a locale class that
installs the std::ctype facet in constructor.
Objects of the regex class that inherits from std::basic_regex are
created, used and destroyed concurrently in multiple threads but are not shared
between threads.
The problem is that while creating such an objects std::bad_cast is
sporadically thrown. Unfortunately, I'm unable to reproduce the issue in my
development environment to provide a full stack trace and, moreover, a simple
test to replicate the issue. However, debugging through the creation of these
regex objects makes me think that there is the following data race in the
libstdc++'s locale implementation that may case the described behavior.
The locale(const locale&, Facet*) constructor template (that is called from
multiple threads in our case) calls
_M_impl->_M_install_facet(&_Facet::id, __f);
that in turn calls _M_id() for the passed facet id. On the first call the
locale::id::_M_id() function sets/uses the locale::id::_M_index member in the
thread-unsafe manner:
size_t
locale::id::_M_id() const throw()
{
if (!_M_index)
{
_M_index = ...
}
return _M_index - 1;
}
As a result, 2 locale objects created concurrently in 2 threads with the
mentioned constructor may have a facet of the same type to be saved under
different indexes in the _M_facets array. If that happens then use_facet()
template function called for this facet type will end up badly for one of the
objects, taking the facet pointer from the wrong index (may crash, throw
bad_cast, etc).
