--- Comment #7 from redi at gcc dot gnu dot org 2009-05-05 21:33 ---
Subject: Bug 39909
Author: redi
Date: Tue May 5 21:32:38 2009
New Revision: 147137
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147137
Log:
2009-05-05 Jonathan Wakely
PR libstdc
--- Comment #8 from redi at gcc dot gnu dot org 2009-05-05 21:44 ---
Subject: Bug 39909
Author: redi
Date: Tue May 5 21:44:27 2009
New Revision: 147138
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147138
Log:
2009-05-05 Jonathan Wakely
PR libstdc
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jwakely dot gcc at gmail dot
|dot org
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jwakely dot gcc at gmail dot
|dot org
--- Comment #5 from redi at gcc dot gnu dot org 2009-06-24 07:06 ---
Subject: Bug 40297
Author: redi
Date: Wed Jun 24 07:06:17 2009
New Revision: 148893
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148893
Log:
2009-06-24 Jonathan Wakely
PR libstdc
--- Comment #6 from redi at gcc dot gnu dot org 2009-06-24 07:08 ---
Subject: Bug 40297
Author: redi
Date: Wed Jun 24 07:07:49 2009
New Revision: 148894
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148894
Log:
2009-06-24 Jonathan Wakely
PR libstdc
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-10 15:09 ---
For now, the workaround is to provide some or all of these explicit
instantiations in your program:
namespace std
{
template
basic_ofstream::basic_ofstream(string const&, ios_base::openmode);
temp
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-10 15:36 ---
The code is invalid: The template parameters T and U cannot be deduced in your
partial specialization, because they occur in a non-deduced context.
According to 14.5.4.1 [temp.class.spec.match] paragraph 2 the
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org
|dot org
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-12 09:55 ---
reduced:
struct S
{
int size() const;
};
template
struct Packer
{
int foo() {
return Packer::var.size();
}
const S& var;
};
--
redi at gcc dot gnu dot org changed:
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-13 10:31 ---
(In reply to comment #1)
> It cannot be as it is only undefined behavior and the C++ (and C standard by
> the way) says that
> undefined behavior cannot be an error only a warning.
I don't know about C
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-13 10:59 ---
(In reply to comment #2)
> Well, if the call is on foo then surely a foo can call; its own methods,
Yes, a foo can call its own methods, but a bar can only call them through a bar
object, not on an object with sta
--- Comment #6 from redi at gcc dot gnu dot org 2009-08-13 12:51 ---
(In reply to comment #3)
> I totally agree with David Faure, please make this warning controllable:
> -Werror=invalid-offsetof
>
> All other warnings have a type that can be ignored, but when using the
>
--- Comment #1 from redi at gcc dot gnu dot org 2005-11-09 17:51 ---
We need to doc much more than that ... we don't have any docs saying which TR1
components are supported or how to make use of them, do we?
I had some changes on my hard drive adding docs to the docs/html/ext
--- Comment #3 from redi at gcc dot gnu dot org 2005-11-09 19:49 ---
Created an attachment (id=10194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10194&action=view)
alternative fix
This bug was my fault - sorry for the dumb mistake, and not catching it.
We coul
--- Comment #5 from redi at gcc dot gnu dot org 2005-11-10 21:42 ---
I'm building the compiler now, will test a.s.a.p
--
redi at gcc dot gnu dot org changed:
What|Removed |
: 4.0.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
h
--- Additional Comments From redi at gcc dot gnu dot org 2005-03-25 20:38
---
This can be simplified to:
template void f()
{
T t;
t.f<>(0); //should be t.template f<>(0);
}
If either 'f' is renamed g++ correctly reports an error.
Comeau's onlin
--- Comment #18 from redi at gcc dot gnu dot org 2008-09-04 22:34 ---
Subject: Bug 36962
Author: redi
Date: Thu Sep 4 22:33:10 2008
New Revision: 140012
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140012
Log:
PR libstdc++/36962
* include/Makefile.am
--- Comment #10 from redi at gcc dot gnu dot org 2008-11-05 02:06 ---
Subject: Bug 37351
Author: redi
Date: Wed Nov 5 02:05:59 2008
New Revision: 141596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141596
Log:
PR libstdc++/24803
PR libstdc
--- Comment #11 from redi at gcc dot gnu dot org 2008-11-05 02:06 ---
Subject: Bug 24803
Author: redi
Date: Wed Nov 5 02:05:59 2008
New Revision: 141596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141596
Log:
PR libstdc++/24803
PR libstdc
--- Comment #12 from redi at gcc dot gnu dot org 2008-11-05 02:10 ---
Fixed for 4.4 (including the nits you spotted, thanks Paolo)
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from redi at gcc dot gnu dot org 2008-11-05 02:27 ---
argh! I've broken call_once, re-opening while I look into it. A
testsuite_files was causing some tests not to run.
--
redi at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from redi at gcc dot gnu dot org 2008-11-05 09:37 ---
Subject: Bug 38017
Author: redi
Date: Wed Nov 5 09:36:35 2008
New Revision: 141602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141602
Log:
PR libstdc++/38017
Revert:
*
--- Comment #3 from redi at gcc dot gnu dot org 2008-11-05 09:38 ---
Fixed, sorry for the breakage
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-14 09:51 ---
Do you have a testcase?
I tried this and static_cast behaves the same as the C-style cast:
int i1 = 0.5;
int i2 = (int)0.5;
int i3 = static_cast(0.5);
Only the first line gives a warning.
--
http://gcc.gnu.org
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-14 10:33 ---
Can you extract the tests that were failing and add them to the testsuite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41061
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-14 11:30 ---
I'm seeing this on RHEL5 with the gcc-4.5-20090813 snapshot, GMP 4.3.1 and MPFR
2.4.1
I have /lib/cpp present (from the cpp package) but no system compilers
installed. Instead I have GCC 4.3.4 elsewhere in my
--- Comment #6 from redi at gcc dot gnu dot org 2009-08-14 12:58 ---
I'm configuring with --enable-languages=c,c++ and still don't have a
prev-gcc/g++ (is g++ ever built in stage1?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
--- Comment #8 from redi at gcc dot gnu dot org 2009-08-14 13:13 ---
Thanks, Richard.
If in-tree gmp is going to use --enable-cxx (which it seems to, even though I'm
not building with ppl and cloog-ppl) then should the c++ compiler be built in
stage1 automatically?
Alternat
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-18 19:54 ---
use g++ not gcc
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Invoking-G_002b_002b.html
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-21 09:56 ---
I get the warning with FSF 4.4.1 and the 4.5.0 20090813 snapshot, looks like a
problem with ubuntu's 4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41135
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-21 16:30 ---
I think the docs for 4.4 might be lying, or maybe it's just std::is_pod that
doesn't work correctly.
It works with 4.5, probably since bug 37907 was fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41141
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-21 16:39 ---
Does the C++0x status in the libstdc++ manual also need updating? it says
is_system_layout is missing - I think that should be is_standard_layout, but
it's not missing on trunk now anyway.
--
http://gcc.gn
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-21 16:51 ---
The relevant text in the standard is changing to make it
conditionally-supported, and it's now documented that this isn't supported by
GCC:
http://gcc.gnu.org/onlinedocs/gcc/Conditionally_002dsupported-beh
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-21 17:03 ---
-Werror=int-to-pointer-cast will make one class of warnings into errors, but I
don't think there's a switch to handle the other cases your script detects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41142
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 14:43 ---
IIUC, the top-level const qualifier on "const typename Foo::double3" in the
primary template applies to the type, which is not known during phase 1
At instantiation time, double3 is known to be an arra
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 14:51 ---
(In reply to comment #2)
> IIUC, the top-level const qualifier on "const typename Foo::double3" in the
> primary template applies to the type, which is not known during phase 1
i.e. it's equiva
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-26 15:31 ---
Reduced:
#include
#include
struct GoodE {
GoodE()
{
try {
throw 1;
} catch (...) {
}
}
};
struct BadE {
BadE()
try {
throw 1;
} catch
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 15:52 ---
It looks as though uncaught_exception() does not always become false when
entering the handler of a function-try-block, and this causes it to stay true.
Maybe the count of uncaught exceptions is not decremented in the
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 16:01 ---
(In reply to comment #2)
> at the end of the handler, causing it to be one more than it should not be.
Oops, obviously I meant "one more than it should be"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-26 16:17 ---
(In reply to comment #1)
> Note that GoodE doesn't cause the problem. The difference is that BadE has a
> function-try-block
And, of course, that the exception is rethrown by BadE at the end of the
handle
--- Comment #5 from redi at gcc dot gnu dot org 2009-08-26 16:50 ---
I think the problem is that the uncaught_exception() is true as soon as the
memory for the exception has been allocated, but if the exception's copy
constructor is elided then happens before entering the except
--- Comment #9 from redi at gcc dot gnu dot org 2009-08-26 19:03 ---
Subject: Bug 41005
Author: redi
Date: Wed Aug 26 19:03:24 2009
New Revision: 151126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151126
Log:
2009-08-26 Jonathan Wakely
PR libstdc
--- Comment #10 from redi at gcc dot gnu dot org 2009-08-26 19:04 ---
Subject: Bug 41005
Author: redi
Date: Wed Aug 26 19:04:11 2009
New Revision: 151127
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151127
Log:
2009-08-26 Jonathan Wakely
PR libstdc
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-26 19:40 ---
fails with 4.3.4, I don't have a 4.3 branch to check the tip
pr.cc: In constructor VamsSystemFunction<__GET_DEP__>::VamsSystemFunction()
[with std::set, std::allocator >
(VamsFnct::* __GET_DEP__)()con
--- Comment #11 from redi at gcc dot gnu dot org 2009-08-26 19:15 ---
Fixed for 4.4.2 and 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |libstdc++
Ever
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-27 11:37 ---
(In reply to comment #6)
> Is this related to PR 37477?
It looks like a slightly different issue. PR 37477 relates to when
uncaught_exception() stops being true and fixing it might need to wait for the
resolution
--- Comment #9 from redi at gcc dot gnu dot org 2009-08-27 12:18 ---
(In reply to comment #5)
> I think the problem is that the uncaught_exception() is true as soon as the
> memory for the exception has been allocated, but if the exception's copy
> constructor is elide
--- Comment #11 from redi at gcc dot gnu dot org 2009-08-27 15:19 ---
(In reply to comment #10)
>
> I'm not sure that this applies in this situation. An instance of BadE is
> constructed because it is thrown, but BadE::BadE does not "[exit] via an
> uncaugh
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-28 10:19 ---
(In reply to comment #0)
> #gcc
> cd ../gcc-4.4.1
> ./configure
> --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build
> --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-28 10:23 ---
Changing component, nothing to do with c++ front end
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-28 15:01 ---
it should be --build, not -build
as stated at http://gcc.gnu.org/install/configure.html do NOT build in the
source directory, create a new directory to build in and run $SRCDIR/configure
instead of ./configure
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:16 ---
You didn't say how you configured it.
As with bug 40950, you might need --enable-stage1-languages=c,c++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41234
--- Comment #1 from redi at gcc dot gnu dot org 2009-09-03 11:27 ---
*** This bug has been marked as a duplicate of 40664 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2009-09-03 11:27 ---
*** Bug 41231 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2009-09-03 11:35 ---
Your testcase works for me.
Please see http://gcc.gnu.org/bugs.html for the information you need to
provide, specifically you haven't said how you configured gcc or what command
you're using to compile th
--- Comment #7 from redi at gcc dot gnu dot org 2009-09-08 16:00 ---
(In reply to comment #6)
> Could you please find from you env where is the file conftest.c and how is
> that
> generated?
It's created by the configure script, config.log shows the content of the file,
--- Comment #5 from redi at gcc dot gnu dot org 2009-09-11 09:35 ---
Does the GCC you built for Solaris 10 have symbol versioning enabled? You can
check this by looking in the libstdc++-v3/config.log or by running:
nm /path/to/gcc/lib/libstdc++.so | fgrep @GLIBCXX
If that produces
--- Comment #7 from redi at gcc dot gnu dot org 2009-09-11 15:20 ---
(In reply to comment #6)
> configure:114866: WARNING: === Linker version 1800 is too old for
> configure:114868: WARNING: === full symbol versioning support in this release
> of GCC.
> configure:114
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-05 10:28 ---
Access checking happens after overload resolution.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41575
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-05 10:34 ---
The code should not compile, swapping of rvalues is no longer supported in the
C++0x draft.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41568
--- Comment #14 from redi at gcc dot gnu dot org 2009-10-05 11:30 ---
*** Bug 41333 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from redi at gcc dot gnu dot org 2009-10-05 11:30 ---
(In reply to comment #8)
> I have got the issue. The problem is not sed but rather the pattern being
> searched from ld --version
> My ld --version returns
> GNU ld (GNU Binutils)2.18
>
> Where the
--- Comment #4 from redi at gcc dot gnu dot org 2009-10-05 14:58 ---
14.3.1 [temp.arg.type] paragraph 2 in the current C++ standard says:
A type without linkage (3.5) shall not be used as a template argument for a
template type parameter.
This is changing for C++0x, based on the
--- Comment #5 from redi at gcc dot gnu dot org 2009-10-05 17:59 ---
(In reply to comment #4)
> Could you elaborate? Did you mean a wrong tar for creating a tarball?
No, he said untar.
I just downloaded the file from that mirror and it matches its md5 sum,
extracts without errors,
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-07 08:46 ---
The code is not valid, you need to change the line with the error to:
dbLeft.template detectFileChange<3>();
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from redi at gcc dot gnu dot org 2009-10-07 09:48 ---
(In reply to comment #2)
> Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
> worked, so I thought it would be valid.
You should be wary of using VC++ to determine if code is valid
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-07 16:07 ---
(In reply to comment #1)
> but I am fairly sure I've done the wrong thing to the linker script
> (gnu.ver); I don't really understand the linker script, so it was rather
> monkey-see-monkey-do.
I
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-08 09:42 ---
set::insert never invalidates iterators, so that's not a good example.
set::erase invalidates iterators pointing to erased elements, but debug mode
already catches that.
One problem I see with this request is
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-08 09:43 ---
(In reply to comment #1)
> std::set::iterator i = s.insert(5);
Oops, that should be
std::set::iterator i = s.insert(5).first;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
--- Comment #6 from redi at gcc dot gnu dot org 2009-10-13 11:02 ---
Or see http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41690
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-14 09:10 ---
Slightly reduced:
template
struct TSizeEnabler
{
typedef T TClass;
};
template
int
GetAllSize(const X &Var)
{ return sizeof(Var); }
template
int
GetAllSize(const typename TSizeEnabler::TClass &Var)
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-16 11:42 ---
This looks very similar to bug 41038, but still fails with 4.4.2
N.B. you don't need the friend declaration at all, nested types can access all
members of their enclosing class (this was changed by DR45)
--
--- Comment #4 from redi at gcc dot gnu dot org 2009-10-30 12:14 ---
(In reply to comment #2)
> Isn't ::foo the using'd class from name?
No, see 7.3.1.2 [namespace.memdef]/3 - an unqualified friend declaration refers
to a member of the innermost enclosing namespace. Names
--- Comment #5 from redi at gcc dot gnu dot org 2009-10-30 12:15 ---
(In reply to comment #3)
> I think it is a bug, because the class test is declared at the scope ::
A friend declaration specifies a class that belongs to the innermost enclosing
namespace scope, outer scopes are
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-03 13:32 ---
(In reply to comment #2)
>
> Is there a sane workaround for this?
Don't use 'const' members of unions.
Union members cannot have a non-trivial copy assignment operator.
The assignment ope
--- Comment #5 from redi at gcc dot gnu dot org 2009-11-03 14:21 ---
(In reply to comment #4)
> > I'm not sure whether using A in a union causes the implicitly-declared copy
> > assignment operator to be implicitly defined, but that seems to be what's
> > ha
--- Comment #8 from redi at gcc dot gnu dot org 2009-11-03 18:10 ---
(In reply to comment #6)
>
> The ARM comment (as quoted) is clearly wrong: offhand, I can think of
> two other ways of getting an object initialized. There are probably
> more.
>
> 1. Casting th
--- Comment #9 from redi at gcc dot gnu dot org 2009-11-04 14:41 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#653
and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#683
and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2762
I'm stil
--- Comment #10 from redi at gcc dot gnu dot org 2009-11-04 15:28 ---
To be clear: In C++0x struct A would have a deleted copy assign operator, and
union U would be allowed, but its copy assignment operator would be deleted.
IMHO C++03 is not clear whether struct A has a trivial
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-06 08:38 ---
Subject: Bug 41949
Author: redi
Date: Fri Nov 6 08:38:02 2009
New Revision: 153961
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153961
Log:
2009-11-06 Jonathan Wakely
PR libstdc
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-06 08:48 ---
Fixed for 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-09 12:01 ---
probably related to PR 23885 and/or PR 16635
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-11 11:50 ---
It would certainly be nice to get warnings about members that are not
initialized in the constructor, I don't think GCC currently does that anywhere.
If you add -O then you will get a warning for the use of the m
--- Comment #10 from redi at gcc dot gnu dot org 2009-11-11 14:05 ---
Sorry for the lack of progress, I'll take another crack at it this week and
report back on what I've got and what doesn't work. If I can't finish it I'll
say so and unassign myself
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-12 13:24 ---
It should fail to compile because you are specializing a template which was
never declared, not because it is ambiguous.
namespace {
template<>
void foo(void) { return; }
}
That is a specialization, but th
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-12 13:28 ---
This fails:
template
void foo(void);
template<>
void foo(void);
namespace {
template<>
void foo(void) { return; }
}
int main(int, char **) { foo(); }
ttt.cc:6: error: specialization of 'templa
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-12 17:03 ---
Seems like a reasonable request, it will disable at least the get_deleter()
functionality. I'll work on this when I update shared_ptr to match the latest
WP
--
redi at gcc dot gnu dot org changed:
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-13 10:03 ---
Can you be more specific?
Ordinary unqualified lookup finds ::g and lookup in the associated namespace
finds NS::g, the latter is a better match for the arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-13 10:24 ---
Ah yes, this is DR 239
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#239
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-13 10:59 ---
A::B should have external linkage according to [basic.link] but the definition
of A::B::foo() is a local symbol:
$ nm A.o
t _ZN1A1B3fooEv
U __gxx_personality_v0
--
redi at gcc dot
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-17 10:01 ---
Also, please note that n2960 is not a standard, it's only a draft, and it's not
even the latest draft.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42063
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-18 01:30 ---
Created an attachment (id=19031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19031&action=view)
proposed patch
I'm testing this, with and without -fno-rtti
Without rtti 20_util/sha
--- Comment #4 from redi at gcc dot gnu dot org 2009-11-18 18:47 ---
(In reply to comment #3)
> you tell me when they plan to release a stable version of a C++1x compiler ?
After the C++1x standard is finished, which might be next year, or might not.
I don't know of any compi
--- Additional Comments From redi at gcc dot gnu dot org 2005-08-31 19:27
---
As DR39 has been ruled a defect, this should be re-opened.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13590
--- Additional Comments From redi at gcc dot gnu dot org 2005-08-31 21:04
---
Is this a dup of Bug 14258 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15260
--- Additional Comments From redi at gcc dot gnu dot org 2005-08-31 21:10
---
The resolution of DR460 makes this code illegal and GCC's behaviour correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16468
words: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161
1 - 100 of 688 matches
Mail list logo
