https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91412
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
--- Comment #3 from Tom Honermann ---
A patch for this issue has been submitted:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00150.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
Tom Honermann changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125
--- Comment #5 from Tom Honermann ---
(In reply to Andrew Sutton from comment #3)
> Function concepts have some parsing issues related to TS-style terse
> notation, overloading and variadic templates. In particular, there are
> places where writi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #2 from Tom Honermann ---
I think my preferred fix to this is to introduce new length modifiers for the
"%s" conversion specifier for all of char8_t, char16_t, and char32_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #4 from Tom Honermann ---
(In reply to Florian Weimer from comment #3)
> But the precedent with wchar_t is that the type of the format string
> determines the type of the %s arguments. I'm not sure if that's a good
> precedent, but i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #6 from Tom Honermann ---
(In reply to jos...@codesourcery.com from comment #5)
> We (GCC) don't control printf;
I know, by "we" I meant the C and C++ standards community.
> the format checking should match what the
> actual libc s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
--- Comment #2 from Tom Honermann ---
I confirmed that Jeff's patch, applied to gcc 9.1.0, suffices to address both
Hana's test case and the code in the "Emulate C++17 u8 literals" section of
P1423R2
(http://www.open-std.org/jtc1/sc22/wg21/docs/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70095
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
--- Comment #2 from Tom Honermann ---
(In reply to Tom Honermann from comment #1)
Actually, the test case in comment 1 seems to be a different issue; its failure
is a regression introduced in r234231 via bug 70095.
As of r234231 (and up through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70037
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
--- Comment #3 from Tom Honermann ---
The error in comment 2 was also reported in bug 69364.
oduct: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asut
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an ICE
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code triggers an ICE
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following test case is w
oduct: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc d
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not rejected
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following ill-formed code is not rejected
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following test case is taken from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71141
--- Comment #1 from Tom Honermann ---
If it is decided that this code is well-formed, then I think the declaration of
f7() in t3.cpp should be added to the example in the Concepts TS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
--- Comment #4 from Tom Honermann ---
(In reply to Tom Honermann from comment #3)
> The error in comment 2 was also reported in bug 69364.
I don't know where I got that bug number from. That should have been:
The error in comment 2 was also rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70862
--- Comment #4 from Tom Honermann ---
(In reply to ryan.burn from comment #3)
> It's a different bug. The test case from 70095 compiles fine with the trunk
> from 20160428, but the above example won't.
The example in bug 70095 comment 2 still fa
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following code is ill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221
--- Comment #1 from Tom Honermann ---
(In reply to Tom Honermann from comment #0)
> $ g++ --version
> g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Oops, I ran the above in the wrong terminal session. The correct gcc version
info is:
$ g++ --ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61896
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
--- Comment #6 from Tom Honermann ---
(In reply to Jason Merrill from comment #5)
> PR c++/60095 - partial specialization of variable templates
I believe this was intended to refer to PR c++/70095.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
gcc 6.2/7.0/trunk reports an ICE when checking constraints involving concepts
defined with dependent template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746
Tom Honermann changed:
What|Removed |Added
Blocks||67491
--- Comment #1 from Tom Honermann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147
--- Comment #2 from Tom Honermann ---
The following bug looks likely to be related:
- Bug 80746 - [concepts] ICE evaluating constraints for concepts with dependent
template parameters
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
It appears that an operand
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
It appears that an operand
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
It appears that an operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80748
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80750
--- Comment #1 from Tom Honermann ---
*** Bug 80748 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80750
--- Comment #2 from Tom Honermann ---
*** Bug 80749 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79759
--- Comment #2 from Tom Honermann ---
This looks to be directly related to the following reports:
- Bug 80746 - [concepts] ICE evaluating constraints for concepts with dependent
template parameters
- Bug 67147 - [concepts] ICE on checking concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81139
--- Comment #1 from Tom Honermann ---
Bug 69448 appears to be related.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69448
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1
: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
I built the latest revision of the gcc c++-concepts branch (r221648) last night
and encountered a regression in constraint checking for
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Encountered with the latest revision of the gcc c++-concepts branch (r221681).
Parse errors are issued for function declarations that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
--- Comment #2 from Tom Honermann ---
r221695 does correct the specific test case in comment 0. However, I'm still
seeing similar errors for function declarations that don't specify the return
type with a trailing return type:
$ svn info # Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
--- Comment #5 from Tom Honermann ---
r221733 seems to address the case in comment 2 for me.
I have one more for you. This one is a little different (no return type
involved), so let me know if you want me to open a different bug for it.
$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Encountered with the latest revision of the gcc c++-concepts branch (r221742).
An internal
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Encountered with the latest revision of the gcc c++-concepts branch (r221742).
An internal compiler error occurs when
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Encountered with the latest revision of the gcc c++-concepts branch (r221742).
An internal compiler error occurs when a type
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates what I believe to be a spurious error in
resolving constrained class template partial specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65635
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65635
Tom Honermann changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #3 from Tom Honerma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65634
--- Comment #3 from Tom Honermann ---
Confirmed fixed with r221861. I'll leave the bug open though since comment 2
is requesting additional followup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65636
--- Comment #3 from Tom Honermann ---
Confirmed fixed with r221861. I'll leave the bug open though since comment 2
is requesting additional followup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates high CPU and memory utilization during
compilation when compiled with gcc
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates what I believe to be an error in type
constraint satisfaction involving type aliases. I believe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854
Tom Honermann changed:
What|Removed |Added
Summary|[c++-concepts] Type |[c++-concepts] Type
|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
The following test case was accepted by r211591 of the c++-concepts branch, but
is rejected by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
I believe the following code is intended to be well-formed according to P0121r0
[1]. gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #9
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
I believe the following test case is well-formed, but gcc trunk
,
||asutton at gcc dot gnu.org,
||tom at honermann dot net
--- Comment #2 from Tom Honermann ---
I'm also experiencing this issue and finding it to be rather catastrophic at
present. I'm currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221
--- Comment #3 from Tom Honermann ---
This issue appears to be resolved as of r238202. I can now compile the test
case from comment 0 successfully.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71843
--- Comment #1 from Tom Honermann ---
Created attachment 38876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38876&action=edit
Patch to elucidate failed constraints
The attached patch was provided to me by Andrew Sutton earlier this year
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67565
--- Comment #5 from Tom Honermann ---
Nice, thanks!
Using gcc r238587, I get the times below for the examples in this report. All
cases are dramatically improved. Unless there is some other known issue not
captured in the discussion here, it l
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
A compile-time performance degradation in gcc HEAD (r238592) vs gcc-6-branch
HEAD (r238587) was observed while verifying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71995
Tom Honermann changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277
--- Comment #4 from Tom Honermann ---
We recently got bit by this. It is still an issue in latest gcc trunk:
$ cat t.cpp
enum E : int {
e1 = 1
};
constexpr E operator-(E, E) {
return (E)99;
}
typedef struct {
E e;
E ebf : 16
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
As demonstrated at https://godbolt.org/z/GoTqPTcM3, use of gcc's '#pragma GCC
diagnostic ignored "-Wc++20-com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423
--- Comment #1 from Tom Honermann ---
A patch for this issue was submitted to the gcc-patches mailing list and is
available at https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598736.html.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
As demonstrated at https://godbolt.org/z/7xzWEbqb5, UTF-8 character literals in
preprocessor directives are given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426
--- Comment #1 from Tom Honermann ---
A patch for this issue was submitted to the gcc-patches mailing list with the
patch series available at
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599240.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106426
--- Comment #3 from Tom Honermann ---
I believe this issue can be resolved as fixed via commit
053876cdbe8057210e6f4da4eec2df58f92ccd4c for the gcc 13 release.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423
--- Comment #3 from Tom Honermann ---
I believe this issue can be resolved as fixed via commit
60468d6cd46a3bd3afe8ff856f82afcd4c65a217 for the gcc 13 release.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71136
--- Comment #3 from Tom Honermann ---
(In reply to Andrew Pinski from comment #2)
> Hmm, clang and MSVC also reject the code in comment #1 (the one without the
> bool) for the same reason as GCC.
Interesting. Perhaps this is a common compiler bu
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
As demonstrated by the following test case, GCC emits symbols with external
linkage for explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
--- Comment #4 from Tom Honermann ---
(In reply to Marek Polacek from comment #3)
> Thanks, I can test
Thank you. That change looks right. My apologies for introducing the
regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658
--- Comment #3 from Tom Honermann ---
In retrospect, I think I misunderstood Andrew's motivation for filing this
issue.
There is a difference of behavior between gcc and clang with regard to aliasing
of `char16_t` and `char32_t` with respect to
: normal
Priority: P3
Component: objc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
Target Milestone: ---
GCC's environment variable documentation
(https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html#index-CPAT
96 matches
Mail list logo
