: 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 lo
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.
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, s
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 constr
ity: 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 (li
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!
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).
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;` ->
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 .
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.o
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-
mal
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&action=edit
Testcase for ifstream::rea
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 las
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494
Michel Morin changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment
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.
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036
Michel Morin changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment
: 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
NCONFIRMED
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
--- Comment #13 from Michel Morin 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
Michel Morin changed:
What|Removed |Added
CC||mimomorin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043
--- Comment #3 from Michel Morin 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!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043
--- Comment #1 from Michel Morin 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 ;)
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50732
Bug #: 50732
Summary: [type_traits] is_base_of unnecessarily
instantiates Base (which shouldn't be instantiated)
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49021
Michel MORIN changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment
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
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
30 matches
Mail list logo
