[Bug libstdc++/110190] New: regex: incorrect match results on DFA engines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110190
Bug ID: 110190
Summary: regex: incorrect match results on DFA engines
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
libstdc++ makes incorrect matches with the sample code in
https://en.cppreference.com/w/cpp/regex/syntax_option_type . (Though the
description of the "leftmost longest rule" is not correct in that page, their
expected results are fine).
Here is a slightly shorter version:
#include
#include
#include
int main()
{
std::string text = "regexp";
std::regex re(".*(ex|gexp)", std::regex::extended);
std::smatch m;
std::regex_search(text, m, re);
std::cout << m[0] << '\n'; // => should be "regexp" on DFA engines
}
This should print "regexp", but libstdc++ prints "regex". (libc++ works fine.)
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #9 from Michel Morin --- > (which even mentions the std::string((const char*)nullptr) case): > https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html Oh, that's good to know. Understood that PEDASSERT fits better. > can we add a "pednonnull" attribute or something to produce a -Wnonnull > warning like the nonnull attribute but w/o affecting code generation as well? I think such an attribute (like Clang's _Nonnull) would be a nice addition. So I grepped Nonnull on libc++, but strangely there are __no__ uses of _Nonnull/__nonnull. I only found a few __gnu__::__nonnull__ in __memory_resource/memory_resource.h. In libc++, std::string constructors have assertions for nullptr check, but there are no attributes.
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #6 from Michel Morin --- True. Detectable is not correct — that's "maybe-detectable" at most, and the bug is not silent. In a code that I checked, the buggy code (`std::cout << NullCharPtr;`) is the last printing call to std::cout, so I failed to see the side-effect. The patchlet using `_GLIBCXX_DEBUG_PEDASSERT` works fine. Actually I would like `_GLIBCXX_DEBUG_ASSERT` (because I've been using `_GLIBCXX_DEBUG` but never `_GLIBCXX_DEBUG_PEDANTIC`), but I guess using `_GLIBCXX_DEBUG_PEDASSERT` rather than `_GLIBCXX_DEBUG_ASSERT` in this case is a delibarate choice.
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #3 from Michel Morin --- >From the safety point of view, I agree with you. But, at the same time, I thought that detectable UB (with the help of sanitizers) is useful than silent bug. How about `throw`ing as in std::string's constructor?
[Bug libstdc++/109891] New: Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
Bug ID: 109891
Summary: Null pointer special handling in ostream's operator <<
for C-strings
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
This code
#include
int main() { std::cout << (char*)nullptr; }
does not cause any bad things (like SEGV), because libstdc++'s
operator<<(ostream, char const*) has special handling of null pointers:
template
inline basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __out, const _CharT* __s)
{
if (!__s)
__out.setstate(ios_base::badbit);
else
__ostream_insert(...);
return __out;
}
Passing a null pointer to this operator is a precondition violation, so the
current implementation perfectly conforms to the C++ standard. But, why don't
we remove this special handling? By doing so, we get
- better interoperability with toolings (i.e. sanitizers can find the bug
easily)
- unnoticeable performace improvement
and we lose
- deterministic behaviors (of poor codes) on a particular stdlib
I believe the first point makes more sense than the last point.
It seems that old special handling `if (s == NULL) s = "(null)";`
(https://github.com/gcc-mirror/gcc/blob/6599da0/libio/iostream.cc#L638) was
removed in GCC 3.0, but reintroduced (in the current form) in GCC 3.2 in
response to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6518 .
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #5 from Michel Morin --- Confirmed the fix. Will send a patch to ML. > I had use -std=c++98 This comment helps me a lot to understand what's going on. Thanks!
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #4 from Michel Morin --- It seems that the reason is: `cp_keyword_starts_decl_specifier_p` in `cp/parser.c` does not include `RID_TYPENAME`. Note that `typedef` is a decl-specifier ([dcl.spec] p.1 in the Standard).
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #3 from Michel Morin --- There is a typo in this PR's Description. Here is a more readable one: When we enable `typeof` GCC extension (e.g. using `-std=gnu++**` options), we get strange did-you-mean suggestions. `typdef int Int;` -> error: 'typdef' does not name a type; did you mean 'typeof'? `typedeff int Int;` -> error: 'typedeff' does not name a type; did you mean 'typeof'? Confirmed on GCC 11.2.
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #5 from Michel Morin --- I put a wrong link for Rust's PR. The correct link is https://github.com/rust-lang/rust/pull/38622 .
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #4 from Michel Morin --- I googled and found that Rust and Python had the same issue (and fixed it): [Rust] https://github.com/rust-lang/rust/issues/38590 (PR: https://github.com/ziglang/zig/pull/6333) [Python] https://bugs.python.org/issue24658 (PR: https://github.com/python/cpython/pull/1705) These bug reports also says that the darwin's `write(…, …, nbyte)` fails when nbyte > INT_MAX, and I confirmed that. > Maybe they do a loop around the read for sizes >= INT_MAX. Sounds good to me.
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #2 from Michel Morin --- Whoa, darwin's (and FreeBSD's too?) `read(…, …, nbyte)` fails when nbyte >= 2^31! This is the culprit, I think. I also found the following description in FreeBSD's manpage of read (https://www.unix.com/man-page/FreeBSD/2/read/): ERRORS [EINVAL] The value nbytes is greater than INT_MAX. Given that the testcase works file when compiled with Clang, libcxx would have some workround for it.
[Bug libstdc++/102259] New: ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
Bug ID: 102259
Summary: ifstream::read(…, count) fails when count >= 2^31 on
darwin
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
Created attachment 51431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51431=edit
Testcase for ifstream::read(…, count >= 2^31)
I tried to read a large file using `ifstream::read` on Mac, but it fails to
read any byte when count >= 2^31. Note that the system is 64-bit and
`std::streamsize` has 8 bytes.
Here is a testcase.
#include
#include
int main() {
std::ifstream is{"2GB.bin", std::ios::binary}; // filesize >= 2^31 bytes
auto buffer = new char[1LL << 31];
is.read(buffer, 1LL << 31);
std::cout << is.good() << " (" << is.gcount() << " bytes)\n";
// Expected output: "1 (2147483648 bytes)"
// Actual output (on Mac): "0 (0 bytes)"
}
My system is macOS 10.15 running on x86_64 Mac. The testcase failed on
Homebrew's GCC (ver. 6, 9, 10, 11) and MacPorts' GCC (ver. 6), but it succeeded
on LLVM Clang (trunk) and Apple Clang (ver. 12).
`ifstream::read(…, count)` works fine when count < 2^31. So if we split
is.read(buffer, 1LL << 31);
into
is.read(buffer, (1LL << 31) - 1);
is.read(buffer + (1LL << 31) - 1, 1);
then everything goes OK.
Additionally, `istringstream::read(…, count >= 2^31)` works fine both on GCC
and Clang.
I don't think this simple issue went unnoticed, so maybe I've missed something.
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 --- Comment #18 from Michel Morin --- Thanks, much appreciated! (In reply to Jonathan Wakely from comment #17) > That's how new features work. If you want to use them, you need the new > version. The time for adding new features to GCC 9 was last year. Agreed in general. If this was a C++2A feature, I would not ask for releasing it in a hurry. New features should be tested enough and we developers can test/use the feature with a gcc-trunk snapshot. (I made this backport request because I (mistakenly) thought that this was a small fix and not a new feature.)
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 --- Comment #15 from Michel Morin --- > Backporting to stable branches should not be done as a way to find bugs. Makes sense. I stand corrected. > The patch affects all targets, not just the ones currently using a PRNG, so > it's not as simple as just saying it must be better. Ah, I didn't notice that. > I'm afraid you aren't making a very good case for backporting it. I just felt that waiting for GCC-10 (i.e. about a year) is a bit too long. (Some of my colleagues suffer from this issue; so I hoped that this fix gets released earlier... but anyway, I'll probably provide them a wrapper to workaround the issue.)
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 --- Comment #13 from Michel Morin --- Pushing this into GCC-9 might help finding bugs (if there are some) and I think having non-deterministic `random_device` _with possible small bugs_ would be more important than having deterministic one.
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 Michel Morin changed: What|Removed |Added CC||mimomorin at gmail dot com --- Comment #11 from Michel Morin --- Could this be back-ported to GCC-9.2?
[Bug c++/83248] Spuriously identifying template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83248 --- Comment #2 from Michel Morin --- Ah, I thought that GCC 5-7 and trunk were maintained. > if it is fixed in GCC 6 please use that. OK, I'll forward the message to the PR in Boost trac.
[Bug c++/83248] New: Spuriously identifying template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83248
Bug ID: 83248
Summary: Spuriously identifying template arguments
Product: gcc
Version: 5.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
On g++-5 in C++ 11, 14, 17 modes, this valid code fails to compile
(tested on g++-5.4 and 5.5, also failed on g++-4.9)
#include
typedef unsigned long long cl_ulong __attribute__((aligned(8)));
void f()
{
cl_ulong x = 0;
std::cout << x;
}
template struct is_unsigned {};
template <> struct is_unsigned< unsigned long long> {};
template <> struct is_unsigned {};
with the following error messages
Line13: error: redefinition of 'struct is_unsigned'
template <> struct is_unsigned {};
^
Line12: error: previous definition of 'struct is_unsigned'
template <> struct is_unsigned< unsigned long long> {};
^
G++-6, 7 (and 4.8) work fine.
I made this testcase by inspecting the bug report to Boost.TypeTraits
(https://svn.boost.org/trac10/ticket/13315).
I tried to make a smaller testcase, but I couldn't get one.
[Bug c++/52036] C++11 allows template parameters to have internal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036
Michel Morin changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment #11 from Michel Morin ---
The internal linkage testcase
template class TestClass {
/* ... */
};
constexpr float pi = 3.14;
int main()
{
TestClass<float, pi> test;
}
compiles successfully from GCC 6.
However, Richard's testcase (i.e. testcase in the Standard)
template class X {
/* ... */
};
const char p[] = "Vivisectionist";
X<int,p> x;
fails to compile even on GCC 7 (in C++11/14 modes) with this error message
error: the value of 'p' is not usable in a constant expression
X<int,p> x;
^
note: 'p' was not declared 'constexpr'
const char p[] = "Vivisectionist";
As the message suggests, if `p` is declared as `constexpr` it compiles fine.
Note that in a C++1z mode (from GCC 5) it compiles fine without `constexpr`.
[Bug c++/77565] New: `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 Bug ID: 77565 Summary: `typdef int Int;` --> did you mean `typeof`? Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mimomorin at gmail dot com Target Milestone: --- Compiling `typdef int Int;` on gcc 7.0.0 (20160904) gives this message: error: 'typedeff' does not name a type; did you mean 'typeof'? I would expect "did you mean 'typedef'?", instead. Note that the edit distance between `typdef` and `typedef` is smaller than the one between `typdef` and `typeof`. So I think it's a bit strange that the compiler suggests `typeof`.
[Bug middle-end/58711] New: Missing uninitialized warning in loop condition (when compiling without optimization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58711
Bug ID: 58711
Summary: Missing uninitialized warning in loop condition
(when compiling without optimization)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
In the following code, `cond` is uninitialized in `while (cond)`. However,
the uninitialized warning (i.e. variable 'cond' is uninitialized when used
here)
does not emit when compiling without optimization.
(If we compile it with optimization option, the warning is properly emitted.)
Tested on gcc 4.4-4.8, 4.9 (trunk).
int main(int argc, char* argv[])
{
int cond;
// Missing uninitialized warning
while (cond != 0) {
// `(void)` is used to avoid unused-value warning
(void)cond;
}
return 0;
}
Clang has the same issue, but it's fixed recently.
( http://llvm.org/bugs/show_bug.cgi?id=16054 )
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
Michel Morin mimomorin at gmail dot com changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment #8 from Michel Morin mimomorin at gmail dot com 2013-03-28
13:11:00 UTC ---
The implementation of N3276 is not complete.
`decltype` in gcc-4.9-20130324 does not require type-completeness
but involves unnecessary template instantiations:
* Compilation of the demonstration code in N3276 (also appeared in
Nathan Ridge's comment in this PR) exhausted memory on my PC,
so I had to quit the compilation.
* Boost's testing code
(https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_decltype_n3276.ipp)
failed to compile.
(One needs to remove `namespace boost_no_cxx11_decltype_n3276 {` and its
closing
brace`}`, and rename `int test()` to `int main()` before the compilation.)
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #13 from Michel Morin mimomorin at gmail dot com 2013-03-29 00:40:59 UTC --- Thanks Jason, Paolo. I'll enable N3276 decltype support in Boost.Config for gcc 4.8.1 and 4.9.0.
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #1 from Michel Morin mimomorin at gmail dot com 2012-02-21 11:51:14 UTC --- Created attachment 26711 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26711 A testcase for N3204 Attached a testcase for N3204 ;)
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #3 from Michel Morin mimomorin at gmail dot com 2012-02-22 02:43:30 UTC --- Created attachment 26721 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26721 A updated testcase OK, here is a take two!
[Bug c++/50835] New: [4.7 Regression] Lvalue-ness of conditional operator results is incorrect in a function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50835
Bug #: 50835
Summary: [4.7 Regression] Lvalue-ness of conditional operator
results is incorrect in a function template
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mimomo...@gmail.com
Created attachment 25578
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25578
Test case (which incorrectly fails to be compiled on gcc-4.7)
Suppose we have the following class
templatetypename T
struct rvalue_probe
{
explicit rvalue_probe(T t) : value(t) {}
operator T () { return value; }
operator T() const { return value; }
T value;
};
Then,
// std::vectorint v;
true ? rvalue_probestd::vectorint (v) : v
should be evaluated to an lvalue.
But in a function template, this is incorrectly evaluated to an rvalue.
Tested on gcc-4.7.0 20111022 (in a C++03 mode).
[Bug c++/50732] New: [type_traits] is_base_ofBase, Derived unnecessarily instantiates Base (which shouldn't be instantiated)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50732
Bug #: 50732
Summary: [type_traits] is_base_ofBase, Derived unnecessarily
instantiates Base (which shouldn't be instantiated)
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mimomo...@gmail.com
Created attachment 25504
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25504
Test case (which fails to be compiled)
Let `Base` be an instance of a class template. By FDIS 20.9.4.3 p3,
`Base` can be incomplete type and its instantiation should be avoided
in `is_base_ofBase, Derived`. But, as can be seen below, g++ erroneously
instantiates `Base` when its definition is visible.
The following code compiles fine:
#include iostream
#include type_traits
template typename T struct non_instantiatable;
int main (int argc, char* argv[])
{
std::cout std::is_base_ofnon_instantiatableint, void::value
std::endl;
return 0;
}
But if we add the definition, the code fails to compile,
since g++ tries to instantiate `non_instantiatableint`:
#include iostream
#include type_traits
template typename T
struct non_instantiatable
{
typedef typename T::THIS_TYPE_CANNOT_BE_INSTANTIATED type;
};
int main (int argc, char* argv[])
{
std::cout std::is_base_ofnon_instantiatableint, void::value
std::endl;
return 0;
}
Tested on g++ 4.7.0 20111008 (experimental).
[Bug c++/49021] [4.6 regression] BOOST_FOREACH over vector segfaults at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49021 Michel MORIN mimomorin at gmail dot com changed: What|Removed |Added CC||mimomorin at gmail dot com --- Comment #13 from Michel MORIN mimomorin at gmail dot com 2011-05-23 09:04:14 UTC --- (In reply to comment #12) This is a bug in BOOST_FOREACH_COMPILE_TIME_CONST_RVALUE_DETECTION. This was already fixed in boost/trunk, and the fix will be released in Boost.1.47. For details, please see the following ticket: [Foreach] Compile-time const rvalue detection fails with gcc 4.6 https://svn.boost.org/trac/boost/ticket/5279
[Bug c++/47999] New: [C++0x] auto type deduction works incorrectly in a function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47999
Summary: [C++0x] auto type deduction works incorrectly in a
function template
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mimomo...@gmail.com
Created attachment 23554
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23554
Test case
When `auto` is initialized with a function return value that is an lvalue
reference, the deduced type should be an lvalue reference.
int identity(int i) { return i; }
void f()
{
int i = 0;
auto x = identity(i); // x has type `int`
}
But, in a function template, auto type deduction incorrectly deduces
the type as an rvalue reference.
template typename T
void f()
{
int i = 0;
auto x = identity(i); // BUG: x has type `int`
}
This bug leads to compilation error in gcc 4.5 and 4.6,
because lvalues cannot bind to rvalue references.
In gcc 4.4, the code compiles fine because lvalues are
allowed to bind to rvalue references.
Tested compilers: gcc-4.4.5, 4.5.2, 4.6-20110219.
(This problem was found by Nathan Ridge.)
[Bug c++/47851] New: [4.6 Regression] [C++0x] Incorrect decltype result for conditional operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47851
Summary: [4.6 Regression] [C++0x] Incorrect decltype result for
conditional operator
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mimomo...@gmail.com
Created attachment 23436
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23436
Test case
Suppose we have a code
struct Type {};
typedef Type const ConstType;
struct ConvertibleToType {
operator Type() { return *reinterpret_castType*(this); }
};
Then expression `true ? ConvertibleToType() : ConstType()` has type `Type`.
But `decltype(true ? ConvertibleToType() : ConstType())` is `Type const`.
Note that, in gcc 4.5, both the type of the expression and its `decltype` are
`Type`.
(In clang TOT, both are `Type const`.)
