++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
Created attachment 55673
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55673&action=edit
demo program
A postconditon declared on a coroutine should be evaluated w
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
Created attachment 55672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55672&action=edit
Sample program illustrating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #16 from Andrzej Krzemienski ---
Oh, I see. The above requirement applies only to chapter Algorithms library.
Not Iterators library. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #15 from Andrzej Krzemienski ---
How come?
[algorithms.requirements], paragraph 4, bullet 5
(http://eel.is/c++draft/algorithms#requirements-4.5) says:
If an algorithm's template parameter is named BidirectionalIterator,
Bidirectiona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95607
--- Comment #1 from Andrzej Krzemienski ---
Note that the behavior of GCC cannot be called non conformant with the C++
Standard, as the Standard is very unclear: it does not define the term
"immediate context", but later refers to it.
The proble
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
Consider the following three declarations in exactly this order:
```
template int f(T, T = "") ;
int f(...) ;
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
The following program should fail to compile in C++20 because the type of the
predicate in requires-clause is not bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595
--- Comment #3 from Andrzej Krzemienski ---
The part of the Standard that requires this:
http://eel.is/c++draft/temp.explicit#11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595
Andrzej Krzemienski changed:
What|Removed |Added
Version|6.1.0 |10.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #10 from Andrzej Krzemienski ---
For `std::prev()` it is UB, but by my reading of UB
(http://eel.is/c++draft/intro.defs#defns.undefined) it is legal for the
implementation to respond with "terminating a translation" "with the issuance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #25 from Andrzej Krzemienski ---
(In reply to Allan Jensen from comment #24)
> So with this the rule-of-three is now the rule-of-four or six?
The Rule of Zero: https://blog.rmf.io/cxx11/rule-of-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85069
--- Comment #3 from Andrzej Krzemienski ---
You're correct. It is my bad. Sorry, I assumed they both had identical
interface. This ticket can be closed.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
`std::invoke_result` returns a wrong type. Consider the following source file:
```
#include
// log_type displays the type of T in compiler error
template void log_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
--- Comment #7 from Andrzej Krzemienski ---
This still reproduces in version 7.2. Here is a Wandbox link:
https://wandbox.org/permlink/5uCAr5u0xpynljhQ
Here is the code, you need to compile it with -DNDEBUG -O2:
```
#include
class O
{
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrzej Krzemienski changed:
What|Removed |Added
CC||akrzemi1 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139
--- Comment #5 from Andrzej Krzemienski ---
What does this mean that the status of this bug report is "NEW"? It is 2 years
old. In GCC Bugzilla one can assign status "CONFIRMED" to bug reports. Why is
this one not confirmed? Was nobody able to co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80664
--- Comment #5 from Andrzej Krzemienski ---
Thank you for pointing this out. Can anything be done to fix this PR 66139? It
has status "NEW" but is in fact quite old. In the comments above, you have
provided some substantial analysis of the source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80664
--- Comment #1 from Andrzej Krzemienski ---
This happens on all C++11 GCC versions.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
The following program logs calls to successful constructors and destructors of
class `R`. I expect the number of constructions to equal the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #4 from Andrzej Krzemienski ---
Just to clarify, what I request for this "unconditional" check is not the
existence of all operators, but only the check for the iterator_tag (we expect
a bidirectional iterator).
That is, the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #2 from Andrzej Krzemienski ---
Sorry, you are correct. As per [res.on.functions], passing types that do not
satisfy the requirements is a UB, and therefore a well formed program. GCC is
standard-compliant in this respect.
So, I have
++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
The following code compiles, even though according to the C++ Standard it is
ill-formed.
```
#include
#include
int main()
{
std::forward_list il = {1, 2, 3, 4, 5, 6, 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78058
--- Comment #1 from Andrzej Krzemienski ---
Fore some background, the bug is caused by GCC correctly implementing p0032r2.
Technically GCC is compliant with N4604, however the tags as specified in 20.2
are buggy, as can be seen in the initial exa
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
The following program fails to compile:
```
#include
#include
using std::optional;
using std::nullopt;
using std::in_place;
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
Andrzej Krzemienski changed:
What|Removed |Added
CC||akrzemi1 at gmail dot com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
PROBLEM DESCRIPTION:
It is a known C++ gotcha: you declare a one-argument non-explicit constructor,
even though you never intend it to participate in any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595
--- Comment #1 from Andrzej Krzemienski ---
I mean, the expectation is that member functions whose constraints are not
satisfied should be omitted during explicit class template instantiation.
See this discussion for more background:
https://gro
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
The following correct program, compiled with -fconcepts, gives compilation
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
An example in the Standard shows that template deduction should fail upon
narrowing conversion from template argument. [temp.deduct] para 9:
```
template int f(int
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
Target Milestone: ---
My class has a perfect-forwarding non-explicit constructor. I expect that when
it binds to a constant lvalue of type int, it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #10 from Andrzej Krzemienski ---
I guess, by now "item 11" should read "either delete or define ..."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #7 from Andrzej Krzemienski ---
Just one remark. A warning in this situation is not to just warn about any
deprecated feature, but to indicate something that is very likely to be a bug
(It used to be legal in C++03, so you couldn't leg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #6 from Andrzej Krzemienski ---
(In reply to Andrzej Krzemienski from comment #2)
> No. Other compilers (Clang and VS 2010) do not emit such warning either.
Correction: The newest version of Clang does give a warning:
"definition of i
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akrzemi1 at gmail dot com
The following program is correct in C++11, but uses a deprecated language
feature. According section D.3, paragraph 1:
"The imp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407
--- Comment #2 from Andrzej Krzemienski ---
No. Other compilers (Clang and VS 2010) do not emit such warning either.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55537
--- Comment #1 from Andrzej Krzemienski 2012-11-29
21:19:10 UTC ---
Even a slightly simpler example crashes:
BEGIN
constexpr int j = 0;
constexpr int const& get() {
return (0, j);
}
constexpr int i = get();
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55537
Bug #: 55537
Summary: constexpr usage crashes the compiler
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55432
Bug #: 55432
Summary: Too much constexpr makes the compiler crash
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53302
Bug #: 53302
Summary: a combination of union, perfect forwarding and
template parameter pack causes a seg-fault in program
Classification: Unclassified
Product: gcc
Version: 4.6.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51738
Bug #: 51738
Summary: C++11 initializer list does not work correctly with
operator[]
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
--- Comment #3 from Andrzej Krzemienski 2011-08-08
23:31:37 UTC ---
(In reply to comment #1)
> G++ is actually correct according to wording in the C++11 FDIS (see 8.5.4
> paragraphs 5 and 6), but we've reported it as an issue that needs to be fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
Summary: C++0x initialization syntax doesn't work for class
members of reference type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48993
Summary: segmentation fault when compiling this program with
constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
43 matches
Mail list logo
