[Bug c++/38345] New: redeclaration of name introduced in a condition
The example in 6.4p3 is not diagnosed by GCC:
if (int x = f()) {
int x; // ill-formed, redeclaration of x
}
else {
int x; // ill-formed, redeclaration of x
}
This compiles without warnings on every version of GCC I tried from 3.3 to 4.3
--
Summary: redeclaration of name 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=38345
[Bug c++/18770] g++ accepts invalid code with scopes on ifs
--- 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 CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18770
[Bug c++/38345] redeclaration of name introduced in a condition
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38345
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- 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
[Bug libstdc++/38923] New: symbol versioning disabled due to non-portable sed script
libstdc++-v3/configure contains this:
ldver=`$LD --version 2>/dev/null | head -1 | \
sed -e 's/GNU \(go\)\{0,1\}ld \(version \)\{0,1\}\(([^)]*)
\)\{0,1\}\([0-9.][0-9.]*\).*/\4/'`
that sed script fails with /usr/bin/sed on Solaris, disabling symbol
versioning.
Here's an example of what I get:
++ /sbcimp/run/pd/binutils/32-bit/2.18/bin/ld --version
++ head -1
++ sed -e 's/GNU ld \(version \)\{0,1\}\(([^)]*)
\)\{0,1\}\([0-9.][0-9.]*\).*/\3/'
+ ldver='GNU ld (GNU Binutils) 2.18'
++ echo GNU ld '(GNU' 'Binutils)' 2.18
++ nawk -F. '{ if (NF<3) $3=0; print ($1*100+$2)*100+$3 }'
+ glibcxx_gnu_ld_version=1800
This leads to:
configure: WARNING: === Linker version 1800 is too old for
configure: WARNING: === full symbol versioning support in this release of GCC.
configure: WARNING: === You would need to upgrade your binutils to version
configure: WARNING: === 21400 or later and rebuild GCC.
configure: WARNING: === Symbol versioning will be disabled.
configure: versioning on shared library symbols is no
Could be fixed by requiring a POSIX sed, or by using awk to select the version
(we already require POSIX awk)
--
Summary: symbol versioning disabled due to non-portable sed
script
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: 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
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
--- 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
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
--- 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
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
--- 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
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
--- 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: WARNING: === Linker version 1800 is too old for configure: WARNING: === full symbol versioning support in this release of GCC. configure: WARNING: === You would need to upgrade your binutils to version configure: WARNING: === 21400 or later and rebuild GCC. configure: WARNING: === Symbol versioning will be disabled. configure: versioning on shared library symbols is no I can't do aanother test until tomorrow now, but I'll try to verify if libgomp really does get it right, and if so, how. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
--- 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
[Bug c++/40007] specialization causes access problem in primary template
--- 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
[Bug c++/26693] [4.3/4.4/4.5 regression] Access checks not performed for types in templates
--- 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 CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
[Bug c++/40007] specialization causes access problem in primary template
--- 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
[Bug bootstrap/40027] New: [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
=FUNC; file
/var/tmp/build-gcc/gcc/./gcc/crtend.o type=FUNC);
ld: fatal: File processing errors. No output written to ./libgcc_s.so.1.tmp
collect2: ld returned 1 exit status
make[3]: *** [libgcc_s.so] Error 1
make[3]: Leaving directory `/var/tmp/build-gcc/gcc/i686-pc-solaris2.10/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/var/tmp/build-gcc/gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/var/tmp/build-gcc/gcc'
make: *** [all] Error 2
The problem seems to be that gcc/configure in 4.4.0 was changed to
unconditionally set gcc_cv_ld_hidden=yes for Solaris targets:
*-*-solaris2.9* | *-*-solaris2.1[0-9]*)
gcc_cv_ld_hidden=yes
;;
$ grep gcc_cv_.._hidden gcc/config.log
gcc_cv_as_hidden=yes
gcc_cv_ld_hidden=yes
Judging by the failure, this doesn't seem to be correct.
A similar configuration using --build=i686-pc-solaris2.10 with 4.3.2
successfully bootstraps, because gcc/configure sets gcc_cv_ld_hidden=no
$ /usr/ccs/bin/ld -V
ld: Software Generation Utilities - Solaris Link Editors: 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
using Sun ld
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
GCC build triplet: i686-pc-solaris2.10
GCC host triplet: i686-pc-solaris2.10
GCC target triplet: i686-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
--- 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 : public x
{
typedef x::type z;
};
template class y;
shows the explicit instantiation of y calls
perform_typedefs_access_check() which calls
enforce_access() with decl = x::type.
That's wrong, it should be x::type - somehow the wrong typedef is
added to the list of types to check for the y specialisation.
(gdb) bt
#0 enforce_access (basetype_path=0x2b643180, decl=0x2b641cc0,
diag_decl=0x2b641cc0) at ../../src/gcc/gcc/cp/call.c:4447
#1 0x004acabc in perform_typedefs_access_check (
tmpl=, targs=0x2b6429c0)
at ../../src/gcc/gcc/cp/pt.c:6960
#2 0x004b827b in instantiate_class_template (type=0x2b644240)
at ../../src/gcc/gcc/cp/pt.c:7443
#3 0x004edf00 in complete_type (type=0x2b644240)
at ../../src/gcc/gcc/cp/typeck.c:130
#4 0x004b062c in do_type_instantiation (t=0x2b644240,
storage=0x0, complain=1) at ../../src/gcc/gcc/cp/pt.c:15011
#5 0x004e0f11 in cp_parser_explicit_instantiation (
parser=0x2b4b59b0) at ../../src/gcc/gcc/cp/parser.c:10812
#6 0x004e6905 in cp_parser_declaration (parser=0x2b4b59b0)
at ../../src/gcc/gcc/cp/parser.c:8013
#7 0x004e6caa in cp_parser_declaration_seq_opt (parser=0x2b4b59b0)
at ../../src/gcc/gcc/cp/parser.c:7927
#8 0x004e7527 in c_parse_file () at ../../src/gcc/gcc/cp/parser.c:3029
#9 0x005557fa in c_common_parse_file (
set_yydebug=) at ../../src/gcc/gcc/c-opts.c:1272
#10 0x007519e2 in toplev_main (argc=13, argv=0x7fffe8a8)
at ../../src/gcc/gcc/toplev.c:979
#11 0x2ace24ca in __libc_start_main () from /lib/libc.so.6
#12 0x0048216a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) n
4448 gcc_assert (TREE_CODE (basetype_path) == TREE_BINFO);
(gdb)
4450 if (!accessible_p (basetype_path, decl, true))
(gdb)
4452 if (TREE_PRIVATE (decl))
(gdb)
4454 else if (TREE_PROTECTED (decl))
(gdb)
4455error ("%q+#D is protected", diag_decl);
(gdb)
pr40007.cc: In instantiation of y:
pr40007.cc:20: instantiated from here
pr40007.cc:5: error: typedef int x::type is protected
4458 error ("within this context");
(gdb)
pr40007.cc:10: error: within this context
4463}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2
--- 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 changed: What|Removed |Added CC||jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2
--- 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++ --disable-bootstrap --disable-checking --with-gmp=/dev/shm/wakelyjo/stage --with-mpfr=/dev/shm/wakelyjo/stage Thread model: posix gcc version 4.5.0 20090402 (experimental) (GCC) and Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.2/configure --prefix=/opt/gcc/32-bit/4.3.2 --enable-languages=c,c++,fortran,objc,obj-c++ --with-gnu-as --with-as=/opt/binutils/32-bit/2.18/bin/as --with-gnu-ld --with-ld=/opt/binutils/32-bit/2.18/bin/ld --with-gmp=/var/tmp/stage --with-mpfr=/var/tmp/stage --build=i686-pc-linux-gnu --with-arch=pentium4 --enable-shared --enable-threads=posix --enable-nls --enable-libstdcxx-debug --enable-__cxa_atexit Thread model: posix gcc version 4.3.2 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2
--- 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 version using 4.1 and 4.2, but I assume there's no point as those branches are closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2
--- 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 versions of GCC GCC 4.1.1 (FSF) at -O3 doesn't call the pure virtual. GCC 4.1.2 (Red Hat) at -O3 doesn't call the pure virtual. GCC 4.2.2 (FSF) at -O3 calls the pure virtual. GCC 4.3.2 (FSF) can't compile the program (again, due to Boost's heavy use of preprocessor checks) Do you want that unincluded testcase attached? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug libstdc++/40295] New: [C++0x] std::move and builtin types
I'm not sure what's going on here, but with a recent 4.5 snapshot this program
fails:
#include
#include
template
struct S
{
S() : buf() { }
void set(T&& i) { buf = std::move(i); }
T&& get() { return std::move(buf); }
private:
T buf;
};
struct pod { };
template class S;
template class S;
template class S;
int main()
{
S s;
s.set(5);
assert( s.get() == 5 );
}
Compiling with 4.5.0 20090528 gives these warnings:
tmpret.cc: In member function T&& S::get() [with T = int]:
tmpret.cc:19: instantiated from here
tmpret.cc:11: warning: returning reference to temporary
tmpret.cc: In member function T&& S::get() [with T = double]:
tmpret.cc:20: instantiated from here
tmpret.cc:11: warning: returning reference to temporary
tmpret.cc: In function int main():
tmpret.cc:27: warning: is used uninitialized in this function
And the assertion fails at runtime.
Notice that the explicit instantiations of S and S trigger the
warning about returning a reference to a temporary for this line:
T&& get() { return std::move(buf); }
but the S instantiation doesn't. I can't see what's wrong with that line,
it seems that std::move creates a temporary when 'T' is a builtin type.
It looks as though std::move(buf) instantiates std::move(T&&) with T = int&,
so the rvalue-reference binds to an int& not an int.
Am I missing something or is this a bug in either std::move or g++?
N.B. the changes to std::move proposed by n2844 are not in the WP yet, so the
specification of std::move may change.
--
Summary: [C++0x] std::move and builtin types
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: 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
[Bug c++/40295] [C++0x] rvalue-references and builtin types
--- 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();
assert( &r == &s.buf );
}
tmpret.cc: In member function int&& S::get():
tmpret.cc:7: warning: returning reference to temporary
tmpret: tmpret.cc:16: int main(): Assertion `&r == &s.buf' failed.
Looks like the cast to int&& creates a temporary, which is bound to the
returned reference, triggering the warning. According to 8.5.3 [dcl.init.ref]
paragraph 5, the reference should be bound to the object, not to a temporary.
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
Component|libstdc++ |c++
Keywords||wrong-code
Summary|[C++0x] std::move and |[C++0x] rvalue-references
|builtin types |and builtin types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40295
[Bug libstdc++/40296] New: [C++0x] std::exception_ptr comparisons
[propagation]/5 says
An object of type exception_ptr can be compared for equality with a null
pointer constant
#include
int main()
{
std::exception_ptr p;
return (p == 0);
}
eptr.cc: In function int main():
eptr.cc:7: error: ambiguous overload for operator== in p == 0
eptr.cc:7: note: candidates are: operator==(void
(std::__exception_ptr::exception_ptr::*)(), void
(std::__exception_ptr::exception_ptr::*)())
/dev/shm/wakelyjo/insroot/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/exception_ptr.h:148:
note: bool std::__exception_ptr::operator==(const
std::__exception_ptr::exception_ptr&, const
std::__exception_ptr::exception_ptr&)
--
Summary: [C++0x] std::exception_ptr comparisons
Product: gcc
Version: 4.5.0
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=40296
[Bug libstdc++/40297] New: [C++0x] debug mode vs atomics
The atomic types in have debug-mode assertions that will always
fail.
#define _GLIBCXX_DEBUG
#include
int main()
{
std::atomic_address ptr;
return ptr.load() ? 0 : 1;
}
Fails with:
/dev/shm/wakelyjo/insroot/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/atomic_2.h:114:
void* std::__atomic2::atomic_address::load(std::memory_order) const volatile:
Assertion '__m == memory_order_release' failed.
Due to:
void*
load(memory_order __m = memory_order_seq_cst) const volatile
{
__glibcxx_assert(__m == memory_order_release);
__glibcxx_assert(__m == memory_order_acq_rel);
__sync_synchronize();
void* __ret = _M_i;
__sync_synchronize();
return __ret;
}
Since memory_order is an enumeration and each enumerator has a distinct value,
it's not possible for both assertions to pass.
I'm not sure what they were intended to check, unless it's to prevent atomics
being used in debug mode!
--
Summary: [C++0x] debug mode vs atomics
Product: gcc
Version: 4.5.0
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=40297
[Bug c++/34022] C++0x: rvalue references and std::forward() broken with built-in types
--- 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 CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34022
[Bug c++/40295] [C++0x] rvalue-references and builtin types
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40295
gcc-bugs@gcc.gnu.org
--- 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/bugzilla/show_bug.cgi?id=37089
[Bug c++/39050] [c++0x] rvalue reference & copy construction issue
--- 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: error: initializing argument 1 of void f(S) -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC| |jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39050
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- 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 be done unambiguously, adding that non-standard conversion would
encourage non-portable code. I think operator! should be removed for the same
reason.
I also noticed the move-assignment operator adds no value:
#ifdef __GXX_EXPERIMENTAL_CXX0X__
exception_ptr&
operator=(exception_ptr&& __o) throw()
{
exception_ptr(__o).swap(*this);
return *this;
}
#endif
That should be
exception_ptr(static_cast(__o)).swap(*this);
because otherwise the temporary is copy-constructed, not move-constructed, and
therefore the effect is identical to the lvalue assignment operator,
incrementing and decrementing the refcount.
(static_cast to rvalue-reference must be used, because std::move() is not
available in libsupc++)
I'll fix that separately, as part of a forthcoming patch implementing n2844.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- 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't be necessary. Similar problems exist when invoking std::function with scalar rvalue arguments. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added BugsThisDependsOn||34022 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC
--- 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 uncosntructed streambuf.
You shoudl either pass a null pointer to the base class, then call m_buf.init()
in the MyStream constructor body, or use the base-from-member idiom to
initialise m_buf before the base class.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391
[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC
--- 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 constructor. You should either call the default constructor of the base class, then call this->init(&m_buf) ... > in the MyStream constructor body, or use the base-from-member idiom to > initialise m_buf before the base class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391
[Bug target/26397] Program crashes when rethrowing exception
--- 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&rev=141646 > Log: > PR target/26397 > * config/rs6000/aix.h (LIBSTDCXX_STATIC): Define. > > cp/ > * g++spec.c (LIBSTDCXX_STATIC): New. > (lang_spec_driver): Use LIBSTDCXX_STATIC when not shared_libgcc. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/rs6000/aix.h > trunk/gcc/cp/ChangeLog > trunk/gcc/cp/g++spec.c > http://gcc.gnu.org/ml/gcc/2009-06/msg00231.html shows that the string "-lstdc++ -lsupc++" is passed to collect2 as a single argument via execvp, resulting in an attempt to link to "libstdc++ -lsupc++" which is not valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC
--- 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 pass a null pointer. The description for basic_ios::init() > (27.4.4.1) says that, as a postcondition, rdstate() is "goodbit if sb is not a > null pointer, otherwise badbit". You're right, I should have checked before replying. > Can someone please do me a favor and test this with a more current version of > gcc? I can't test on ppc. Where is the segfault? gdb or valgrind should tell you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391
[Bug c++/32534] gcc fails to initialize template's static data members before their use in some cases
--- 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 what you mean but this works fine:
template<> A B::a = A();
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC| |jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
[Bug c++/32534] gcc fails to initialize template's static data members before their use in some cases
--- 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::a = A();
template
struct C
{
C()
{
printf("C::C %d\n", B::a.value);
B::a.value = 2;
}
};
C c;
int main()
{
printf("main %d\n", B::a.value);
}
compiled with 4.3.2 prints:
C::C 0
A::A 1
main 1
but I expect:
A::A 1
C::C 1
main 2
It seems that the initializer for B::a runs after the initialization of c,
so although the B::a.value gets set by C::C it then gets overwritten by
A::A
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
[Bug c++/40434] [C++0x] g++ does not obey 8.3.5p5?!
--- 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, which fails to compile (as with the next line.) -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC| |jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40434
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- 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 version 2.3.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
--- 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 should be
__glibcxx_assert(__m != memory_order_release);
__glibcxx_assert(__m != memory_order_acq_rel);
I can prepare a patch to fix that everywhere if Benjamin agrees.
Debug mode apart, I think there are more problems with the memory ordering.
__atomic2::atomic_flag::test_and_set() issues a full barrier when m ==
memory_order_relaxed (too much synchronization) but is not a release operation
when m == memory_order_acq_rel (not enough synchronization.)
sync_lock_test_and_set is always an acquire barrier, so the full barrier is
only needed when the ordering specifies it should also be a release operation
i.e.
bool
test_and_set(memory_order __m = memory_order_seq_cst) volatile
{
// Redundant synchronize if built-in for lock is a full barrier.
if (__m >= memory_order_release)
__sync_synchronize();
return __sync_lock_test_and_set(&_M_i, 1);
}
__atomic2::atomic_flag::clear also issues an unwanted full memory barrier when
m == memory_order_relaxed, and in debug mode doesn't enforce the requirement
that m != acquire and m != acq_rel.
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, assuming it is,
I would write it:
void
clear(memory_order __m = memory_order_seq_cst) volatile
{
__glibcxx_assert(__m != memory_order_acquire);
__glibcxx_assert(__m != memory_order_acq_rel);
__sync_lock_release(&_M_i);
if (__m == memory_order_seq_cst)
__sync_synchronize();
}
atomic_*::store() has no memory barrier when m == memory_order_release.
atomic_*::fetch() would benefit from an atomic load operation.
atomic_*::exchange() needs a release barrier when m >= memory_order_release.
N.B. I have not fully grokked the atomic operations library, so everything I've
said above might be wrong!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug other/40458] gcc flavours
--- 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
[Bug other/40458] gcc flavours
--- 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
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
--- 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 should disallow consume so Lawrence Crowl will address it in a forthcoming paper. (In reply to comment #3) > me, so yes proceed please. I'm still not sure that this kind of debug mode > only > error handling is correct but it seems like an approach that is vaguely > familiar from other parts of the library. So at least usage is consistent, > even > if the original implementation was plain wrong The approach seems fine to me, but then I'm a frequent user of _GLIBCXX_DEBUG anyway. > There are many problems with memory ordering in the atomics2 implementation. > It > is known to be incorrect and incomplete, as the saying goes. The goal was to > start experimenting with compliler builtins assuming x86_64 hardware and see > how far we got, what kind of compiler intrinsics we needed first, how we test > this stuff, etc etc. The current code is more than good enough to let me start experimenting and feeling my way around so please take my comments as feedback not complaints :-) I'll prepare a patch to reverse the sense of the debug assertions, but won't change anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- 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 std::forward were *not* accepted into the WP yet, I think there's ongoing work in that area. Because of that, I'm not sure what would happen if the front end changes were applied (I think the current definitions of std::move and std::forward would break large parts of the library!) -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC| |jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- 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
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- 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 draft. That needs fixing too. > > > > If you are referring to: > > template > pair make_pair(T1&& x, T2&& y); > > I'm not into concepts yet (the reason being obvious :-), but I think > T1,T2 can be lvalue-references. Unfortunately, in this case, under > reference collapsing rules, this _will_ accept lvalues and perfectly forward > them to the pair constructor. Ah, OK, I hadn't understood that correctly, thanks for the explanation. > Am I off the track here? As for deducing pair template parameters as described > in WP, I can only see symptoms of "coding under influence" :-D I'm not sure, so I'll take your word for it :-) > I say "unfortunately" above, because I don't like the syntax (namely &&) > used to express a function that can take both lvalues and rvalues. > I have objected on comp.std.c++, but got no real support. > Also, about move and forward. IMHO, those presented in the patch > seem fine. Did I understand correctly that the only thing you > are waiting is acceptance into WP? I guess the functionality will > remain the same. It might be they have issues with concepts. > I'm only guessing, so I apologize if you have some _solid_ information. Yes, I was just pointing out that the WP currently doesn't have the changes to std::forward and std::move - I don't know why, or what the final versions might look like. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
--- 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{/usr/bin} before @file{/usr/xpg4/bin} for the duration of the build.
That directly contradicts my experience with this bug, which is that you must
have /usr/xpg4/bin/sed earlier in your path than /usr/bin/sed in order to get
symbol versioning in libstdc++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
[Bug libstdc++/40518] New: data races when calling std::string::erase() on empty string
ed int)
(basic_string.h:1133)
==17699==by 0x80486DF: do_work(void*) (etbe2.cc:8)
==17699==by 0x4AA970B: mythread_wrapper (hg_intercepts.c:194)
==17699==by 0x96745A: start_thread (in /lib/libpthread-2.5.so)
==17699==by 0x8EDC4D: clone (in /lib/libc-2.5.so)
==17699== This conflicts with a previous write of size 4 by thread #2
==17699==at 0x602B998: std::string::_M_mutate(unsigned int, unsigned int,
unsigned int) (basic_string.h:201)
==17699==by 0x602C187: std::string::erase(unsigned int, unsigned int)
(basic_string.h:1133)
==17699==by 0x80486DF: do_work(void*) (etbe2.cc:8)
==17699==by 0x4AA970B: mythread_wrapper (hg_intercepts.c:194)
==17699==by 0x96745A: start_thread (in /lib/libpthread-2.5.so)
==17699==by 0x8EDC4D: clone (in /lib/libc-2.5.so)
==17699==
==17699== Possible data race during write of size 4 at 0x607d688 by thread #3
==17699==at 0x602B99F: std::string::_M_mutate(unsigned int, unsigned int,
unsigned int) (basic_string.h:207)
==17699==by 0x602C187: std::string::erase(unsigned int, unsigned int)
(basic_string.h:1133)
==17699==by 0x80486DF: do_work(void*) (etbe2.cc:8)
==17699==by 0x4AA970B: mythread_wrapper (hg_intercepts.c:194)
==17699==by 0x96745A: start_thread (in /lib/libpthread-2.5.so)
==17699==by 0x8EDC4D: clone (in /lib/libc-2.5.so)
==17699== This conflicts with a previous write of size 4 by thread #2
==17699==at 0x602B99F: std::string::_M_mutate(unsigned int, unsigned int,
unsigned int) (basic_string.h:207)
==17699==by 0x602C187: std::string::erase(unsigned int, unsigned int)
(basic_string.h:1133)
==17699==by 0x80486DF: do_work(void*) (etbe2.cc:8)
==17699==by 0x4AA970B: mythread_wrapper (hg_intercepts.c:194)
==17699==by 0x96745A: start_thread (in /lib/libpthread-2.5.so)
==17699==by 0x8EDC4D: clone (in /lib/libc-2.5.so)
==17699==
==17699== Possible data race during write of size 1 at 0x607d694 by thread #3
==17699==at 0x602B9A1: std::string::_M_mutate(unsigned int, unsigned int,
unsigned int) (char_traits.h:246)
==17699==by 0x602C187: std::string::erase(unsigned int, unsigned int)
(basic_string.h:1133)
==17699==by 0x80486DF: do_work(void*) (etbe2.cc:8)
==17699==by 0x4AA970B: mythread_wrapper (hg_intercepts.c:194)
==17699==by 0x96745A: start_thread (in /lib/libpthread-2.5.so)
==17699==by 0x8EDC4D: clone (in /lib/libc-2.5.so)
==17699== This conflicts with a previous write of size 1 by thread #2
==17699==at 0x602B9A1: std::string::_M_mutate(unsigned int, unsigned int,
unsigned int) (char_traits.h:246)
==17699==by 0x602C187: std::string::erase(unsigned int, unsigned int)
(basic_string.h:1133)
==17699==by 0x80486DF: do_work(void*) (etbe2.cc:8)
==17699==by 0x4AA970B: mythread_wrapper (hg_intercepts.c:194)
==17699==by 0x96745A: start_thread (in /lib/libpthread-2.5.so)
==17699==by 0x8EDC4D: clone (in /lib/libc-2.5.so)
==17699==
==17699== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 8 from 2)
The storage is written to, even if not modified, so this comment may not hold
true:
static _Rep&
_S_empty_rep()
{
// NB: Mild hack to avoid strict-aliasing warnings. Note that
// _S_empty_rep_storage is never modified and the punning should
// be reasonably safe in this case.
void* __p = reinterpret_cast(&_S_empty_rep_storage);
return *reinterpret_cast<_Rep*>(__p);
}
As expected, the helgrind errors are not present with
--enable-fully-dynamic-string
--
Summary: data races when calling std::string::erase() on empty
string
Product: gcc
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
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- 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
[Bug libstdc++/14990] multiset forward iterator is const
--- 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. It is unspecified whether or not iterator and const_iterator are the same type." Also, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322 The libstdc++ behaviour is correct -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC| |jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14990
[Bug libstdc++/14990] multiset forward iterator is const
--- 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
[Bug libstdc++/34106] [parallel mode] Atomic operations compatibility layer needs cleanup
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- 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
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
--- 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 CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- 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::move. * include/std/iosfwd (operator<<): Provide a forwarding operator<< that accepts rvalue streams. (operator>>): Ditto. * include/bits/stl_iterator.h (move_iterator::operator*): Explicitly std::move the result, to convert it to an rvalue reference. * include/bits/stl_move.h (forward): Forward lvalues (which may end up being turned into rvalues). (move): Explicitly static_cast to an rvalue. * testsuite/27_io/rvalue_streams.cc: New; test the use of rvalue streams. Works except for the fact that we can't call str() on the result. (This is an existing issue). I think the move_iterator and tuple changes would be OK to apply now but the stream parts have a FIXME and as discussed, the definition of std::move is undecided. I'll come back to this soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug c++/40595] New: ICE trying to use sfinae with variadic template pack expansion
template
struct S
{
typedef int type;
};
template
struct Get
{
static T get();
};
#ifdef BUG
# define ELLIPSIS ...
#else
# define ELLIPSIS
#endif
template
struct B
{
template
typename S::get() (Get::get() ELLIPSIS) )>::type
f(Args&& ELLIPSIS a);
};
struct X
{
bool operator()(int) const;
};
int main()
{
B b;
b.f(1);
}
jwak...@gcc16:~/src/tests$ g++ -std=c++0x -c pr.cc
jwak...@gcc16:~/src/tests$ g++ -std=c++0x -c pr.cc -DBUG
pr.cc: In instantiation of B:
pr.cc:35:10: instantiated from here
pr.cc:25:9: internal compiler error: in tsubst, at cp/pt.c:9733
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
The code compiles fine with a single template parameter, but not with a
parameter pack of size one.
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
--
Summary: ICE trying to use sfinae with variadic template pack
expansion
Product: gcc
Version: 4.5.0
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=40595
[Bug c++/40595] ICE trying to use sfinae with variadic template pack expansion
--- 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 expression in a sizeof context is not valid in C++03, but the SFINAE rules were extended to cover general expressions by n2634 so I believe the code is valid in C++0x (see 14.9.2 [temp.deduct] p8 in WP n2914) and should result in a type deduction failure not a hard error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40595
[Bug c++/40595] [C++0x] ICE trying to use sfinae with variadic template pack expansion
--- 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 whether the
callable object and arguments are lvalues or rvalues.
If you look at struct _Bind in include/tr1_impl/functional you will see it has
multiple overloads of operator() and __call() with different cv-qualifiers.
Those overloads are used to ensure the cv qualifiers of the functor _M_f are
the same as the cv qualifiers of the _Bind object, as required by
[func.bind.bind]. The return type of those overloads uses result_of, but that
involves forming invalid expressions e.g. when there is no const volatile
operator() on the functor type.
I can solve that by using sfinae to remove the overloads when the expression is
invalid, but this bug prevents it.
A temporary solution would be to remove the const and volatile overloads for
now. That will work for 99% of cases, and will pass most of the testsuite,
because users don't usually invoke const or volatile binders.
This would fail under that workaround:
void f(int);
auto const b = std::bind(f, 1);
b();
Another options would be to support the example above, but to fudge the
result_of so that it does not use the correct cv qualifiers. That would fail
for this case:
struct F {
char* operator() const;
int operator();
};
i.e. when the cv qualifiers of the function object are significant and affect
the result type of the function call operator. For that type, using result_of
with the wrong cv qualifiers would cause _Bind to fail, because it infers a
result tyep that is not convertible to the actual result of the call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40595
[Bug libstdc++/40600] pair& operator=(pair&& __p) doesn't work without inlining
--- 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
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- 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
[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions
--- 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 determines the result of an expression that isn't valid > syntax > for pointers to members. Could Howard or Doug comment on this? the Callable concept and result_of both determine the result of an expression fn(args...) which in invalid if fn is a pointer to member. If that's correct, this bug could be closed as INVALID, but that would mean std::bind and std::reference_wrapper do not support features that work with the equivalent components in TR1. It also means that std::bind() works with pointers to members, even though std::bind() doesn't, because the former doesn't rely on Callable and is only defined in terms of INVOKE which does support pointers to members. I'm trying to figure out if I need to continue to support this behaviour, or if I can simplify result_of by ignoring pointers to members, but I think this should be an LWG issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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/bugzilla/show_bug.cgi?id=40655
[Bug c++/40655] The copy constructor is not needed but GCC (C++) don't let me to initialize my object instance!
--- 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 called copy-initialization and is equivalent to the form T x = a; and 12.8 [class.copy] paragraphs 14 and 15 A program is ill-formed if the copy constructor or the copy assignment operator for an object is implicitly used and the special member function is not accessible ... When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. Your code is invalid, this is not a bug in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40655
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- 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 misunderstanding: you mean overridden, not overloaded. This seems like the sort of thing that could be put in a plugin or other static analysis tool rather than the compiler, because it warns about a preference in coding style. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC| |jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- 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. It is about overwriting. Overriding :-) I'm using the terminology of the C++ standard, but I do have the advantage that it's written in my native language -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- 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 might make sense to add attributes rather than a -W switch, as that might make it easier to implement the C++0x [[base_check]] and [[override]] attributes. It would also be easier for user code to transition from GNU-style __attribute__((override)) to C++0x-style [[override]] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/20423] Warning -Woverloaded-virtual triggers to often
--- 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 declaration may be an error in > defining a virtual function. In a derived class, the definitions of > virtual functions must match the type signature of a virtual > function declared in the base class. With this option, the compiler > warns when you define a function with the same name as a virtual > function, but with a type signature that does not match any > declarations from the base class. But that's not what it does. The description in the manual describes the current behaviour correctly, that description above doesn't. (In reply to comment #6) > A really wild-guess patch. Comments? ... > + /* If at least one method has the same signature, > + the not overloaded variants are just > + hidden. */ > + just_hidden = true; Shouldn't this say "not overridden variants" ? I don't like the name -Wpartial-overloaded-virtual for the same reason. The name should clearly distinguish whether it is triggered by overloading, overriding or hiding. -Woverloaded-virtual is a reasonable name for the current behaviour; it triggers if there is an overload that hides a virtual (whether the overload is itself virtual or not.) The proposed -Wpartial-overloaded-virtual name makes no sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423
[Bug c++/40793] "Error: no matching function for call to XYZ" doesn't display function-template-arguments
--- 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 could find out the same info in seconds by looking at the line. There's no candidate list because there is no match for the template arguments you used. The empty candidate list tells you something by itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
[Bug c++/40828] Rejected valid specialization of member class template
--- 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 specialized"
See the last specialisation in the example following 14.7.3 [temp.expl.spec]
paragraph 18
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40828
[Bug c++/35989] code rejected in template specialization (4.2 did accept)
--- 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 compile quietly. 4.3.2 (g++ -c test.cpp) gives :
>
> kk.cpp:5: error: template parameters not used in partial specialization:
> kk.cpp:5: error: K
>
I think this is invalid because K is used in a non-deduced context
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35989
[Bug c++/35989] code rejected in template specialization (4.2 did accept)
--- 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.4.1 [temp.class.spec.match] paragraph 2 the template arguments of the partial specialisation must be deduced, but in the testcases they appear in non-deduced contexts as defined by 14.8.2.4 [temp.deduct] paragraph 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35989
[Bug c++/40871] g++ does not find lstdc++ on AIX
--- 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 mailing list in this thread: > http://gcc.gnu.org/ml/gcc-help/2009-06/msg00092.html > and a patch was issued. It was supposedly committed to the main branch after > 4.4.0, but for some reason was not present (or did not solve the issue) in > 4.4.1. That will be because 4.4.1 was released from the gcc-4_4-branch, not the main trunk. If the patch wasn't applied to the 4.4 branch (and the mail thread doesn't say it was) then the fix won't be in 4.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40871
[Bug bootstrap/40337] PPLLIBS flags do not include -lm
--- 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/configure.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40337
[Bug c++/40901] Access qualifiers of embedded templates are discarded
--- 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
[Bug c++/40944] [C++0x] rejects well-formed code: SFINAE, decltype, function call
--- 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 >
int bar(T const& x,
decltype( pf(make::it()) )* = 0 // SFINAE!
) {
return 1;
}
int bar(...) {
return 0;
}
int main() {
return bar(42);
}
I think this should compile and return 0
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC| |jwakely dot gcc at gmail dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40944
[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.
--- 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 Comeau rejects it.
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC| |jwakely dot gcc at gmail dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40942
[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved
--- 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);
> };
>
> int i = S().foo((D*)0);
> -
That tries to initialise a B*& with a D* rvalue, which would fail even if D was
the same type as B. This might be a slightly better testcase:
struct B {};
struct D : B {};
struct S {
int foo(B* & taskData);
};
D* p = 0;
int i = S().foo(p);
It might be an improvement if GCC gave different diagnostics for the case where
a suitable conversion sequence exists but cannot be used because it would
create an rvalue which cannot bind to a non-const reference, and the case where
there is no suitable conversion (i.e. the types are unrelated)
That seems to be what 2.95 attempted to do by saying "initializing 'blah' with
'blah' will use a temporary" but I find that message confusing, as it *won't*
use a temporary because doing so is not valid. The message should really have
been something like "initializing 'blah' with 'blah' would use a temporary, but
that's not allowed"
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
------------------------
CC||jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979
[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved
--- 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 = foo( px );
GCC 4.4.1 gives:
pr13979.cc:8:20: error: invalid initialization of non-const reference of type
B*& from a temporary of type B*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*&)
pr13979.cc:10:20: error: invalid initialization of non-const reference of type
B*& from a temporary of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*&)
pr13979.cc:13:17: error: invalid initialization of reference of type B*& from
expression of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*&)
pr13979.cc:16:17: error: invalid initialization of reference of type B*& from
expression of type X*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*&)
Comeau gives equivalent errors in all four cases. The only significant
difference is that Comeau doesn't mention the types in the first two errors.
GCC 2.95.2 is quite different:
pr13979.cc:8: initialization of non-const reference type `struct B *&'
pr13979.cc:8: from rvalue of type `B *'
pr13979.cc:6: in passing argument 1 of `foo(B *&)'
pr13979.cc:10: initializing non-const `B *&' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *&)'
pr13979.cc:13: initializing non-const `B *&' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *&)'
pr13979.cc:16: type `B' is not a base type for type `X'
pr13979.cc:6: in passing argument 1 of `foo(B *&)'
I think the current diagnostics are better than the 2.95 ones. As I said
above, "will use a temporary" is misleading. The fourth error saying "is not a
base type" may be true, but is also misleading, because it wouldn't compile
even if it was a base type.
As I said earlier, it might be nice if the third error said e.g.
pr13979.cc:13:17: error: invalid initialization of reference of type B*& from
expression of type D*
pr13979.cc:6:5: error: in passing argument 1 of int foo(B*&)
pr13979.cc:13:17: note: conversion from `D*' to `B*' would create a temporary
However,
(In reply to comment #8)
> I don't even know if we have different codepaths for those!
if it's not possible then I think the current diagnostics are reasonable, and
at least as good as Comeau's.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979
[Bug c++/31423] Improve upon "invalid use of member (did you forget the '&' ?)"
--- 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 I think changing '&' to '()' unconditionally makes sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug c++/31423] Improve upon "invalid use of member (did you forget the '&' ?)"
--- 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 correctly requires '&C::f' I know some users want the compiler to suggest how to fix their errors, but it's hard to make a useful suggestion for most of the nearly infinite number of invalid expressions users can come up with. The suggestion is misleading in too many cases (specifically, the "did you forget the '&'?" hint doesn't solve the problem in any of the examples given in this PR.) -- jwakely dot gcc at gmail dot com changed: What|Removed |Added -------------------- CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug c++/40997] Wrong address returned in covariant return
--- 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 expected the line: Bar& bar(getOuter()); to adjust the pointer to the Bar 'subobject' but instead it appears to point to the 'Bart' subobject returned by the covariant getOuter(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/40997] Wrong address returned in covariant return
--- 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 << "BaseIf2: " << (BaseIf*)&bar << endl; shows different values for the BaseIf base, which should be unique and unambiguous as it is virtually inherited. BaseIf1: 0x7fff86f73460 BaseIf2: 0x7fff86f73478 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/40997] Wrong address returned in covariant return
--- 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 the class type D. The class Bart is not complete at the point of declaration of Bart::InnerBart::getOuter(), which might explain why the pointer adjustment does not happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/40997] Wrong address returned in covariant return
--- 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 invalid. I think GCC hould have rejected the code, so this is a missing diagnostic, but not wrong-code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/40997] Wrong address returned in covariant return
--- 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 the point of declaration of
> D::f or shall be the class type D.
Here's a reduced testcase for the missing diagnostic:
struct OuterBase { };
struct B
{
virtual OuterBase* f();
};
struct OuterDerived : OuterBase
{
struct D : B {
virtual OuterDerived* f();
};
};
OuterDerived is not complete at the point of declaration of D::f and is not D.
The standard doesn't say this is undefined or "no diagnostic required" so I
think this bug should be 'accepts-invalid' rather than 'wrong-code'
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
----
CC| |jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40997
[Bug c++/41020] Can't declare an extern "C" friend.
--- 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|Removed |Added CC| |jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name
--- 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 'number' > is redundant because statements > test.cpp:15: error: declaration of 'int testclass::number' > test.cpp:9: error: conflicts with previous declaration 'int > testclass::number() const' > that appear before already cover this case. We already have a member named > 'number' so we certainly can't have field with the same name. Diagnostic > claims > that a member 'number' already exist and field with that name cannot be > created > seems to be more reasonable here, but "test.cpp:15" and "test.cpp:9" already > said that. The errors for lines 9 and 15 relate to the duplicate declaration of a member with the name 'number', whereas the error on line 4 refers to the invalid member initializer for 'number'. Those are separate errors. If you removed the declaration of 'int number;' (fixing the error on line 15) then there would still be an error on line 4, so I definitely don't consider that diagnostic to be redundant. > Besides I found it interesting that swapping public: and private: blocks > around > makes diagnostic even more unclear: Huh? The errors are the same except for swapping which declaration is treated as the duplicate and which as the previous declaration, and that's because you swappged the order. What did you expect? Why is it more unclear? (In reply to comment #1) > By the way using gcc instead of g++ doesn't changed things. Good - it shouldn't make any difference in this case. The difference with Comeau apears to be that name lookup finds the member variable 'number' whereas GCC finds the member function 'number' - maybe Comeau's name lookup finds the last declaration of that name and GCC's finds the member function - I'm not sure. Since the code is invalid neither compiler is right or wrong, and personally I don't have a strong preference. Both compilers point out that 'number' is declared twice, which is the main problem in the code that needs to be fixed, and both compilers print that as the first error. 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 about the invalid member initializer and about the return statement in the member function. i.e. when the member function is declared later, Comeau's name lookup finds that one, and behaves similarly to GCC. I don't think there's much scope for improvement here. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002
[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name
--- 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 > about the invalid member initializer and about the return statement in the > member function. i.e. when the member function is declared later, Comeau's > name lookup finds that one, and behaves similarly to GCC. Just to be clear: this means Comeau also prints the error that you consider to be redundant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002
[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.
--- 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
[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.
--- 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 is used. I'll test that fix tonight if noone beats me to it. The problem seems to be present on the 4.4 branch as well as trunk. -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug c++/41002] Redundant diagnostic when class member function's name overlaps with class field's name
--- 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 keeping on emitting errors on every occurence of symbol that becoms a > source of that conflict. In fact GCC found out that it is able to create nor > property number nor member number(); later compiler descried a reference to a > variable that is not exist (because it killed this variable later) and omitted > another error. I agree that compiler exhibits its strict behaviour there but > I'm not shure is it good for non-pedantic mode. Ah, I see what you mean. -pedantic controls something different and I don't think it should suppress later errors as you suggest. You might want to try -Wfatal-errors, which will cause compilation to stop at the first error. That's still not exactly what you want, as it will prevent *all* further errors being printed and not just those which are related to the first one, but I think in general it would be very difficult for the compiler to determine if individual errors are caused by an earlier error and suppress them conditionally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41002
[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend.
--- 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 function scope a lone ';' is a valid expression-statement, but expression-statements are not allowed at namespace scope, only declarations are, and ';' is not a valid declaration. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.
--- 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/gcc/Template-Instantiation.html 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.
--- 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 in this case it fails to provide an explicit instantiation of the new C++0x members because src/fstream-inst.cc is not compiled with -std=c++0x or -std=gnu++0x So the library tells the compiler not to instantiate the templates in your code, promising to provide explicit instantiations, and then fails to provide the explicit instantiations. So the workaround I gave in comment #3 provides them in your program. Another workaround would be to compile with -D_GLIBCXX_EXTERN_TEMPLATE=0, which disables the extern template feature, causing the compiler to implicitly instantiate the templates in every file that needs them, and then rely on the linker to merge the duplicate definitions. But the right fix is just to ensure src/fstream-inst.cc is compiled in C++0x mode, so that the instantiations are present in libstdc++.so and you don't need any workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- 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
[Bug c++/20423] Warning -Woverloaded-virtual triggers to often
--- 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 proposed in that paper allow the derived class to explicitly state whether a function should override or hide the same name in the base class, making it ill-formed if there is unintended hiding -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC| |jwakely dot gcc at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423
[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.
--- 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: src/Makefile.am === --- src/Makefile.am (revision 150635) +++ src/Makefile.am (working copy) @@ -278,6 +278,11 @@ atomic.lo: atomic.cc atomic.o: atomic.cc $(CXXCOMPILE) -std=gnu++0x -c $< +fstream-inst.lo: fstream-inst.cc + $(LTCXXCOMPILE) -std=gnu++0x -c $< +fstream-inst.o: fstream-inst.cc + $(CXXCOMPILE) -std=gnu++0x -c $< + string-inst.lo: string-inst.cc $(LTCXXCOMPILE) -std=gnu++0x -c $< string-inst.o: string-inst.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
[Bug c++/41039] Member reordering rule is overly strict
--- 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 is required for a violation of this rule.
'foo' is used in the class, but in the completed scope which includes the
function body of S::foo() 'foo' refers to the member function.
If you don't want to use -fpermissive you can convince gcc to compile it by
referring to the type as '::foo' because in that case the name always refers to
the global type even in the completed scope.
struct foo { };
struct bar {
::foo foo();
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41039
