introduced in a condition
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http
--- Comment #4 from jwakely dot gcc at gmail dot com 2008-12-02 10:39
---
*** Bug 38345 has been marked as a duplicate of this bug. ***
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #2 from jwakely dot gcc at gmail dot com 2008-12-02 10:39
---
Ah yes, it's a dup. Thanks, Andrew.
*** This bug has been marked as a duplicate of 18770 ***
--
jwakely dot gcc at gmail dot com changed:
What|Removed |
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-01-15 11:44
---
I'm working on adding rvalue support to bind etc. but time is not on my side
recently. I hope to make some more progress this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
edTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
GCC build triplet: ultrasparc3-sun-solaris2.10
GCC host triplet: ultrasparc3-sun-solaris2.10
GCC target triplet: ultrasparc3-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-01-20 15:58
---
should "head -1" also be replaced by "head -n 1" or is that less portable?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-01-20 17:17
---
then
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch02.html#manual.intro.setup.prereq
should be updated to say a POSIX sed is required.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-01-20 17:18
---
oh sorry, Paolo, did you only mean the "head" part? I'm not too concerned
about that bit, it works everywhere I care about, even if POSIX says otherwise
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-01-20 19:07
---
I've just noticed that the libgomp configure says:
configure: versioning on shared library symbols is gnu
even though it seems to have the same sed script as libstdc++, which says:
configure: WA
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-01-21 12:21
---
Not sure what happened yesterday, but I get the same result for both libgomp
and libstdc++ today: both interpret the GNU ld version as 1800
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-05-05 11:34
---
Only fails in trunk. I haven't checked, but could it be caused by the fix for
PR26693 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
--- Comment #18 from jwakely dot gcc at gmail dot com 2009-05-05 13:07
---
I think this fix caused Bug 40007
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-05-05 13:08
---
gcc-4.5-20090327 works, gcc-4.5-20090402 doesn't
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
s: 5.10-1.487
$ uname -a
SunOS xxx 5.10 Generic_127112-03 i86pc i386 i86pc
Is building for i686-pc-solaris2.10 no longer supported, is my linker too old,
or is gcc/configure making incorrect assumptions?
--
Summary: [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-05-05 22:14
---
Fixed for 4.5.0 and 4.4.1
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-05-08 20:52
---
Debugging cc1plus for this slightly reduced program:
template
struct x
{
protected:
typedef int type;
};
template
struct y : public x
{
typename x::type z;
};
template<>
struct y : pu
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-05-11 11:15
---
I can reproduce this on x86_64-unknown-linux-gnu at -O2 with 4.3.2 and
4.5-20090402 snapshot, and at -O3 with 4.2.2
I can't reproduce it with 4.1.2
--
jwakely dot gcc at gmail dot com ch
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-05-11 11:23
---
I was using Boost 1.37.0 with:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20090402/configure
--prefix=/dev/shm/wakelyjo/insroot/4.5-20090402 --enable-languages=c,c
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-05-11 12:42
---
The testcase will have included lots of code from Boost headers conditionally
based on __GNUC__ etc. so it's not surprising it doesn't compile with 4.1 or
4.2
If wanted I can produce an unincluded ver
--- Comment #11 from jwakely dot gcc at gmail dot com 2009-05-11 13:09
---
It does seem to be a regression. I preprocessed the program in comment 4 with
GCC version 4.1.2 20071124 (Red Hat 4.1.2-42), then ran uninclude to produce a
standalone testcase and compiled it with different
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-05-17 14:05
---
(In reply to comment #4)
> I am testing this patch at the moment.
> Could you please test it in your environment and tell me if it helps at all ?
Yes, that patch works for the code I was working on.
--
normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40295
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-05-29 17:08
---
This is independent of std::move
#include
struct S
{
S() : buf(5) { }
int&& get() { return static_cast(buf); }
int buf;
};
int main()
{
S s;
int&& r = s.get();
asse
rity: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-06-02 14:14
---
*** Bug 40295 has been marked as a duplicate of this bug. ***
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-02 14:14
---
*** This bug has been marked as a duplicate of 34022 ***
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-02 14:24
---
I can't change it, but keyword should be diagnostic not link-error, the link
error occurs because the function is not defined, not because GCC generates the
wrong code
--
http://gcc.gnu.org/bug
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-02 15:10
---
seems to be fixed as of gcc version 4.5.0 20090528
pr39050.cc: In function void g():
pr39050.cc:3: error: S::S(const S&) is private
pr39050.cc:11: error: within this context
pr39050.cc:11: e
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-03 09:30
---
(In reply to comment #1)
> I'm under the impression we should simply not provide operator __safe_bool()
Agreed, there is no requirement for conversion to bool, explicit or implicit.
Even if it can
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-06-05 12:48
---
I've got std::bind and friends working with rvalues, but bug 34022 means that
ugly workarounds are needed to work with rvalues of scalar types. When Core DR
664 is ready and bug 34022 is fixed that won
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-10 10:33
---
The code is invalid
MyStream::
MyStream ()
: std::iostream (&m_buf),
m_buf ()
{
}
m_buf has not been cosntructed when you pass it to the base constructor, so
m_buf.init() is called on an uncosntru
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-10 10:42
---
(In reply to comment #4)
>
> You shoudl either pass a null pointer to the base class, then call
> m_buf.init()
Oops, I got that a bit wrong, don't pass a null pointer to the base
constructo
--- Comment #13 from jwakely dot gcc at gmail dot com 2009-06-10 11:45
---
(In reply to comment #12)
> Subject: Bug 26397
>
> Author: dje
> Date: Thu Nov 6 15:32:40 2008
> New Revision: 141646
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&r
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-06-10 13:09
---
(In reply to comment #6)
> According to my copy of ISO 14992:1998, std::iostream does not have a default
> constructor. However, my reading of the standard leads me to believe that it
> is valid to pa
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-15 09:19
---
(In reply to comment #0)
> I can't use "template<> A B::a = something;" form (which would help)
> because I have only empty ctor (like in the case of map).
I'm not sure w
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-15 09:55
---
extern "C" int printf(const char*, ...);
struct A
{
A() : value(1) { printf("A::A %d\n", value); }
int value;
};
template
struct B
{
static A a;
};
template A B
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-15 12:06
---
8.3.5p5? is that reference right?
and I assume you mean line 10, not line 14.
The pair(pair&&) constructor is not in the WP. Commenting it out causes the
pair(pair&&) constructor to be used
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-15 17:19
---
Older versions show the information too:
$ echo | gcc -v -x c -c - 2>&1 | fgrep -B1 GMP
GNU C (GCC) version 4.3.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.3, MPFR
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-16 12:35
---
I think all the assertions are simply backwards, the load() operation requires:
"The order argument shall not be memory_order_release nor
memory_order_acq_rel."
so the assertions
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-16 13:23
---
for the record: http://gcc.gnu.org/ml/gcc/2009-06/msg00173.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-16 15:40
---
(In reply to comment #4)
> Or use --enable-version-specific-runtime-libs .
>
That's been broken for some time on x86_64, see bug 32415
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-18 12:43
---
(In reply to comment #2)
> It seems strange to me that clear() allows memory_order_consume but not
> acquire. I'll ask on the lib reflector if that's an oversight,
I asked and everyone agreed it
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-18 13:11
---
I've already done the library parts on trunk, see
http://gcc.gnu.org/ml/libstdc++/2009-05/msg00114.html
I'll review Doug's patch to see if I missed anything.
N.B. the changes to std::move and st
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-18 13:13
---
Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept
lvalues according to the current draft. That needs fixing too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-18 15:39
---
(In reply to comment #4)
> (In reply to comment #3)
> > Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept
> > lvalues according to the current
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-06-19 15:31
---
I've just noticed this bit of install.texi:
The build process works more smoothly with the legacy Sun tools so, if you
have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend that you place
@file{/us
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-22 11:58
---
That looks good. I didn't run the v3 testsuite, but it fixes the helgrind
errors in the test cases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-22 14:38
---
See http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103
"For associative containers where the value type is the same as the key type,
both iterator and const_iterator are constant iterators.
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-22 14:49
---
bug 14410 and also bug 5583 :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14990
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-22 20:25
---
Created an attachment (id=18049)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18049&action=view)
use BITS_PER_UNIT instead of hardcoded 8
additional patch to use BITS_PER_UNIT for lcas_t_bits
--
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-06-22 20:30
---
the revised patch tests ok, no helgrind errors from
std::string s;
s.erase();
s.erase(s.begin(), s.end());
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-06-23 18:32
---
This seems to be fixed in all open branches (4.3+)
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-06-23 18:40
---
The library pieces of Doug's patch that still need to be applied are:
* include/std/tuple (_Tuple_impl): Use lvalue references when
explicitly specifying the template argument to std:
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-06-24 07:09
---
Fixed for 4.4.1 and 4.5.0
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40595
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-06-30 09:53
---
(In reply to comment #0)
> I'm trying to use SFINAE to disable overloads when a function call expression
> is invalid, which is needed to implement std::bind for C++0x
N.B. the use of an invalid expr
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-30 10:52
---
The basic problem is I've made std::result_of too good ;-)
My new result_of uses decltype to determine the exact result type of an
arbitrary function call, including resolving overloads based on whethe
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-06-30 12:05
---
Is Richard's original issue related to bug 34022?
Bug 40600 is caused by the differences between std::pair in gcc and the current
WP
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40600
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-06-30 12:10
---
Dragan, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054 tracks
the issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
--- Comment #16 from jwakely dot gcc at gmail dot com 2009-07-01 12:18
---
(In reply to comment #9)
>
> In the current draft, reference_wrapper invocation requires Callable, which
> means it should not work for pointers to members. The same is true of
> result_of, which de
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-07-06 17:21
---
(In reply to comment #0)
> // ERROR: How could i use the auto keyword which exist in GCC 4.4
> auto a1 = A (5);
You need to use -std=c++0x to enable C++0x features.
--
http://gcc.gnu.org/bu
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-07-06 17:34
---
See 8.5 [dcl.init] paragraph 12
The initialization that occurs in argument passing, function return, throwing
an exception (15.1), handling an exception (15.3), and brace-enclosed
initializer lists (8.5.1) is
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-07-13 11:48
---
(In reply to comment #0)
>
> What I/we at OOo would like to have is a warning when a when a function in a
> derived class is overloaded without specifing 'virtual'.
To avoid further misunde
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-07-13 16:46
---
(In reply to comment #8)
>
> Ooops... Sorry!
> I just was told that I confused those two terms. >_<
> (That might happen to non-native speakers)
> My apologies!
> Yes you are correct.
--- Comment #11 from jwakely dot gcc at gmail dot com 2009-07-21 10:51
---
There is a lot of overlap between this warning and the functionality described
by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html (which
will be updated by N2928 in a couple of weeks.)
It
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-07-21 17:36
---
(In reply to comment #0)
>
> This is also not conforming to the "specification" in
> http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg01069.html
>
> Warn when a derived class function decla
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-07-21 17:45
---
It tells you the location of the call. If you've specified the template
arguments at that location then you can see what they are, I don't see how
putting them in the diagnostic will save hours if you
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-23 14:06
---
The code is invalid. This is allowed:
template <>
template
class Outer::Inner {};
but not the other way around. The diagnostic is correct to say "enclosing
class templates are not explicitly
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-07-24 10:12
---
(In reply to comment #3)
> Simple case :
>
>
> template struct A {};
> template struct B { struct Inner {}; };
>
> template
> struct A::Inner> {};
>
>
> 4.1.2/VS2005 com
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-07-24 10:29
---
(In reply to comment #4)
> I think this is invalid because K is used in a non-deduced context
Which is the same problem as with the original testcase - this is not a bug in
gcc.
According to 14.5.
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-27 10:11
---
(In reply to comment #0)
> On AIX 5.3, g++ version 4.4.0 and 4.4.1 cannot find the libstdc++ in default
> location. This did not occur with 4.3.x.
> The problem has been already discussed on the mailin
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-28 14:04
---
You didn't say how you configured the build, but you might want to use
something like:
--with-host-libstdcxx='/usr/local/gcc-4.4/lib/libstdc++.a -lm'
as documented at http://gcc.gnu.org/install
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-29 11:01
---
looks similar to bug 40843 but I'm not sure if it's the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40901
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-04 12:35
---
I think you're right that this is a bug, this is a slightly reduced testcase
showing the same error:
template
struct make { static T&& it(); };
void (*pf)(int&) = 0;
template< typename T
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-04 12:48
---
Testcase can be reduced to:
struct S
{
template
S (T const *)
{ }
template
S (char const (&)[N])
{ }
};
int
main()
{
S s1 ("test");
}
GCC still accepts this while Com
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-08-04 17:48
---
(In reply to comment #5)
> Here's a small testcase:
>
> struct B {};
> struct D : B {};
>
> struct S {
> int foo(B* & taskData);
>
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-08-05 10:03
---
This example has four slightly different errors:
struct B {};
struct D : B {};
struct X {};
int foo(B*&);
int i = foo( (B*)0 );
int j = foo( (D*)0 );
D* pd = 0;
int k = foo( pd );
X* px = 0;
int l =
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-05 16:40
---
&c.f isn't even valid, it should be &C::f
I didn't check the code, but that message isn't used for member variables or
nested types, so if it does only apply to member functions then
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-08-06 09:51
---
I don't think any of those tests would be made correct simply by replacing 'f'
with '&f'
Maybe they would have been accepted by GCC 2.95 with the ampersand present, but
current GCC
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-07 12:26
---
The line before the assertion shows the address of the 'Bar' subobject, which
is not the same value as previously given for that subobject (on the 2nd and
5th lines of output.)
Like the reporter, I ex
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-07 12:31
---
Adding this to Bart::InnerBart::getOuter():
cout << "BaseIf1: " << (BaseIf*)&outer << endl;
and this to Bar::InnerBar::getVal():
cout << "B
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-07 12:42
---
Ah, [class.virtual] paragraph 5 says:
If the return type of D::f differs from the return type of B::f, the class type
in the return type of D::f shall be complete at the point of declaration of
D::f or shall be
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-07 12:47
---
Moving the definition of InnerBart outside the body of Bart (which requires
making Bart::createInner non-covariant) allows the assertion to pass, the
addresses are all correct. So I believe this program is
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-08-07 12:59
---
(In reply to comment #4)
> Ah, [class.virtual] paragraph 5 says:
> If the return type of D::f differs from the return type of B::f, the class
> type
> in the return type of D::f shall be complete at
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 10:40
---
Apart from the semi-colon after the extern "C" block the code is valid and this
is a recent regression on trunk.
--
jwakely dot gcc at gmail dot com changed:
What
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 11:34
---
(In reply to comment #0)
> To my mind statement
> test.cpp: In constructor 'testclass::testclass()':
> test.cpp:4: error: class 'testclass' does not have any field named &#
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-10 11:35
---
(In reply to comment #2)
> Note that if you put the declaration of 'int number;' first then Comeau has a
> very similar error to GCC's when the member function is first - it complains
>
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-10 12:26
---
Does libstdc++-v3/src/fstream-inst.cc get compiled in C++0x mode? If not, then
the C++0x-only symbols would not be instantiated in the library
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 13:17
---
Since the C++0x changes to fstream are only additions, the simplest solution is
probably to compile src/fstream-inst.cc in c++0x mode, which just means adding
new targets to src/Makefile.am so that -std=gnu++0x
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-10 14:44
---
(In reply to comment #4)
> Those are seperate errors of course. I've meant that when compiler already
> discovered that there is a conflict between number and number() it looks like
> it's
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-10 17:05
---
It's irrelevant to this bug and is just me being more pedantic than -pedantic,
however ... even with -pedantic GCC has always accepted stray semi-colons at
namespace scope, but it's not valid.
At func
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-10 19:39
---
The definitions are in that header, but the 'extern template' extension is used
to prevent the compiler from instantiating the code in your program, see
http://gcc.gnu.org/onlinedocs/gc
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-08-10 20:05
---
(In reply to comment #5)
> Instead of instantiating that code in every object a single explicit
> instantiation is provided in libstdc++.so, that's the purpose of
> src/fstream-inst.cc
... but i
--- Comment #12 from jwakely dot gcc at gmail dot com 2009-08-11 14:16
---
revised 'Explicit Virtual Function Overrides' paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-08-11 14:24
---
as with bug 31937, there is overlap between this enhancement and the 'Explicit
Virtual Function Overrides' paper,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm
the attributes p
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-08-11 23:02
---
This patch (and running autoreconf) fixes the problem, but I'm still trying to
work out the right changes to the linker script so that the new symbols are
versioned as GLIBCXX_3.4.13 not GLIBCXX_3.4
Index
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-08-12 08:55
---
Created an attachment (id=18344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18344&action=view)
compile fstream-inst.cc as c++0x to instantiate new members
i'm testing this patch
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-12 09:41
---
I think maybe the second example is rejected because of 2) not 3)
2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the
completed scope of S. No diagnostic
1 - 100 of 231 matches
Mail list logo
