--- Comment #2 from gcc at magfr dot user dot lysator dot liu dot se
2010-09-22 15:58 ---
*** Bug 45747 has been marked as a duplicate of this bug. ***
--
gcc at magfr dot user dot lysator dot liu dot se changed:
What|Removed |Added
--- Comment #3 from gcc at magfr dot user dot lysator dot liu dot se
2010-09-22 15:58 ---
I agree.
*** This bug has been marked as a duplicate of 45625 ***
--
gcc at magfr dot user dot lysator dot liu dot se changed:
What|Removed |Added
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2010-09-22 15:19 ---
Created an attachment (id=21861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21861&action=view)
Test case showing the bug
Compile with
g++ enums-and-template-params.cpp
to trig
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
GCC host triplet: i686-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45747
--- Comment #4 from gcc at magfr dot user dot lysator dot liu dot se
2010-05-29 08:17 ---
I have run head-first into this problem as well.
I have found that _ZN1tcvT_IiEEv ( t::operator int() ) works but
_ZN1tcvKT_IiEEv ( t::operator int const() ) fails so it seems the problem
is that
--- Comment #3 from gcc at magfr dot user dot lysator dot liu dot se
2010-02-01 17:19 ---
I think the code is valid.
The unique_ptr(nullptr_t) constructor should take the 0 and build an empty
unique_ptr object that is compared with ptr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2010-02-01 16:47 ---
Created an attachment (id=19774)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19774&action=view)
Test case demonstrating the problem.
compile with
g++ -std=c++0x -c test.
4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
turn the length of the
decoded name
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2009-11-21 12:24 ---
Created an attachment (id=19074)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19074&action=view)
Test case - g++ -Wignored-qualifiers test.C gives confusing results
In C++ it becom
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2009-05-03 22:05 ---
Created an attachment (id=17794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17794&action=view)
Test case demonstrating the problem.
--
http://gcc.gnu.org/bugzilla/show_bug
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
--- Comment #2 from gcc at magfr dot user dot lysator dot liu dot se
2008-04-14 06:34 ---
I think I was wrong.
--
gcc at magfr dot user dot lysator dot liu dot se changed:
What|Removed |Added
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2008-04-14 05:24 ---
Created an attachment (id=15475)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15475&action=view)
Testcase for the error message
Repeat by compiling as
g++ -c pmv.C
--
FIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
GCC build triplet: i586-pc-linux-gnu
GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-
rsion: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
GCC build triplet: i586-pc-linux-gnu
GCC host triplet: i5
--- Comment #28 from gcc at magfr dot user dot lysator dot liu dot se
2007-11-03 07:47 ---
That both files are named S1.C doesn't matter.
If one do
cp S1.C S2.C
g++ -c S1.C
g++ -c S2.C
g++ S1.o S2.o
one get the same behaviour and the same linker error.
--
http://gcc.gn
--- Comment #15 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-30 16:53 ---
I agree that the linker should not drop the typeinfo when it is needed.
I could just tell that I see the problem on Linux so it isn't Darwin-specific.
> > Should the typeinfo for a
--- Comment #13 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-29 18:52 ---
Should the typeinfo for an anonymous namespace class be local if it inherits
from a class that is outside the anonymous namespace?
If that is the case, what should typeid(reference to base of
--- Comment #5 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-29 00:04 ---
Created an attachment (id=14430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14430&action=view)
Testcase demonstrating the problem
To reproduce, compile using
g++ S1.C S1.C
Yes
--- Comment #16 from gcc at magfr dot user dot lysator dot liu dot se
2007-04-17 07:18 ---
Created an attachment (id=13375)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13375&action=view)
Test showing that the current fix causes an ICE
--
http://gcc.gnu.org/b
--- Comment #15 from gcc at magfr dot user dot lysator dot liu dot se
2007-04-17 07:15 ---
I think there are still some kind of problem.
If I try to compile bar.C using g++ -c bar.C then where g++ is g++ (GCC) 4.3.0
20070416 (experimental) (Hm, I'd wish for a revision number in
--- Comment #4 from gcc at magfr dot user dot lysator dot liu dot se
2006-10-06 18:48 ---
I still fail to understand why this would inherently violate the ODR.
I agree with Andrew that if more than one translation unit sees the defintion
of foo::bar then it will violate the ODR but if
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2006-10-06 06:09 ---
Created an attachment (id=12389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12389&action=view)
foo.C - testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
nnecessary anonymous namespace warnings
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator
--- Comment #6 from gcc at magfr dot user dot lysator dot liu dot se
2006-04-06 12:52 ---
(In reply to comment #5)
> "gcc at magfr dot user dot lysator dot liu dot se" <[EMAIL PROTECTED]>
> writes:
>
> | The standard says the limit have to be more than 1
--- Comment #4 from gcc at magfr dot user dot lysator dot liu dot se
2006-04-06 12:08 ---
The standard says the limit have to be more than 17, the g++ default is 500 in
order, I assume, to be nice to users.
The reason I reported the bug was that the compiler terminated with an
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2006-04-05 21:14 ---
Created an attachment (id=11214)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11214&action=view)
Recursive template for error triggering
--
http://gcc.gnu.org/bugzilla/show_bug
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2006-04-04 08:36 ---
Created an attachment (id=11198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11198&action=view)
Testcase - program.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
ht
--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot
se 2005-04-29 21:15 ---
Created an attachment (id=8767)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8767&action=view)
Example program demonstrating the problem
Compile with g++ -Wall -O1 -c foo.C
arning on legal code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot
se 2005-02-25 14:55 ---
(In reply to comment #3)
> Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01489.html>
This fixes the obvious case but it also makes the following pass with no
warnings
--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot
se 2005-02-23 18:15 ---
Created an attachment (id=8267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8267&action=view)
Program demonstrating the bug
Compile with
g++ -Wmissing-braces -c fo
members
with "strings"
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr do
--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot
se 2004-11-25 08:27 ---
Created an attachment (id=7606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7606&action=view)
Program that generates the bug
--
http://gcc.gnu.org/bugzilla/show_bug
t gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18672
38 matches
Mail list logo
