This is a multi-part message in MIME format.
Norman Virus Control a supprimé le message original qui contenait le virus
[EMAIL PROTECTED]
|4 |8 (sys/types.h)
---
long double | 12 |16
Thank in advance,
Tom
--
View this message in context:
http://www.nabble.com/Size-of-C-C%2B%2B-data-type-from-GNU-GCC-g%2B%2B-compiled-ELF-64-bit-LSB-executable%2C-AMD-x86-64-vs.-EL
s doesn't happen, because we create non-joinable
threads. In fact if we tried to join them, pthread_join would just
return an error (unless Linux egregiously violates POSIX or X/OPEN
here).
Wolfgang> Unfortunately, I can't find the place where you actually
Wolfgang> create a new thread right away...
_Jv_ThreadStart in libjava/posix-threads.cc.
Tom
c not
found
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom at tiri dot li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25384
--- Comment #2 from tom at tiri dot li 2005-12-16 15:54 ---
Yes, without binutils it is working.
I set following ulimits to make it compile:
ulimit -c unlimited
ulimit -d unlimited
ulimit -f unlimited
ulimit -m unlimited
ulimit -s 131072
But one open question:
I CAN COMPILE binutils
3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom at atoptech dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
--- Comment #2 from tom at atoptech dot com 2009-02-12 18:10 ---
Subject: Re: -Wconversion useless
You miss the point. The only way to assign a non-constant value to a bit
field outside of a struct is using an integral variable i.e.,
struct foo
{
int a : 2;
};
void assign
--- Comment #4 from tom at atoptech dot com 2009-03-10 17:40 ---
Manuel,
You miss understood what I meant by "old behavior was just fine". I was saying
that the previous behavior of "gcc" worked fine and I was NOT referring
specifically to the "-Wconversio
--- Comment #6 from tom at atoptech dot com 2009-03-10 20:34 ---
Subject: Re: cannot silence -Wconversion warnings for
bit-fields
> AFAIK, that is not true. I just tried your very example with gcc 4.2.4 and it
> doesn't warn with -Wall -Wextra -Wconversion. g++ d
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
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
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: 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=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
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=95267
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=95696
zhongyunde at tom dot com changed:
What|Removed |Added
CC||zhongyunde at tom dot com
: 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=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
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 #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_
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=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.
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=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
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=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
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=91412
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #1
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
--- Comment #4 from tom at kera dot name 2009-08-25 14:48 ---
(In reply to comment #2)
> Why would this be ambiguous? A string literal has type "array of n const char"
> (see 2.13.4/1), so it should go with the array constructor. Do you disagree?
>
> W.
>
Tab
at arm is natively little-endian, and thus there may be a reason to
always default it to little-endian in certain cases) please disregard this
message and close this bug report. Thanks.
Regards,
Tom
--
Summary: big-endian arm MULTILIB_DEFAULTS hard-coded to little-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935
Tom de Vries changed:
What|Removed |Added
CC||tom at codesourcery dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14799
Tom de Vries changed:
What|Removed |Added
CC||tom at codesourcery dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935
--- Comment #6 from Tom de Vries 2011-01-14
15:48:03 UTC ---
Related bug: PR 14799.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304
Bug #: 50304
Summary: poor code for accessing certain element of arrays
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304
--- Comment #2 from Tamas Fenyvesi 2011-09-08
13:14:44 UTC ---
Created attachment 25225
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25225
some testcases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304
--- Comment #3 from Tamas Fenyvesi 2011-09-08
13:16:20 UTC ---
Created attachment 25226
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25226
-O1..-O3 compiled objdumped result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50304
--- Comment #4 from Tamas Fenyvesi 2011-09-08
13:16:53 UTC ---
Please find a sample code and its objdump-ed asm in the attachment.
The command line is:
arm-none-eabi-gcc -D__REDLIB__ -DDEBUG -D__USE_CMSIS -D__CODE_RED -I"../cmsis"
-I"../config"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169
--- Comment #2 from Tomalak Geret'kal 2012-02-08
10:45:17 UTC ---
Are you sure it's not just that in_avail is 0? Why should it be -1 here?
i.e. doesn't readsome become a noop when there's nothing to read?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
++
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=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.
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=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
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
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
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?
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 #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 #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 #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 #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=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
> pla
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
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=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
--- Comment #12 from Tom Geocaris 2013-01-04 17:32:22
UTC ---
Is there any resolution to this issue? We need to move to a more recent version
of gcc, but are still stuck at gcc 4.2.4.
I looked at gcc 4.7.2 but behavior is the same and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #11 from Tom Hughes ---
This is C++ so -fexcess-precision=standard is no help as that is C only.
Likewise -ffloat-store is, as I understand it, not much help in real world code
because you need to make sure that you force stores in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #14 from Tom Hughes ---
Yes upstream took my fix to avoid the equality
(https://github.com/mapnik/node-mapnik/pull/589) but have also now noticed that
most of the FP can be one away with completely.
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
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
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
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
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
1 - 100 of 227 matches
Mail list logo
