[Bug libstdc++/71557] time_get is case sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71557 --- Comment #2 from Sergey Zubkov --- er, never mind, that was a different issue, although also with %b
[Bug libstdc++/71557] time_get is case sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71557 Sergey Zubkov changed: What|Removed |Added CC||cubbi at cubbi dot org --- Comment #1 from Sergey Zubkov --- I think it's just %b; I reported this in a duplicate but more specific bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78714
[Bug libstdc++/78714] New: std::get_time does not accept full month name in %b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78714
Bug ID: 78714
Summary: std::get_time does not accept full month name in %b
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: cubbi at cubbi dot org
Target Milestone: ---
The standard says time_get calls get_time which follows "ISO/IEC 9945 function
strptime" ([locale.time.get.members]p8.4)
strptime defines the meaning of %b as "The month, using the locale's month
names; either the abbreviated or full name may be specified.":
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html
however it appears libstdc++ only accepts abbreviated month name:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/locale_facets_nonio.tcc#L673-L678
testcase:
#include
#include
#include
#include
#include
tm t;
int main()
{
assert(strptime("2011-Feb-18 23:12:34", "%Y-%b-%d %H:%M:%S", )); // pass
assert(strptime("2011-February-18 23:12:34", "%Y-%b-%d %H:%M:%S", )); //
pass
{
std::istringstream ss("2011-Feb-18 23:12:34");
assert(ss >> std::get_time(, "%Y-%b-%d %H:%M:%S")); // pass
}
{
std::istringstream ss("2011-February-18 23:12:34");
assert(ss >> std::get_time(, "%Y-%b-%d %H:%M:%S")); // FAIL
}
}
all asserts pass with clang's libc++ and with MSVC 2015
[Bug c++/67259] New: list-initialization of a reference fails to initialize char array from string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67259
Bug ID: 67259
Summary: list-initialization of a reference fails to initialize
char array from string literal
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cubbi at cubbi dot org
Target Milestone: ---
The following is accepted by clang, intel, and msvc, but fails to compile with
gcc (HEAD 6.0.0 20150817)
struct agg { char str[20]; };
int main() {
const agg r {foo};
}
with the following diagnostic:
prog.cc: In function 'int main()':
prog.cc:3:24: error: invalid initialization of reference of type 'const agg'
from expression of type 'brace-enclosed initializer list'
const agg r {foo};
^
prog.cc:3:16: warning: unused variable 'r' [-Wunused-variable]
const agg r {foo};
^
(this also prevents agg x; x = { foo };)
it appears to be one of the consequences of the changes to list initialization
recently made by http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1467
[Bug c++/67249] New: [concepts] ICE parsing f(pairauto, concept)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67249
Bug ID: 67249
Summary: [concepts] ICE parsing f(pairauto, concept)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cubbi at cubbi dot org
Target Milestone: ---
ICE using gcc HEAD 6.0.0 20150816 to compile the following
templateclass T concept bool C1 = true;
templateclass A, class B struct Pair {};
void f(Pairauto, C1);
int main() {}
output:
prog.cc:3:19: internal compiler error: Segmentation fault
void f(Pairauto, C1);
^
0xa65abf crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:352
0x629184 get_concept_from_constraint
/home/heads/gcc/gcc-source/gcc/cp/parser.c:34610
0x629184 synthesize_implicit_template_parm
/home/heads/gcc/gcc-source/gcc/cp/parser.c:34648
0x6297a2 cp_parser_maybe_constrained_type_specifier
/home/heads/gcc/gcc-source/gcc/cp/parser.c:15707
0x62e004 cp_parser_maybe_concept_name
/home/heads/gcc/gcc-source/gcc/cp/parser.c:15732
0x62e004 cp_parser_nonclass_name
/home/heads/gcc/gcc-source/gcc/cp/parser.c:15785
0x644681 cp_parser_type_name
/home/heads/gcc/gcc-source/gcc/cp/parser.c:15571
0x644681 cp_parser_simple_type_specifier
/home/heads/gcc/gcc-source/gcc/cp/parser.c:15485
0x634c55 cp_parser_type_specifier
/home/heads/gcc/gcc-source/gcc/cp/parser.c:15154
0x637273 cp_parser_type_specifier_seq
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19139
0x640262 cp_parser_type_id_1
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19005
0x64035e cp_parser_template_type_arg
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19060
0x64268b cp_parser_template_argument
/home/heads/gcc/gcc-source/gcc/cp/parser.c:14578
0x64268b cp_parser_template_argument_list
/home/heads/gcc/gcc-source/gcc/cp/parser.c:14488
0x64268b cp_parser_enclosed_template_argument_list
/home/heads/gcc/gcc-source/gcc/cp/parser.c:25096
0x643493 cp_parser_template_id
/home/heads/gcc/gcc-source/gcc/cp/parser.c:14162
0x643c21 cp_parser_class_name
/home/heads/gcc/gcc-source/gcc/cp/parser.c:20289
0x63e07e cp_parser_qualifying_entity
/home/heads/gcc/gcc-source/gcc/cp/parser.c:5776
0x63e07e cp_parser_nested_name_specifier_opt
/home/heads/gcc/gcc-source/gcc/cp/parser.c:5462
0x64428f cp_parser_simple_type_specifier
/home/heads/gcc/gcc-source/gcc/cp/parser.c:15457
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 Sergey Zubkov cubbi at cubbi dot org changed: What|Removed |Added CC||cubbi at cubbi dot org --- Comment #9 from Sergey Zubkov cubbi at cubbi dot org --- Just a few volunteers, aral. You can bring up your concerns and suggestions on the Discussion tab of any cppreference.com page and on the Spotted an error? contact us at the bottom of any cplusplus.com/reference page.
[Bug c++/64497] std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497 Sergey Zubkov cubbi at cubbi dot org changed: What|Removed |Added CC||cubbi at cubbi dot org --- Comment #5 from Sergey Zubkov cubbi at cubbi dot org --- FYI, cppreference got that phrasing from POSIX's If the correct value would cause underflow, and is representable, a range error may occur and the correct value shall be returned., which is a part of its optional IEC 60559 Floating-Point extension to the C standard: http://pubs.opengroup.org/onlinepubs/9699919799/functions/scalbln.html
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857 Sergey Zubkov cubbi at cubbi dot org changed: What|Removed |Added CC||cubbi at cubbi dot org --- Comment #5 from Sergey Zubkov cubbi at cubbi dot org --- Looking at existing implementations, libstdc++ is the odd one out: LLVM libc++, IBM XL C++, Microsoft Visual Studio, and Oracle libCstd and stlport4 all let me ignore exactly the number of characters requested, without an extra read from the socket.
[Bug libstdc++/51438] New: std::exception and derived classes are not compatible with std::nested_exception and C++11 in general
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51438
Bug #: 51438
Summary: std::exception and derived classes are not compatible
with std::nested_exception and C++11 in general
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cu...@cubbi.org
As implemented in gcc-4.7.0_alpha2026, struct _Nested_exception has an
implicit destructor, while std::exception and all stdexcept exception classes
have explicit destructors with throw().
Because of this, it's impossible to use std::throw_with_nested with any
exception derived from std::exception:
#include exception
#include stdexcept
int main()
{
try {
throw 2;
} catch(int) {
std::throw_with_nested(std::runtime_error(test));
}
}
gives compilation error:
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha2026/include/g++-v4/exception:155:0,
from test.cc:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha2026/include/g++-v4/bits/nested_exception.h:
In instantiation of ‘struct std::_Nested_exceptionstd::runtime_error’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha2026/include/g++-v4/bits/nested_exception.h:126:60:
required from ‘void std::__throw_with_nested(_Ex, ...) [with _Ex =
std::runtime_error]’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha2026/include/g++-v4/bits/nested_exception.h:140:7:
required from ‘void std::throw_with_nested(_Ex) [with _Ex =
std::runtime_error]’
test.cc:8:58: required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha2026/include/g++-v4/bits/nested_exception.h:78:12:
error: looser throw specifier for ‘virtual
std::_Nested_exceptionstd::runtime_error::~_Nested_exception()’
In file included from test.cc:2:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-alpha2026/include/g++-v4/stdexcept:122:13:
error: overriding ‘virtual std::runtime_error::~runtime_error() throw ()’
suggested fix: remove throw() in exception and stdexcept in C++11 mode.
The C++11 version of class exception should have virtual ~exception(); and
other member functions should be noexcept (per §18.8.1) and the stdexcept
classes should have implicit dtors (per §19.2).
[Bug libstdc++/51288] New: get_money implementation is missing the sentry object (does not skip leading whitespace)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51288
Bug #: 51288
Summary: get_money implementation is missing the sentry object
(does not skip leading whitespace)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cu...@cubbi.org
The I/O manipulator std::get_money, as implemented so far, fails to skip
leading whitespace:
#include iostream
#include sstream
#include locale
#include iomanip
int main()
{
std::string str =$1.23;
std::istringstream s1(str);
try {
s1.imbue(std::locale(en_US.UTF-8));
long double val;
s1 std::get_money(val);
if(s1)
std::cout val '\n';
else
std::cout Bug\n;
} catch(...) {
std::cout Missing locale en_US.UTF-8, cannot run this test\n;
}
}
g++ 4.7.0 2005 output:
Bug
clang++ 2.9/libc++-svn output:
123
The cause:
GCC implementation of operator(basic_istream_CharT, _Traits __is,
_Get_money_MoneyT __f) calls __mg.get right away, but the standard says
§27.7.5/1
The expression in get_money(mon, intl) described below behaves as a
formatted input function (27.7.2.2.1).
§27.7.2.2.1/1
Each formatted input function begins execution by constructing an object of
class sentry with the noskipws (second) argument false.
[Bug libstdc++/50119] New: copy_n advances InputIterator one more time than necessary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50119
Bug #: 50119
Summary: copy_n advances InputIterator one more time than
necessary
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cu...@cubbi.org
The naive implementation of std::copy_n() incorrectly increments InputIterator
one more time than needed, which fails with single-pass input iterators such as
istream_iterator
Test program:
#include algorithm
#include vector
#include sstream
#include iterator
#include iostream
int main()
{
std::istringstream s(1 2 3 4 5);
std::vectorint v;
copy_n(std::istream_iteratorint(s), 2, back_inserter(v));
copy_n(std::istream_iteratorint(s), 2, back_inserter(v));
copy(v.begin(), v.end(), std::ostream_iteratorint(std::cout, ));
std::cout '\n';
}
Output with GCC 4.5.3 and 4.7.0-alpha20110716
1 2 4 5
expected output:
1 2 3 4
Similar bug was fixed in LLVM's libc++ in february 2011, the fix is
straightforward:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110221/039404.html
[Bug c++/48854] New: signal mask is not restored when exiting signal handler via exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48854
Summary: signal mask is not restored when exiting signal
handler via exception
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cu...@cubbi.org
When using -fnon-call-exception to convert a SIGSEGV or SIGFPE to a C++
exception, the straightforward implementation fails to handle the same signal
more than once because it remains masked after the signal handler and the
exception handler have been executed.
While this is reasonable behavior, perhaps it should be briefly mentioned in
the documentation on -fnon-call-exceptions?
Example (compile with -fnon-call-exceptions)
#include iostream
#include stdexcept
#include signal.h
void handler(int signo)
{
std::cerr Signal handler called with signo '\n';
// uncomment the following lines to fix the bug
// sigset_t x;
// sigemptyset (x);
// sigaddset(x, SIGSEGV);
// sigprocmask(SIG_UNBLOCK, x, NULL);
throw std::runtime_error(sigsegv);
}
int main()
{
signal(SIGSEGV, handler);
int* invalid_p = NULL;
// first attempt: always works
try{
*invalid_p = 7;
} catch(const std::exception e)
{
std::cerr main() caught e.what() '\n';
}
// second attempt: fails unless uncommented sigprocmask above
try{
*invalid_p = 7;
} catch(const std::exception e)
{
std::cerr main() caught e.what() '\n';
}
}
reproduced using
gcc 3.4.6 (linux x86_64)
gcc 4.4.1 (linux i386)
gcc 4.5.2 (linux x86_64)
gcc 4.6.0 20110325 (linux x86_64)
[Bug c++/44449] New: incorrectly allows assignment to arrays from braced-init-list (c++0x)
I am able to compile this using -std=c++0x (not even -std=gnu++0x):
#include iostream
int main()
{
int test[] = {1,2,3};
std::cout test[0] test[1] test[2];
test = {4,5,6};
std::cout test[0] test[1] test[2] std::endl;
}
it compiles without warnings (-Wall -Wextra -pedantic) and prints 123456.
Tested on GCC 4.4.3 and GCC 4.5.1-pre
The C++0x final draft (N3092) says, under 5.17/9 [expr.ass]
A braced-init-list may appear on the right-hand side of
an assignment to a scalar [...]
an assignment defined by a user-defined assignment operator [..]
The standard does not allow assignment from a braced-init-list to arrays (and
if was allowed, then, logically, assignment of arrays to arrays would be
allowed as well)
--
Summary: incorrectly allows assignment to arrays from braced-
init-list (c++0x)
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cubbi at cubbi dot org
GCC host triplet: x86_64-pc-linux-gnu-4.5.1-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
