: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
I am seeing warnings about equality comparison results being unused
[-Wunused-comparison] in libstdc++-v3/include/std/text_encoding - which is
included through locale_classes.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406
--- Comment #2 from Paul Keir ---
Created attachment 59519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59519&action=edit
Test for the proposed fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406
--- Comment #3 from Paul Keir ---
At least for ilogb.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
The std::ilogb overloads for std::float16_t and std::bfloat16_t should return
INT_MAX when given an infinite
y: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
#include
#include
int main(int argc, char *argv[])
{
std::float16_t f0{0}, f1{1};
std::nextafter(f0, f1);
return 0;
}
Compiling the C++23 program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87275
Paul Keir changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 116695, which changed state.
Bug 116695 Summary: [c++11/c++14] Undefined behaviour involving unsequenced
side effects on a memory location during constant evaluation should not compile
https://gcc.gnu.org/bugzilla/show_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116695
Paul Keir changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
The C++14 code below compiles, but should not, as the
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
I often want to be sure that an expression is evaluated at compile time, while
also checking that it produces the expected value. With a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272
--- Comment #8 from Paul Keir ---
I wonder if a small part of this bug still remains. The code below should
#include , but as it doesn't, we get an error message. The
message now gives all the right information but, with -std=c++23 and
-std=c++2
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
The C++26 code below fails to compile with GCC trunk; with Clang it passes. The
error message indicates that the constexpr evaluator uses `const
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
The C++20 program below fails to compile. A call to `basic_string::clear()` in
the move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272
--- Comment #4 from Paul Keir ---
I believe P2448R2 would only allow the code, without the static_assert.
Explicitly calling `test()`, `Jam::Jam()` and then `Jam::ft()` here would mean
evaluating a non-constexpr function (i.e. `ft`). ft is *cons
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
[DR 2526](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2526)
clarifies that in C++23 comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272
--- Comment #2 from Paul Keir ---
Thanks. The `-Winvalid-constexpr` mentioned there is a helpful workaround.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
The C++14 code below requires the `constexpr` specifier on the `ft` member
function. Compiling this with `-std=c++14`, `-std=c++17` or `-std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248
Paul Keir changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110714
--- Comment #3 from Paul Keir ---
Actually, there's no need here to delete through the base pointer; so this is
perhaps simpler:
struct Base
{
constexpr Base* get_this() { return this; }
int x;
};
struct Derived : public Base {};
constexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110714
--- Comment #2 from Paul Keir ---
I know. `delete pf` also works. The issue seems to be with the use of the this
pointer within the member function. This is just the MRE - I've come across
this issue twice now in our code base.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Compiling the C++20 MRE code below fails:
struct Base
{
constexpr virtual ~Base() {}
constexpr Base* get_this() { return this; }
int x;
};
struct Derived : public
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 53210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53210&action=edit
The code described in the bug report.
The dynamic_cast, evaluated wit
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 51483
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51483&action=edit
The code described in the bug report.
Compiling the code belo
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 50624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50624&action=edit
The C++ file producing
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 49062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49062&action=edit
A C++ file containing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95514
Paul Keir changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 49012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49012&action=edit
A C++ file containing the code de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96414
--- Comment #1 from Paul Keir ---
constexpr int lt_fun(const char& c1, const char& c2) {
return c1 < c2;
}
constexpr bool doit()
{
char *pc = new char;
const char* s = "a";
*pc = 'b';
lt_fun(*s, *pc); // a < b
*pc = 'a';
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 48981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48981&action=edit
The file containing the code de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95977
Paul Keir changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68342
Paul Keir changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95514
--- Comment #1 from Paul Keir ---
The code above should also include:
int main(int argc, char *argv[])
{
static_assert(test1());
// test1(); // no problem
return 0;
}
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 48671
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48671&action=edit
The code descr
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 47881
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47881&action=edit
The code described in the bug repor
++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 47272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47272&action=edit
The code described in the bug report.
The static_assert expression in the C++
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 45383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45383&action=edit
C++ file which p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83003
Paul Keir changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
--- Comment #13 from Paul Keir ---
Yup, I just came up with exactly the same solution. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
Paul Keir changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71737
--- Comment #1 from Paul Keir ---
Created attachment 38820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38820&action=edit
Minimal testcase.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
The code below (and attached) produces an ICE with gcc (GCC) 7.0.0 20160608
(experimental) when compiled using g++ with "-c -std=
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 36704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36704&action=edit
The code which produces the unexpecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68278
--- Comment #2 from Paul Keir ---
Agreed. I've just tested on 6.0.0 20151110 and there is no ICE.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 36682
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36682&action=edit
C++14 file which produces the i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59991
--- Comment #1 from Paul Keir ---
Created attachment 31988
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31988&action=edit
The output following: g++ -std=c++1y bug.cpp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Created attachment 31987
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31987&action=edit
The test case which produces the i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387
--- Comment #4 from Paul Keir 2013-02-19 12:20:39
UTC ---
Comment on attachment 29492
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29492
Another unexpected error; and also an internal compiler error
>template
>struct is1 {};
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387
--- Comment #3 from Paul Keir 2013-02-19 12:18:17
UTC ---
I've added gcc472aliastemplatebug.cpp which also displays an unexpected error;
shown below along with the code. This is hopefully a related (and simpler)
example. Also, by using the non-t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387
--- Comment #2 from Paul Keir 2013-02-19 12:01:51
UTC ---
Created attachment 29492
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29492
Another unexpected error; and also an internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56387
Bug #: 56387
Summary: Alias of class template wrongly seen as different
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55013
Bug #: 55013
Summary: variadic sizeof non-constant with alias template
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54763
Bug #: 54763
Summary: Crash with enable_if (instead of recursive template
errors)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40205
--- Comment #3 from Paul Keir 2012-09-30 21:29:22
UTC ---
Still present in GFortran 4.7.2 on 32-bit Ubuntu 12.04.1.
53 matches
Mail list logo
