: 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
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=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 re
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=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=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=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=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.
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=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.
: 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=105545
--- Comment #6 from Tom Hughes ---
The reason it only happens with -D_GLIBCXX_ASSERTIONS or in C++20 mode is that
both of those stop the use of the explicit instantiations for basic_string and
cause them to be implicitly instantiated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
--- Comment #5 from Tom Hughes ---
On top of -O1 you seem to need all of -fexpensive-optimizations -ftree-vrp
-fipa-sra to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
--- Comment #4 from Tom Hughes ---
You don't need -D_GLIBCXX_ASSERTIONS in C++20 mode but you do in C++17 mode it
seems.
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 co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54111
Tom de Geus changed:
What|Removed |Added
CC||tom at geus dot me
--- Comment #6 from
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=96031
--- Comment #4 from zhongyunde at tom dot com ---
> As for ivopt, I can see a minor improvement by replacing != exit condition
> with <=, thus saving add 2 instruction computing _22, which happens to
> "disable" the wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
--- Comment #6 from zhongyunde at tom dot com ---
Created attachment 49087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49087&action=edit
adjust the alignment according the attibute
If user don't specify the alignment, so we
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following case, we can easy known the while loop will execute once, but
with newest gcc 10.2, it still generated suboptimal code with condition
expression.
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93102
--- Comment #4 from zhongyunde at tom dot com ---
case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427 generates *.LC0,
but don't emit an aggregate copy a_1 = *.LC0, i.e. it is legal even for
non-const local array.
typedef int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
--- Comment #2 from zhongyunde at tom dot com ---
should the data alignment honor the user specified ?
Now, it seems compiler _do_ align the initializer according align load.
so even if the local array doesn't specify the __attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
--- Comment #6 from zhongyunde at tom dot com ---
Thanks for you notes and I thinks this issue can be closed now.
It doesn't need to handle of non-SMS cases as they'll reschedule in general,
which is good for performance under my test.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the local array a_1 is aligned 64 bytes,
but now gcc only aligned to default 32 bytes for related anchor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #3 from zhongyunde at tom dot com ---
I find there is some different between the two cases during in ivopts.
For the 2nd case, a UINT32 type iv sum is choosed
[local count: 955630224]:
# sum_15 = PHI <0(5), sum_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
--- Comment #3 from zhongyunde at tom dot com ---
(In reply to Richard Biener from comment #2)
> Please send patches to gcc-patc...@gcc.gnu.org
I have send this patch by email according your suggestion, please give me some
advice, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #1 from zhongyunde at tom dot com ---
this may can be enhance by ivopts.
If the case adjusted as following, then the 'and w2, w2, 65535 ' will
disappear.
typedef unsigned int UINT32;
typedef unsigned short UINT16
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, as instruction strh only store the low 16-bits value,
so the 'and w2, w2, 65535 ' is redundant.
test base on the ARM64 gcc 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
zhongyunde at tom dot com changed:
What|Removed |Added
CC||zhongyunde at tom dot com
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
In some target, it is limited to issue two insns with change the same
register.(The insn 73 start with insn:TI, so it will be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
zhongyunde at tom dot com changed:
What|Removed |Added
CC||zhongyunde at tom dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
zhongyunde at tom dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
--- Comment #1 from zhongyunde at tom dot com ---
patch for this issue.
@ linux-9z2e in ~/software/gcc/gcc on git:master o [23:02:26]
$ git diff
diff --git a/gcc/gcse.c b/gcc/gcse.c
index 8b9518e..65982ec 100644
--- a/gcc/gcse.c
+++ b/gcc
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
rtx_insn *
prepare_copy_insn (rtx reg, rtx exp)
{
...
else
{
rtx_insn *insn = emit_insn (gen_rtx_SET (reg, exp));
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
--- Comment #2 from zhongyunde at tom dot com ---
It is a generic issue for all targets, such as x86, it also don't enpand IVOPTs
as index is not used for DEST and Src directly. we may need expand IVOPTs, then
different targets can s
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the variable C05A1 is only used for
the offset of array Dest and Src, and the unit size
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known init the array C16DD is always
consecutive, so we can use the more bigger mode size.
test base on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
Tom de Geus changed:
What|Removed |Added
CC||tom at geus dot me
--- Comment #7 from
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
> pla
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=91130
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment
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=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
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 wh
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
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=88947
--- Comment #7 from Tomalak Geret'kal ---
(In reply to Tim Shen from comment #5)
> For the original test case, have you tried regex_match() with "what.*"?
That behaves as I'd expect
(http://quick-bench.com/AKdMnnhA03T1vwfN9sf53xlbD6s).
> Do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #4 from Tomalak Geret'kal ---
To be honest I'd expect this in less trivial circumstances too. If, at a given
stage of processing, the only possible paths towards a match all require a
prefix that's already been ruled out, that should
IRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
Target Milestone: ---
I first raised this on SO (https://stackoverflow.com/q/54237547/560648), on
which I have posted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802
--- Comment #1 from Tomalak Geret'kal ---
[unord.hash]/2
> Each specialization of hash is either enabled or disabled, as described
> below. [ Note: Enabled specializations meet the Cpp17Hash requirements, and
> disabled specializations do not.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
Target Milestone: ---
See https://stackoverflow.com/q/54147254/560648.
C++17 requires that std::hash be provided. MSVS does, but dev
libstdc++ doesn't (and neither does libc++). This seems to be the case on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525
--- Comment #9 from Tom Ritter ---
This may be related to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53485
https://sourceforge.net/p/mingw-w64/bugs/304/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525
--- Comment #7 from Tom Ritter ---
I'm compiling some AVX code with MinGW+gcc. I'm afraid it's difficult to
create a test case, but I think there's an alignment issue here.
Registers at crash site:
rbp is 0x00 %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525
--- Comment #6 from Tom Ritter ---
Created attachment 44020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44020&action=edit
Disassembly of affected function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525
--- Comment #5 from Tom Ritter ---
./x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=./x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/builds/worker/workspace/build/src/mingw32/bin/../libexec/gcc/x86_64-w64-mingw32/6.4.0/lto-wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525
--- Comment #4 from Tom Ritter ---
Created attachment 44018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44018&action=edit
Preprocessed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525
--- Comment #2 from Tom Ritter ---
(In reply to Andrew Pinski from comment #1)
> What exact target is this on?
Sorry, this is x64 if that's what you mean?
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at ritter dot vg
CC: jacek at codeweavers dot com
Target Milestone: ---
I am using gcc 6.4.0 and MinGW to compile some code that uses AVX intrinsics
for Windows. Specifically, this code:
https
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69448
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1
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=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
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=80748
Tom Honermann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746
Tom Honermann changed:
What|Removed |Added
Blocks||67491
--- Comment #1 from Tom Honermann
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=79197
Tom Hughes changed:
What|Removed |Added
CC||tom at compton dot nu
--- Comment #14 from
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71995
Tom Honermann changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution
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=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
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 th
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=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.
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment
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=61896
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1
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
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
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
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
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
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.
: 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
: 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
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
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
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
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
: 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
1 - 100 of 226 matches
Mail list logo
