Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
Created attachment 58451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58451=edit
test.cpp Demonstrate the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #14 from Kristian Spangsege
---
Is the underscore intended before `Guard` in `explicit _Guard(__c_locale) { }`
for the GLIBC <= 2.2 case?
Besides that, the full patch looks correct to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #12 from Kristian Spangsege
---
These changes look good to me.
A couple of points:
* Should the `else`s still be there now that the preceding branches terminate
with `break`?
* `do_out()` has the same problem as `do_in()`.
* If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #7 from Kristian Spangsege ---
This bug still exists in GCC 14.0.1. This was tested with the attacked
test_2.cpp. The actual result is `ok`, but it should have been `partial`.
Curiously, this bug does not occur when using the Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #6 from Kristian Spangsege ---
Created attachment 58405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58405=edit
Test whether bug still exists in GCC 14.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063
--- Comment #6 from Kristian Spangsege ---
Thanks for fixing it. Should it be back-ported to earlier GCC versions? From my
point of view, as far back as GCC 11 would be nice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063
--- Comment #1 from Kristian Spangsege ---
By the way, and as expected, this problem does not exist in Clang.
: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
With the latest GCC (13.2) and also with GCC 11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
Kristian Spangsege changed:
What|Removed |Added
CC||kristian.spangsege at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #3 from Kristian Spangsege ---
I would recommend not locking arithmetic to std::uint32_t, and instead working
with std::uint_fast32_t, because I can imaging a platform (current or future)
where 32-bit arithmetic is slower that 64-bit
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
As far as I can tell, std::seed_seq::generate() has a bug when _Type has more
than 32 bits.
The problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86295
--- Comment #2 from Kristian Spangsege ---
Oh, I missed that crucial fact. Sorry. We can close this as invalid then.
On Mon, Jun 25, 2018 at 3:35 PM, redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
>
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
When inserting a range into a `std::vector`, and the copy, or move constructor
for the value type throws at an unfortunate time
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
Created attachment 44316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44316=edit
Code to trigger the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191
Kristian Spangsege changed:
What|Removed |Added
CC||kristian.spangsege at gmail
dot co
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
The `std::make_signed` and `std::make_unsigned` templates appear to be
incorrectly implemented in GCC 4.8.1.
In particular, both `std::make_signedwchar_t::type` and
`std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326
--- Comment #1 from Kristian Spangsege kristian.spangsege at gmail dot com ---
Oops, should have been:
Clang 3.4 with `libc++` does this on x86_64:
std::make_signedwchar_t::type -- int
std::make_unsignedwchar_t::type -- unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341
--- Comment #2 from Kristian Spangsege kristian.spangsege at gmail dot com ---
And more importantly, here:
http://cplusplus.github.io/LWG/lwg-defects.html#1206
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58341
--- Comment #1 from Kristian Spangsege kristian.spangsege at gmail dot com ---
Important related information here:
http://en.cppreference.com/w/Talk:cpp/algorithm/copy_backward
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
The documentation of copy_backward() in bits/stl_algobase.h conflicts with
the C++ standard on the forbidden range of `result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #5 from Kristian Spangsege kristian.spangsege at gmail dot com
2013-02-22 18:04:41 UTC ---
(In reply to comment #4)
I think 13.3 [over.match] ¶2 and 13.3.1 [over.match.funcs] ¶7 say the
function
template specialization must
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #9 from Kristian Spangsege kristian.spangsege at gmail dot com
2013-02-22 23:09:59 UTC ---
Daniell, would you do me the favour of explaining exactly why you think my
example is ill-formed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #10 from Kristian Spangsege kristian.spangsege at gmail dot com
2013-02-22 23:11:13 UTC ---
Daniel - excuse me :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #12 from Kristian Spangsege kristian.spangsege at gmail dot com
2013-02-22 23:38:47 UTC ---
Yes, so far so good, but where does the standard say that if synthesis fails
for a particular candidate function template declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #13 from Kristian Spangsege kristian.spangsege at gmail dot com
2013-02-22 23:46:04 UTC ---
Jonathan,
The complete set is the set *before* the number of arguments is considered to
find the viable subset. To synthesize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #14 from Kristian Spangsege kristian.spangsege at gmail dot com
2013-02-23 00:02:55 UTC ---
Jonathan, you say that:
Foo::type exists unconditionally, so SFINAE doesn't apply.
The invalid type is not in the immediate context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #17 from Kristian Spangsege kristian.spangsege at gmail dot com
2013-02-23 01:35:02 UTC ---
Dude, you are insulting my ego! :-)
Anyway, thanks for pointing me to [temp.deduct]/8. SFINAE certainly does not
apply in my example.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
Bug #: 56421
Summary: Non-matching overload produces template substitution
error
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53102
Bug #: 53102
Summary: Misplaced 'typename' gives access to private type
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50033
Bug #: 50033
Summary: Failing ADL for template-id function call
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
30 matches
Mail list logo
