[Bug c++/64383] missed warning for unused variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64383
--- Comment #2 from Pawel Sikora pluto at agmk dot net ---
(In reply to Manuel López-Ibáñez from comment #1)
A minimized testcase would be helpful. Using delta would probably remove
already a lot: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
one more small testcase w/o stl with missed warning.
struct Y
{
~Y(); // comment this line to get proper warning about 'unused y variable'
};
struct X
{
static Y get();
};
int main()
{
Y y = X::get();
}
clang 3.5.0 warns in both (w/ and w/o Y dtor) variants.
[Bug c++/64383] New: missed warning for unused variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64383
Bug ID: 64383
Summary: missed warning for unused variable.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
#include memory
#include vector
int main()
{
std::vector std::shared_ptr int v1;
v1.push_back( std::make_shared int ( 7 ) );
for( auto p : v1 )
{
}
std::vector int v2;
v2.push_back( 7 );
for( auto i : v2 )
{
}
}
the 'p' variable is not reported as unused.
% LANG=C g++ -Wall -g2 t.cpp -o t -std=c++1y
t.cpp: In function 'int main()':
t.cpp:13:15: warning: unused variable 'i' [-Wunused-variable]
for( auto i : v2 )
^
[Bug libstdc++/63993] New: vector::insert( make_move_iterator... ) broken by GLIBCXX_DEBUG.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63993
Bug ID: 63993
Summary: vector::insert( make_move_iterator... ) broken by
GLIBCXX_DEBUG.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
#include iterator
#include string
#include vector
int main()
{
std::vector std::string v, t;
t.push_back( hello );
v.insert( v.end(), std::make_move_iterator( t.begin() ),
std::make_move_iterator( t.end() ) );
t.clear();
}
% LANG=C
~/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++
-Wall gcc-bug-new.cpp -std=c++11 -D_GLIBCXX_DEBUG=1
(...)
gcc-bug-new.cpp:9:97: required from here
/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/x86_64-gnu-linux/include/c++/4.9.2/debug/functions.h:220:69:
error: invalid initialization of non-const reference of type
'std::__7::basic_stringchar' from an rvalue of type
'std::__7::move_iterator__gnu_debug::_Safe_iterator__gnu_cxx::__7::__normal_iteratorstd::__7::basic_stringchar*,
std::__cxx1998::__7::vectorstd::__7::basic_stringchar,
std::__7::allocatorstd::__7::basic_stringchar ,
std::__debug::vectorstd::__7::basic_stringchar ::value_type {aka
std::__7::basic_stringchar}'
return __foreign_iterator_aux4(__it, std::__addressof(*__other));
^
In file included from
/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/x86_64-gnu-linux/include/c++/4.9.2/debug/functions.h:36:0,
from
/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/x86_64-gnu-linux/include/c++/4.9.2/debug/debug.h:127,
from
/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/x86_64-gnu-linux/include/c++/4.9.2/bits/stl_iterator_base_funcs.h:65,
from
/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/x86_64-gnu-linux/include/c++/4.9.2/iterator:62,
from gcc-bug-new.cpp:1:
/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/x86_64-gnu-linux/include/c++/4.9.2/bits/move.h:47:5:
note: in passing argument 1 of '_Tp* std::__7::__addressof(_Tp) [with _Tp =
std::__7::basic_stringchar]'
__addressof(_Tp __r) _GLIBCXX_NOEXCEPT
^
[Bug libstdc++/63993] vector::insert( make_move_iterator... ) broken by GLIBCXX_DEBUG.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63993 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Pawel Sikora pluto at agmk dot net --- ahh, yes. testcase was tested on the 4.9.2-prerelease.from 20140804.
[Bug libstdc++/63746] New: i/o fragmentation inside basic_filebuf::xsputn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63746
Bug ID: 63746
Summary: i/o fragmentation inside basic_filebuf::xsputn
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
Hi,
i'm trying to minimize small i/o operations for better overal
application perfromance over networked filesystems.
setting quite large stream buffer doesn't work as axpected
in some cases.
#include iostream
#include fstream
#include memory
#include sstream
#include string
int main()
{
std::size_t bufferSize = 1024*1024;
std::unique_ptr char buffer( new char[ bufferSize ] );
std::ofstream f;
f.rdbuf()-pubsetbuf( buffer.get(), bufferSize );
f.open( s.txt, std::ios_base::out | std::ios_base::binary );
std::stringstream ss;
std::string s1( 10240, 'x' );
ss.str( std::string() );
ss s1;
f ss.rdbuf();
ss.str( std::string() );
ss s1;
f ss.rdbuf();
f.close();
}
% g++ s.cpp -o s -Wall -g2 -std=c++11
% LANG=C strace ./s
(...)
open(s.txt, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
writev(3, [{NULL, 0}, {..., 8136}], 2) = 8136
writev(3, [{, 0}, {..., 2104}], 2) = 2104
writev(3, [{, 0}, {..., 10240}], 2) = 10240
close(3)
i've expected that 20kB i/o from testcase will fit in the 1MB buffer
but the fstream.tcc contains magic const __chunk = 1k and logic that
not use the buffer in the optimal way.
[Bug libstdc++/63746] i/o fragmentation inside basic_filebuf::xsputn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63746 --- Comment #1 from Pawel Sikora pluto at agmk dot net --- Created attachment 33893 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33893action=edit my hack.
[Bug libstdc++/63343] New: g++ accepts incompatible iterator assignemt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63343
Bug ID: 63343
Summary: g++ accepts incompatible iterator assignemt
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
hi, the current g++ accepts incompatible iterator assignment.
#include map
int main()
{
std::map int, int m;
std::multimap int, int ::iterator i = m.end();
}
only with _GLIBCXX_DEBUG there's an expected build error.
[Bug libstdc++/63343] g++ accepts incompatible iterator assignemt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63343 --- Comment #2 from Pawel Sikora pluto at agmk dot net --- release code is scary, debug code is broken, nightmare :
[Bug libstdc++/54173] -D_GLIBCXX_DEBUG breaks string::_Rep::_S_empty_rep_storage weak binding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54173 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Pawel Sikora pluto at agmk dot net --- currently i'm using a gcc configured with --disable-gnu-unique-object, --disable-initfini-array (not supported by ld.so on older *enterprise* redhat/suse distros) and --with-linker-hash-style=both (.gnu.hash section w/o sysv .hash causes divide by 0 inside older ld.so). finally, i'm building my application with -fms-compat-visiblity and explicite __attribute__((visibility(default))) exports instead of tricky linker scripts. such options give me pretty portable binaries (works well on rhel5, rhel6, suse11).
[Bug libstdc++/61329] New: #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 Bug ID: 61329 Summary: #include regex and _GLIBCXX_DEBUG causes multiple symbol definition. Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: pluto at agmk dot net Created attachment 32860 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32860action=edit testcase % g++ t.cpp -Og -g0 -c -std=c++11 -D_GLIBCXX_DEBUG % g++ u.cpp -Og -g0 -c -std=c++11 -D_GLIBCXX_DEBUG % g++ t.o u.o -s -o /dev/null u.o: In function `std::__detail::__7::_State_base::_M_print(std::__7::basic_ostreamchar, std::__7::char_traitschar ) const': u.cpp:(.text+0x0): multiple definition of `std::__detail::__7::_State_base::_M_print(std::__7::basic_ostreamchar, std::__7::char_traitschar ) const' t.o:t.cpp:(.text+0x0): first defined here u.o: In function `std::__detail::__7::_State_base::_M_dot(std::__7::basic_ostreamchar, std::__7::char_traitschar , long) const': u.cpp:(.text+0x1ae): multiple definition of `std::__detail::__7::_State_base::_M_dot(std::__7::basic_ostreamchar, std::__7::char_traitschar , long) const' t.o:t.cpp:(.text+0x1ae): first defined here collect2: error: ld returned 1 exit status % g++ -v Using built-in specs. COLLECT_GCC=/ahome/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ COLLECT_LTO_WRAPPER=/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/../lib64/gcc/x86_64-gnu-linux/4.9.1/lto-wrapper Target: x86_64-gnu-linux Configured with: ../configure --target=x86_64-gnu-linux --with-arch=x86-64 --prefix=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux --with-sysroot=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux --libdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64 --libexecdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64 --with-slibdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64 --with-gmp-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-gmp-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpfr-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-mpfr-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpc-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-mpc-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-linker-hash-style=both --disable-multilib --enable-nls --disable-libssp --disable-libquadmath --disable-libitm --enable-tls --enable-libstdcxx-allocator=new --enable-extern-template --enable-libstdcxx-time=rt --enable-libstdcxx-threads --enable-symvers=gnu-versioned-namespace --disable-libstdcxx-pch --enable-lto --enable-plugin --enable-c99 --enable-long-long --enable-linux-futex --enable-threads=posix --enable-shared --with-pic --enable-gold --enable-libgomp --enable-__cxa_atexit --disable-initfini-array --disable-gnu-unique-object --enable-languages=c,c++ --enable-checking=release --with-long-double-128 --disable-cld --disable-bootstrap Thread model: posix gcc version 4.9.1 20140505 (prerelease) (GCC)
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 --- Comment #1 from Pawel Sikora pluto at agmk dot net --- Created attachment 32861 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32861action=edit testcase
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 --- Comment #2 from Pawel Sikora pluto at agmk dot net --- _M_dot/_M_print declaration from include/c++/4.9.1/bits/regex_automaton.h needs inline attribute.
[Bug libstdc++/59476] gdb pretty-printer cannot print C++11 _Rb_tree_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59476 --- Comment #1 from Pawel Sikora pluto at agmk dot net --- 4.9.0 released with unusable pretty printers :/
[Bug debug/59105] -fdebug-prefix-map doesn't affect DW_AT_comp_dir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59105 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Pawel Sikora pluto at agmk dot net --- my fault, the trailing slash in -fdebug-prefix-map was a problem.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
--- Comment #17 from Pawel Sikora pluto at agmk dot net ---
pure gcc 4.9.0 20140106 still fails:
Breakpoint 2, main () at pr53477.cpp:15
(gdb) p wordBitsetMap
$1 = std::map with 1 elementsTraceback (most recent call last):
File /home/pawels/gcc/4.9/share/gcc-4.9.0/python/libstdcxx/v6/printers.py,
line 438, in children
rep_type = find_type(self.val.type, '_Rep_type')
File /home/pawels/gcc/4.9/share/gcc-4.9.0/python/libstdcxx/v6/printers.py,
line 54, in find_type
raise ValueError, Cannot find type %s::%s % (str(orig), name)
ValueError: Cannot find type const std::mapunsigned int, std::mapunsigned
int, std::setunsigned int, std::__7::lessunsigned int,
std::__7::allocatorunsigned int , std:
:__7::lessunsigned int, std::__7::allocatorstd::__7::pairunsigned int
const, std::setunsigned int, std::__7::lessunsigned int,
std::__7::allocatorunsigned int
, std::__7::lessunsigned int, std::__7::allocatorstd::__7::pairunsigned int
const, std::mapunsigned int, std::setunsigned int, std::__7::lessunsigned
int, std::__7::al
locatorunsigned int , std::__7::lessunsigned int,
std::__7::allocatorstd::__7::pairunsigned int const, std::setunsigned int,
std::__7::lessunsigned int, std::__7::al
locatorunsigned int ::mapped_type::_Rep_type
patch propses in comment #10 works for me:
Breakpoint 2, main () at pr53477.cpp:15
(gdb) p wordBitsetMap
$1 = std::map with 1 elements = {
[3] = std::set with 2 elements = {
[0] = 1,
[1] = 5
}
}
[Bug debug/59105] New: -fdebug-prefix-map doesn't affect DW_AT_comp_dir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59105 Bug ID: 59105 Summary: -fdebug-prefix-map doesn't affect DW_AT_comp_dir. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: pluto at agmk dot net Created attachment 31203 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31203action=edit testcase hi, i'm trying to use -fdebug-prefix-map to reuse (ccache) compilation units across multiple software branches. the first problem was reported as PR58767 and the second one is here. the gcc hardcodes DW_AT_comp_dir when -fdebug-prefix-map is in use and prevents ccache from computing identical checksum/manifest. imo -fdebug-prefix-map should adjust DW_AT_comp_dir in the same way as source name (DW_AT_name). $ ./bug.sh + rm -f '*.o' + CXXFLAGS='-Wall -gno-record-gcc-switches -g2 -gdwarf-4 -c' + cd repo/branch + readlink -m t.cpp + src=/home/users/pawels/bugs/gcc-bug/repo/branch/t.cpp + dirname /home/users/pawels/bugs/gcc-bug/repo/branch/t.cpp + g++ -Wall -gno-record-gcc-switches -g2 -gdwarf-4 -c /home/users/pawels/bugs/gcc-bug/repo/branch/t.cpp '-fdebug-prefix-map=/home/users/pawels/bugs/gcc-bug/repo/branch/=' + objdump -g t.o + grep -E DW_AT_name.+cpp 11 DW_AT_name: (indirect string, offset: 0x0): t.cpp + objdump -g t.o + grep -E DW_AT_comp_dir.+string 15 DW_AT_comp_dir: (indirect string, offset: 0x14c): /home/users/pawels/bugs/gcc-bug/repo/branch + cd ../..
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
Pawel Sikora pluto at agmk dot net changed:
What|Removed |Added
CC||pluto at agmk dot net
--- Comment #39 from Pawel Sikora pluto at agmk dot net ---
Hi,
i see mentioned linker error on the current gcc-4.8.2 for i686-gnu-linux target
and somehow it works for x86_64-gnu-linux target.
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostreamchar, std::__7::char_traitschar
-in-UnitTest::MemoryOutStream: error: undefined reference to 'virtual thunk to
std::__7::basic_ostreamchar, std::__7::char_traitschar ::~basic_ostream()'
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostreamchar, std::__7::char_traitschar
-in-UnitTest::MemoryOutStream: error: undefined reference to 'virtual thunk to
std::__7::basic_ostreamchar, std::__7::char_traitschar ::~basic_ostream()'
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostringstreamchar, std::__7::char_traitschar,
std::__7::allocatorchar -in-UnitTest::MemoryOutStream: error: undefined
reference to 'virtual thunk to std::__7::basic_ostringstreamchar,
std::__7::char_traitschar, std::__7::allocatorchar
::~basic_ostringstream()'
../../../lib/libUnitTest++.a(Test.cpp.o):Test.cpp:function construction vtable
for std::__7::basic_ostringstreamchar, std::__7::char_traitschar,
std::__7::allocatorchar -in-UnitTest::MemoryOutStream: error: undefined
reference to 'virtual thunk to std::__7::basic_ostringstreamchar,
std::__7::char_traitschar, std::__7::allocatorchar
::~basic_ostringstream()'
MemoryOutStream is declared in the UnitTest++ as:
#include sstream
namespace UnitTest
{
class MemoryOutStream : public std::ostringstream
{
public:
MemoryOutStream() {}
char const* GetText() const;
private:
MemoryOutStream(MemoryOutStream const);
void operator =(MemoryOutStream const);
mutable std::string m_text;
};
}
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #40 from Pawel Sikora pluto at agmk dot net --- $ grep ZTv0 * gnu.ver:_ZTv0_n12_NS*; gnu.ver:_ZTv0_n24_NS*; gnu-versioned-namespace.ver:_ZTv0_n24_NS*; versioned namespace doesn't provide *n12* for i686.
[Bug other/58319] New: explicit cast doesn't disable -Wconversion warning.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58319
Bug ID: 58319
Summary: explicit cast doesn't disable -Wconversion warning.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
$ cat u.cpp
struct X { unsigned field : 31; };
int main()
{
unsigned u = 0u;
X x = { .field = static_cast typeof( X::field ) ( u ) };
return x.field;
}
$ g++ u.cpp -c -Wconversion
u.cpp: In function ‘int main()’:
u.cpp:6:58: warning: conversion to ‘unsigned int:31’ from ‘unsigned int’ may
alter its value [-Wconversion]
X x = { .field = static_cast typeof( X::field ) ( u ) };
^
[Bug other/58319] explicit cast doesn't disable -Wconversion warning.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58319 --- Comment #2 from Pawel Sikora pluto at agmk dot net --- (In reply to Paolo Carlini from comment #1) Your cast does nothing, because your typeof (or decltype) is just unsigned int. Given that, the warning makes sense to me and certainly is well known. so how can i cast this value to avoid warning?
[Bug c++/58316] New: error: call of overloaded ‘foo(long long unsigned int, long long unsigned int)’ is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58316
Bug ID: 58316
Summary: error: call of overloaded ‘foo(long long unsigned int,
long long unsigned int)’ is ambiguous
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
$ cat t.cpp
#if !defined( __GNUC__) !defined( __x86_64__)
#error testcase requires LLP64 arch
#endif
typedef unsigned long u64_t1;
void foo( u64_t1, u64_t1 );
void foo( unsigned, unsigned );
void bar()
{
foo( 0xull, 0xull );
}
$ g++ -Wall t.cpp -c -m64
t.cpp: In function ‘void bar()’:
t.cpp:12:52: error: call of overloaded ‘foo(long long unsigned int, long long
unsigned int)’ is ambiguous
foo( 0xull, 0xull );
^
t.cpp:12:52: note: candidates are:
t.cpp:7:6: note: void foo(u64_t1, u64_t1)
void foo( u64_t1, u64_t1 );
^
t.cpp:8:6: note: void foo(unsigned int, unsigned int)
void foo( unsigned, unsigned );
^
the 'unsigned long' and 'unsigned long long' have the same size
on the x86-64(llp64) target, so where's the ambiguity?
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Known to fail||4.9.0 --- Comment #16 from Pawel Sikora pluto at agmk dot net --- (In reply to Phil Muldoon from comment #14) It should be fixed for all cases in the PR. I think we can close it, and if any of the people commenting on this bug have issues, they can reopen it. My pmuld...@redhat.com account does not have sufficient privileges to alter the state of the bug, or the assignee. (Though I did not try with my gcc.gnu.org account) i still see a failure: (gdb) p wordBitsetMap $1 = Python Exception type 'exceptions.ValueError' Cannot find type const std::mapunsigned int, std::mapunsigned int, std::setunsigned int, std::__7::les sunsigned int, std::__7::allocatorunsigned int , std::__7::lessunsigned int, std::__7::allocatorstd::__7::pairunsigned int const, std::setunsigned i nt, std::__7::lessunsigned int, std::__7::allocatorunsigned int, std::__7::lessunsigned int, std::__7::allocatorstd::__7::pairunsigned int con st, std::mapunsigned int, std::setunsigned int, std::__7::lessunsigned int, std::__7::allocatorunsigned int , std::__7::lessunsigned int, std::__7::a llocatorstd::__7::pairunsigned int const, std::setunsigned int, std::__7::lessunsigned int, std::__7::allocatorunsigned int ::mapped_type: :_Rep_type: std::map with 1 elements previously it failed with: (gdb) p wordBitsetMap $1 = Python Exception type 'exceptions.IndexError' list index out of range: std::map with 1 elements
[Bug debug/57828] New: linker error: undefined reference to '.LLSTxxx'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57828 Bug ID: 57828 Summary: linker error: undefined reference to '.LLSTxxx' Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: pluto at agmk dot net Created attachment 30462 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30462action=edit testcase. $ ~/dvm/sandbox/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -v Using built-in specs. COLLECT_GCC=/ahome/pawels/dvm/sandbox/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ COLLECT_LTO_WRAPPER=/home/users/pawels/dvm/sandbox/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/../lib64/gcc/x86_64-gnu-linux/4.7.3/lto-wrapper Target: x86_64-gnu-linux Configured with: ../configure --target=x86_64-gnu-linux --with-arch=x86-64 --prefix=/home/pawels/buildenv.git/gcc/sysroot/x86_64-gnu-linux --with-sysroot=/home/pawels/buildenv.git/gcc/sysroot/x86_64-gnu-linux --libdir=/home/pawels/buildenv.git/gcc/sysroot/x86_64-gnu-linux/lib64 --libexecdir=/home/pawels/buildenv.git/gcc/sysroot/x86_64-gnu-linux/lib64 --with-slibdir=/home/pawels/buildenv.git/gcc/sysroot/x86_64-gnu-linux/lib64 --with-gmp-include=/home/pawels/buildenv.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-gmp-lib=/home/pawels/buildenv.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpfr-include=/home/pawels/buildenv.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-mpfr-lib=/home/pawels/buildenv.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpc-include=/home/pawels/buildenv.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-mpc-lib=/home/pawels/buildenv.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --disable-multilib --enable-nls --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libitm --enable-tls --enable-libstdcxx-allocator=new --enable-extern-template --enable-libstdcxx-time=rt --enable-libstdcxx-threads --disable-libstdcxx-pch --disable-lto --disable-plugin --enable-c99 --enable-long-long --enable-linux-futex --enable-threads=posix --enable-shared --with-pic --enable-gold --enable-libgomp --enable-__cxa_atexit --disable-initfini-array --enable-languages=c,c++ --enable-checking=release --with-long-double-128 --disable-cld --disable-bootstrap Thread model: posix gcc version 4.7.3 (GCC) $ ~/dvm/sandbox/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ dogGenTop.ii -c -fPIC -std=gnu++11 --save-temps -fdwarf2-cfi-asm -fno-strict-aliasing -O1 -g2 -gdwarf-4 $ ~/dvm/sandbox/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ *.o -fPIC -shared -o dog.so -zdefs 21 | grep '.LL' dogGenTop.o(.debug_types+0x87e): error: undefined reference to '.LLST376' dogGenTop.o(.debug_types+0x95e): error: undefined reference to '.LLST381' dogGenTop.o(.debug_types+0xa3a): error: undefined reference to '.LLST385' dogGenTop.o(.debug_types+0xdb9): error: undefined reference to '.LLST204' dogGenTop.o(.debug_types+0x854): error: undefined reference to '.LLST376' dogGenTop.o(.debug_types+0x934): error: undefined reference to '.LLST381' dogGenTop.o(.debug_types+0xa10): error: undefined reference to '.LLST385' dogGenTop.o(.debug_types+0xd8f): error: undefined reference to '.LLST204' dogGenTop.o(.debug_types+0x5b6): error: undefined reference to '.LLST376' dogGenTop.o(.debug_types+0x696): error: undefined reference to '.LLST381' dogGenTop.o(.debug_types+0x772): error: undefined reference to '.LLST385' dogGenTop.o(.debug_types+0xae2): error: undefined reference to '.LLST204' dogGenTop.o(.debug_types+0x58f): error: undefined reference to '.LLST376' dogGenTop.o(.debug_types+0x66f): error: undefined reference to '.LLST381' dogGenTop.o(.debug_types+0x74b): error: undefined reference to '.LLST385' dogGenTop.o(.debug_types+0xabb): error: undefined reference to '.LLST204'
[Bug c++/53650] [4.7 Regression] large array causes huge memory use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53650 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #11 from Pawel Sikora pluto at agmk dot net 2013-01-22 21:05:45 UTC --- (In reply to comment #9) Author: jason Date: Tue Jan 22 16:28:58 2013 New Revision: 195380 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195380 Log: PR c++/53650 * call.c (type_has_extended_temps): New. * cp-tree.h: Declare it. * decl.c (check_initializer): Use build_aggr_init for arrays if it is false. * init.c (build_vec_init): Avoid mixed signed/unsigned arithmetic. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/array34.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/cp/cp-tree.h branches/gcc-4_7-branch/gcc/cp/decl.c branches/gcc-4_7-branch/gcc/cp/init.c this patch breaks bootstrap: ../../gcc/cp/call.c: In function 'type_has_extended_temps': ../../gcc/cp/call.c:8852:7: error: 'for' loop initial declarations are only allowed in C99 mode ../../gcc/cp/call.c:8852:7: note: use option -std=c99 or -std=gnu99 to compile your code
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #7 from Pawel Sikora pluto at agmk dot net 2013-01-18 18:23:27 UTC --- (In reply to comment #6) The fact that a data-race-free program cannot observe the non-atomicity of a 64-bit store, though true, is beside the point. The plain fact is that hardware registers (for which volatile was intended) really do care about the size of the store. A pair of 32-bit stores does not necessarily mean the same thing to hardware as does a single 64-bit store. Given that C is intended to be used for device drivers, volatile stores of reasonably-sized basic types must be atomic, and on 64-bit systems, reasonably-sized very clearly includes 64-bit stores. even 'movq' on x86-64 could be split into 32-bit transfers by mainboard h/w. devices connected to x86-64 should be aware of this! btw, iirc the x87-fpu load/store can give you atomic 64-bit transfer.
[Bug tree-optimization/55869] New: different bit shift/or optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55869
Bug #: 55869
Summary: different bit shift/or optimization.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
here're equvialent functions:
$ cat u.cpp
unsigned long long convert_1( bool flag )
{
return (unsigned long long)(flag ? 1ull : 0ull) 57;
}
unsigned long long convert_2( bool flag )
{
return (unsigned long long)flag 57;
}
current 4.7/4.8 gcc emits following different machine code:
_Z9convert_1b:
testb %dil, %dil # 29*cmpqi_ccno_1/1 [length = 3]
movl$0, %edx# 32*movdi_internal_rex64/1 [length = 5]
movabsq $144115188075855872, %rax # 28*movdi_internal_rex64/3
[length = 10]
cmove %rdx, %rax # 31*movdicc_noc/1 [length = 4]
ret # 39simple_return_internal [length = 1]
_Z9convert_2b:
movq%rdi, %rax # 19*movdi_internal_rex64/2 [length = 3]
salq$57, %rax # 8 *ashldi3_1/1[length = 4]
ret # 27simple_return_internal [length = 1]
while clang/llvm emits equivalent machine code for both functions:
_Z9convert_1b: # @_Z9convert_1b
movzbl %dil, %eax
shlq$57, %rax
ret
_Z9convert_2b: # @_Z9convert_2b
movzbl %dil, %eax
shlq$57, %rax
ret
[Bug debug/49532] Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, or 4) [in module D:\mingw.tests\l.dll]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49532 --- Comment #3 from Pawel Sikora pluto at agmk dot net 2012-12-20 20:05:17 UTC --- (In reply to comment #2) This issue was in fact a binutils problem. This issue is fixed. Therefore I close this bug as invalid. could you tell which binutils release fixes this issue?
[Bug tree-optimization/55738] New: missed memory store optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55738 Bug #: 55738 Summary: missed memory store optimization. Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Created attachment 29006 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29006 testcase please consider attached testcase and look into NetsValue::set asm code. one of the result isn't optimal (2 memory stores).
[Bug c++/55513] [4.7/4.8 Regression] Incorrect snprintf folding when building with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55513 --- Comment #12 from Pawel Sikora pluto at agmk dot net 2012-12-12 09:57:32 UTC --- (In reply to comment #11) Fixed in trunk. no backport to 4.7 branch?
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #4 from Pawel Sikora pluto at agmk dot net 2012-11-18 19:46:59 UTC --- looks like PR55171
[Bug libstdc++/55363] New: tuple_size is not a class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55363 Bug #: 55363 Summary: tuple_size is not a class template Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net gcc configured with --enable-symvers=gnu-versioned-namespace doesn't build. tested on git revision a4c4abc (svn trunk 193583). (...) libtool: compile: /home/users/pluto/src/gcc.builddir/./gcc/xgcc -shared-libgcc -B/home/users/pluto/src/gcc.builddir/./gcc -nostdinc++ -L/home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/opt/gcc48/x86_64-unknown-linux-gnu/bin/ -B/opt/gcc48/x86_64-unknown-linux-gnu/lib/ -isystem /opt/gcc48/x86_64-unknown-linux-gnu/include -isystem /opt/gcc48/x86_64-unknown-linux-gnu/sys-include -I/home/users/pluto/src/gcc.git/libstdc++-v3/../libgcc -I/home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/users/pluto/src/gcc.git/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=condition_variable.lo -O1 -gdwarf-4 -g1 -fno-debug-types-section -pipe -O1 -gdwarf-4 -g1 -fno-debug-types-section -pipe -c /home/users/pluto/src/gcc.git/libstdc++-v3/src/c++11/condition_variable.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o condition_variable.o In file included from /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:39:0, from /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/mutex:38, from /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/condition_variable:39, from /home/users/pluto/src/gcc.git/libstdc++-v3/src/c++11/condition_variable.cc:25: /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/array:273:12: error: 'tuple_size' is not a class template struct tuple_sizearray_Tp, _Nm ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/array:273:37: error: redeclared with 2 template parameters struct tuple_sizearray_Tp, _Nm ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/array:270:11: note: previous declaration 'templateclass _Tp class std::tuple_size' used 1 template parameter class tuple_size; ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/array:281:12: error: 'tuple_element' is not a class template struct tuple_element_Int, array_Tp, _Nm ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/array:281:46: error: redeclared with 3 template parameters struct tuple_element_Int, array_Tp, _Nm ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/array:278:11: note: previous declaration 'templatelong unsigned int _Int, class _Tp class std::tuple_element' used 2 template parameters class tuple_element; ^ In file included from /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/mutex:38:0, from /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/condition_variable:39, from /home/users/pluto/src/gcc.git/libstdc++-v3/src/c++11/condition_variable.cc:25: /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:917:49: error: template argument 2 is invalid typename std::tuple_element_Idx, _Tuple::type, _Tuple, _Nm::__type ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:917:63: error: template argument 2 is invalid typename std::tuple_element_Idx, _Tuple::type, _Tuple, _Nm::__type ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:930:62: error: template argument 4 is invalid std::tuple_size_Tuple::value ^ /home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libstdc++-v3/include/tuple:986:51: error: template argument 1 is invalid typename std::remove_reference_Tp::type::value::__type __type;
[Bug c/55040] dereferencing type-punned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55040 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-10-23 18:40:45 UTC --- looks like a dup of PR52609
[Bug other/54671] [4.7/4.8 Regression] gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2012-09-25 19:23:15 UTC --- (In reply to comment #2) I think this is a user bug. If gcc is configured against binutils that support conversion of ctors into init_array, then it will assume it, obviously you can't use --no-ctors-in-init-array then, you'd need to configure gcc not to assume it. Why do you need to use that option (actually, I wonder why the linker has that option at all)? e.g. i'd like to build an application for an old enterprise distro (which doesn't support init/fini arrays) on my brand new distro. -Wl,--no-ctors-in-init-array works perfectly fine in this case.
[Bug c++/54548] New: unclear error message for ambiguous type lookup.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54548
Bug #: 54548
Summary: unclear error message for ambiguous type lookup.
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
#include new
struct X;
namespace { struct X; }
int main()
{
new X();
}
a gcc error message is unreadable for end-user in case when
the first 'struct X' decl is hidden deeply in the #include forest.
$ LANG=C g++ -Wall t.cpp -c
t.cpp: In function 'int main()':
t.cpp:6:6: error: expected type-specifier before 'X'
t.cpp:6:6: error: expected ';' before 'X'
clang is more user-friendly and shows problem directly.
$ LANG=C clang++ -Wall t.cpp -c
t.cpp:6:6: error: reference to 'X' is ambiguous
new X();
^
t.cpp:2:8: note: candidate found by name lookup is 'X'
struct X;
^
t.cpp:3:20: note: candidate found by name lookup is 'anonymous namespace::X'
namespace { struct X; }
^
t.cpp:6:6: error: allocation of incomplete type 'X'
new X();
^
t.cpp:2:8: note: forward declaration of 'X'
struct X;
^
2 errors generated.
[Bug libstdc++/54173] New: -D_GLIBCXX_DEBUG breaks string::_Rep::_S_empty_rep_storage weak binding.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54173 Bug #: 54173 Summary: -D_GLIBCXX_DEBUG breaks string::_Rep::_S_empty_rep_storage weak binding. Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Created attachment 27937 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27937 testcase hi, afaics, the libstdc++ debug machinery breaks some (at least static weak) symbols binding which causes various runtime problems. here's the testcase: /* good */ $ LANG=C make g++ -Wall l.cpp -fPIC -shared -o l.so -g0 -s -O1 -Wl,--version-script=l.lds -std=gnu++11 readelf -sW l.so | grep storage 10: 0 OBJECT UNIQUE DEFAULT UND _ZNSs4_Rep20_S_empty_rep_storageE@GLIBCXX_3.4 (2) /* bad */ $ LANG=C make CPPFLAGS=-D_GLIBCXX_DEBUG g++ -Wall l.cpp -fPIC -shared -o l.so -g0 -s -O1 -Wl,--version-script=l.lds -std=gnu++11 -D_GLIBCXX_DEBUG readelf -sW l.so | grep storage make: *** [all] Error 1
[Bug libstdc++/54173] -D_GLIBCXX_DEBUG breaks string::_Rep::_S_empty_rep_storage weak binding.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54173 --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-08-04 16:13:03 UTC --- (In reply to comment #1) For sure, nothing changed in this area for years and years, thus must be a compiler issue. Please try to figure when it started... i have similar effects for 4.5/4.6/4.7/4.8 with my .lds script. afaics in the assembly code, the non-debug (good) version only references external _S_empty_rep_storage symbol while the debug (broken) version defines the _S_empty_rep_storage symbol as weak/gnu-unique.
[Bug c++/54053] New: g++ accepts (invalid?) 0; expression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54053
Bug #: 54053
Summary: g++ accepts (invalid?) 0; expression.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
g++ -std=c++11 compiles following code w/o errors.
#include iostream
int main()
{
std::cout 0;
}
while comeau/clang reports syntax error:
t.cpp:5:17: error: expected ';' after expression
std::cout 0;
^
;
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-07-16 19:03:27 UTC --- (In reply to comment #1) (Fixed the component) I can't reproduce this. I can print wordMapBitset before it is initialized but I get a different error: (gdb) p wordBitsetMap $4 = std::map with 140737488349518 elementsCannot access memory at address 0x68732f6c61636f7c in line 15 the wordBitsetMap reference is initialized. (gdb) p wordBitsetMap $3 = Python Exception type 'exceptions.IndexError' list index out of range: std::map with 1 elements ^^^ this is true. What version of gdb are you using? gdb from git 7.4/master branch. Can you do it with stack-printing enabled? (set python print-stack on in recent versions, somewhere under maint in older ones.) This might help. (gdb) set python print-stack full (gdb) p wordBitsetMap $6 = std::map with 1 elementsTraceback (most recent call last): File /opt/gcc47/share/gcc-4.7.2/python/libstdcxx/v6/printers.py, line 427, in children rep_type = find_type(self.val.type, '_Rep_type') File /opt/gcc47/share/gcc-4.7.2/python/libstdcxx/v6/printers.py, line 43, in find_type field = typ.fields()[0] IndexError: list index out of range
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-06-14 20:06:15 UTC --- (In reply to comment #0) Can we have a magic weak symbol output by G++ into compilands saying what -std setting was used? For example: No -std outputs __gplusplus_std_cpluscplus98 -std=c++03 outputs __gplusplus_std_cplusplus03 -std=gnu++03 outputs __gplusplus_std_gnu03 -std=c++11 outputs __gplusplus_std_cplusplus11 -std=gnu++11 outputs __gplusplus_std_gnu11 ... and so on ... Why? Because right now it's too easy to accidentally link object files compiled with 98 with those compiled with 11 and not then know why things spontaneously fail: http://gcc.gnu.org/ml/gcc/2012-06/msg00201.html http://gcc.gnu.org/wiki/Cxx11AbiCompatibility If __gplusplus_std_cpluscplus98 and __gplusplus_std_cplusplus11 both turn up in a shared object or executable, then we know we have combined 98 and 11 built code. Indeed, a future ld could warn if this happens. Niall you can use -frecord-gcc-switches to detect mixed objects in linked library.
[Bug other/53598] New: missed diagnostics / equality comparison result unused.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53598
Bug #: 53598
Summary: missed diagnostics / equality comparison result
unused.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
i've found in my codebase a hidden typo bug.
#include list
void foo( std::listint::const_iterator i, std::listint const l )
{
if ( ++i == l.end() )
i == l.begin(); === here
}
g++ with -Wall -Wextra doesn't warn about this while clang++ wins:
noop-if.cpp:5:5: warning: equality comparison result unused
[-Wunused-comparison]
i == l.begin();
~~^~~~
noop-if.cpp:5:5: note: use '=' to turn this equality comparison into an
assignment
i == l.begin();
^~
=
1 warning generated.
[Bug libstdc++/53477] New: pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
Bug #: 53477
Summary: pretty printer fails with: Python Exception type
'exceptions.IndexError' list index out of range
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
Created attachment 27490
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27490
testcase
$ x86_64-gnu-linux-g++ t.cpp -Wall -o t -g2 -gdwarf-4
$ cgdb ./t
in line 15 pretty printer fails with error.
7│ int main()
8│ {
9│ icapSelection_[ /* frame */ 7 ][ /* word */ 3 ].insert( 5 );
10│ icapSelection_[ /* frame */ 7 ][ /* word */ 3 ].insert( 1 );
11│ for ( IcapSelection::const_iterator i = icapSelection_.begin(); i
!= icapSelection_.end(); ++i )
12│ {
13│ IcapSelection::key_type frame( i-first );
14│ IcapSelection::mapped_type const wordBitsetMap( i-second
);
15├─── for ( IcapSelection::mapped_type::const_iterator j =
wordBitsetMap.begin(); j != wordBitsetMap.end(); ++j )
16│ {
17│ IcapSelection::mapped_type::key_type word( j-first
);
18│ IcapSelection::mapped_type::mapped_type const
bits( j-second );
19│ for (
IcapSelection::mapped_type::mapped_type::const_iterator k = bits.begin(); k !=
bits.end(); ++k )
20│ {
21│ unsigned bit( *k );
22│ }
23│ }
24│ }
25│ }
/home/users/pawels/dvm.git/t.cpp
Breakpoint 1, main () at t.cpp:9
(gdb) n
(gdb)
(gdb) p icapSelection_
$1 = std::map with 1 elements = {
[7] = std::map with 1 elements = {
[3] = std::set with 2 elements = {
[0] = 1,
[1] = 5
}
}
}
(gdb) n
(gdb)
(gdb)
(gdb) p wordBitsetMap
$2 = Python Exception type 'exceptions.IndexError' list index out of range:
std::map with 1 elements
[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 --- Comment #9 from Pawel Sikora pluto at agmk dot net 2012-05-23 08:41:17 UTC --- (In reply to comment #8) I tried it with --enable-languages=all ? libssp and others *silently* disable gnu versioning when you pass --enable-symvers=gnu-versioned-namespace. they only accepts yes/no value for this option.
[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 --- Comment #7 from Pawel Sikora pluto at agmk dot net 2012-05-21 19:13:34 UTC --- (In reply to comment #6) Fixed on trunk and branch what about other target libs? (gfortran,quadmath,ssp)
[Bug debug/49162] ICE in in output_die, at dwarf2out.c:10568 with -femit-struct-debug-reduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49162 --- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-05-12 10:26:56 UTC --- could someone confirm this finally and set target milestone to 4.5.4? i'd like to drop this old problem from 'my bugs' list with 4.5 termination.
[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||bkoz at redhat dot com, ||paolo.carlini at oracle dot ||com --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-05-12 11:15:49 UTC --- Paolo, Benjamin, could you look at this issue?
[Bug tree-optimization/50847] missed diagnostics for dead code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||lopezibanez at gmail dot ||com --- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-05-12 11:35:07 UTC --- Manuel, could you improve gcc diagnostics in this area?
[Bug tree-optimization/50847] missed warning about unreachable code after throw statment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847 --- Comment #3 from Pawel Sikora pluto at agmk dot net 2012-05-12 12:07:06 UTC --- (In reply to comment #2) Related to PR46476? similar (return vs. throw statment).
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #8 from Pawel Sikora pluto at agmk dot net 2012-05-08 07:54:18 UTC --- (In reply to comment #7) Good, good, thanks Francois, anybody willing to benchmark the more limited change? changing __glibcxx_check_heap_*pred* reduces timings for me from ~3.25 sec to 0.18sec (for 1 items in pqueue). tested on on intel core-i3-540 with: x86_64-gnu-linux-g++ pq.C -o pq -g2 -static -D_GLIBCXX_DEBUG -O2
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #5 from Pawel Sikora pluto at agmk dot net 2012-05-07 13:34:43 UTC --- callgrind shows that n*10e3 of pq.push() generates m*10e6 (mn) _M_can_advance() calls and growing fast :)
[Bug bootstrap/53188] New: libatomic error: Please use exactly Autoconf 2.64 instead of 2.69
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53188
Bug #: 53188
Summary: libatomic error: Please use exactly Autoconf 2.64
instead of 2.69
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
fresh autobuild fails with:
(...)
make[2]: Entering directory
`/home/users/pluto/src/gcc.builddir/x86_64-unknown-linux-gnu/libatomic'
CDPATH=${ZSH_VERSION+.}: cd /home/users/pluto/src/gcc.git/libatomic
/bin/sh /home/users/pluto/src/gcc.git/missing --run aclocal-1.11 -I .. -I
../config
configure.ac:26: error: Please use exactly Autoconf 2.64 instead of 2.69.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:26: the top level
autom4te: m4 failed with exit status: 1
aclocal-1.11: autom4te failed with exit status: 1
make[2]: *** [/home/users/pluto/src/gcc.git/libatomic/aclocal.m4] Error 1
6db1d2ca83f9327020b75f6c1610649bb18e71db is the first bad commit
commit 6db1d2ca83f9327020b75f6c1610649bb18e71db
Author: rth rth@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Tue May 1 15:48:28 2012 +
Add libatomic as a target library.
[Bug c++/53068] collect2 breaks link order control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #7 from Pawel Sikora pluto at agmk dot net 2012-04-22 07:54:34 UTC --- (In reply to comment #3) Wow - this will break a lot of big users - we are far from the only ones who find priorities unusable. BTAIM, it appears that our choice is to use an option (there is one? what?) to force 4.7 to continue to use ctors, or to use some other option (there is one? what?) to force 4.7 to process init_array in reverse order from what it does by default. Of these two, which do you recommend as a workaround? Are there any other choices? you can use gold linker. it have nice options: $ ld.gold --help|grep ctors --ctors-in-init-array Use DT_INIT_ARRAY for all constructors (default) --no-ctors-in-init-arrayHandle constructors as directed by compiler
[Bug debug/45088] pointer type information lost in debuginfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45088 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #10 from Pawel Sikora pluto at agmk dot net 2012-04-19 08:07:28 UTC --- what about 4.7 branch?
[Bug libstdc++/52950] --enable-symvers=gnu-versioned-namespace exports symbol twice.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52950 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-04-13 08:43:24 UTC --- not a gcc bug (problem was in custom new/delete tracing).
[Bug libstdc++/52950] New: --enable-symvers=gnu-versioned-namespace exports symbol twice.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52950 Bug #: 52950 Summary: --enable-symvers=gnu-versioned-namespace exports symbol twice. Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net for the cross gcc build, the libstdc++.so.7 export symbols twice. with and without versioning, e.g.: $ readelf -sW (cross).../libstdc++.so.7 |grep Znwm 922: 00075610 144 FUNCGLOBAL DEFAULT 12 _Znwm@@GLIBCXX_7.0 2742: 000756a0 120 FUNCGLOBAL DEFAULT 12 _ZnwmRKSt9nothrow_t@@GLIBCXX_7.0 1170: 000756a0 120 FUNCGLOBAL DEFAULT 12 _ZnwmRKSt9nothrow_t 1171: 00075610 144 FUNCGLOBAL DEFAULT 12 _Znwm the native gcc build exports symbols correctly. $ readelf -sW /usr/lib64/libstdc++.so.7.0.0|grep Znwm 332: 00069820 120 FUNCGLOBAL DEFAULT 12 _ZnwmRKSt9nothrow_t@@GLIBCXX_7.0 3124: 00069790 144 FUNCGLOBAL DEFAULT 12 _Znwm@@GLIBCXX_7.0 $ (cross) x86_64-gnu-linux-g++ -v Using built-in specs. COLLECT_GCC=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ COLLECT_LTO_WRAPPER=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64/gcc/x86_64-gnu-linux/4.7.1/lto-wrapper Target: x86_64-gnu-linux Configured with: ../configure --target=x86_64-gnu-linux --with-arch=x86-64 --prefix=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux --with-sysroot=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux --libdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64 --libexecdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64 --with-slibdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64 --with-gmp-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include --with-gmp-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpfr-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include --with-mpfr-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpc-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include --with-mpc-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib --disable-multilib --enable-nls --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libitm --enable-tls --enable-libstdcxx-allocator=new --enable-extern-template --enable-libstdcxx-time=rt --enable-libstdcxx-threads --disable-libstdcxx-pch --disable-lto --disable-plugin --enable-c99 --enable-long-long --enable-linux-futex --enable-threads=posix --enable-shared --with-pic --enable-gold --enable-__cxa_atexit --enable-languages=c,c++ --enable-checking=release --enable-symvers=gnu-versioned-namespace --with-long-double-128 --disable-cld --disable-bootstrap Thread model: posix gcc version 4.7.1 20120406 (prerelease) (GCC)
[Bug bootstrap/25672] [4.5 Regression] cross build's libgcc picks up CFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672 --- Comment #31 from Pawel Sikora pluto at agmk dot net 2012-03-27 18:39:37 UTC --- (In reply to comment #30) Does this bug prevail in GCC 4.6.x, 4.7.x and/or trunk? i've configured 4.7.0-RC2 for sparc64 target on x86_64 host with: CFLAGS=-O1 -g0 -march=corei7-avx ./configure and the build fails in libgcc as usual: (...) checking for sparc64-gnu-linux-gcc... /home/users/pluto/toolchain/trunk/sparc64-gnu-linux/gcc-4.7.0-RC-20120314/BUILDDIR/./gcc/xgcc -B/home/users/pluto/toolchain/trunk/sparc64-gnu-linux/gcc-4.7.0-RC-20120314/BUILDDIR/./gcc/ -B/opt/gcc47-sparc64/sparc64-gnu-linux/bin/ -B/opt/gcc47-sparc64/sparc64-gnu-linux/lib/ -isystem /opt/gcc47-sparc64/sparc64-gnu-linux/include -isystem /opt/gcc47-sparc64/sparc64-gnu-linux/sys-include checking for suffix of object files... configure: error: in `/home/users/pluto/toolchain/trunk/sparc64-gnu-linux/gcc-4.7.0-RC-20120314/BUILDDIR/sparc64-gnu-linux/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make: *** [configure-target-libgcc] Error 1 config.log says: xgcc: error: unrecognized command line option '-march=corei7-avx' so, the toplevel CFLAGS are pulled into target cflags.
[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700
Pawel Sikora pluto at agmk dot net changed:
What|Removed |Added
Summary|libjava configure fails on |lib* configure fails on
|--enable-symvers=gnu-versio |--enable-symvers=gnu-versio
|ned-namespace. |ned-namespace.
--- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-03-25 10:24:18
UTC ---
the same problem exists in libssp, libgfotran and others. they silently disable
symbol versioning in case of non-{yes/no} versioning value.
[Bug bootstrap/52700] New: libjava configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 Bug #: 52700 Summary: libjava configure fails on --enable-symvers=gnu-versioned-namespace. Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Host: x86_64-gnu-linux Target: x86_64-gnu-linux Build: x86_64-gnu-linux the 4.7.1 boostrap fails inside libjava on --enable-symvers=gnu-versioned-namespace option. (...) checking whether ld supports anonymous version scripts... configure: error: Unknown argument to enable/disable symvers make[1]: *** [configure-target-libjava] Error 1 afaics it accepts only yes/no values: # See if linker supports anonymous version scripts. AC_CACHE_CHECK([whether ld supports anonymous version scripts], [libjava_cv_anon_version_script], [AC_ARG_ENABLE(symvers, AS_HELP_STRING([--disable-symvers], [disable symbol versioning for libjava]), [case $enableval in yes) libjava_cv_anon_version_script=yes ;; no) libjava_cv_anon_version_script=no ;; *) AC_MSG_ERROR([Unknown argument to enable/disable symvers]);; esac], [libjava_cv_anon_version_script=yes] )
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Pawel Sikora pluto at agmk dot net 2012-03-22 22:17:46 UTC --- ok, the original isse (gnu-versioned-namespace.ver) is fixed for 4.7.0. the secondary issue (--disable-nls vs. export table [PR52514]) is invalid, so i'm closing this PR as fixed for 4.7.0.
[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Pawel Sikora pluto at agmk dot net 2012-03-22 22:19:08 UTC --- ok, 4.7.0 is out. closing as fixed (not a regression).
[Bug target/51907] SIGSEGV in _Unwind_GetIP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51907 --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-03-22 22:32:44 UTC --- (In reply to comment #1) Confirmed. It happens for 32-bit and 64-bit targets any progress?
[Bug other/52609] -Wstrict-aliasing / missed diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52609
--- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-03-18 09:32:03
UTC ---
(In reply to comment #1)
accessing unsigned* via float* looks buggy
It does not have to be if the original argument was originally of type float.
Aliasing is not about type of pointers but the type which is used to access
and
such.
ok, here's an updated testcase:
$ cat alias-bug.c
unsigned buffer[1];
float bug1( unsigned u )
{
buffer[0]=u;
return *(float*)(buffer[0]); // warning.
}
float bug2( unsigned u )
{
buffer[0]=u;
float* ptr=(float*)buffer[0];
return *ptr; // missed strict aliasing warning.
}
gcc repots warning only for bug1() and misses warning for bug2():
$ gcc -Wall -Wstrict-aliasing=3 -O2 alias-bug.c -c
alias-bug.c: In function 'bug1':
alias-bug.c:6:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
[Bug other/52609] New: -Wstrict-aliasing / missed diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52609
Bug #: 52609
Summary: -Wstrict-aliasing / missed diagnostics
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
Target: x86_64-gnu-linux
void bug1( unsigned* buffer, int index, float w )
{
*(float*)(buffer[index])=w;
}
void bug2( unsigned* buffer, int index, float w )
{
float* ptr=(float*)buffer[index];
*ptr=w;
}
accessing unsigned* via float* looks buggy but
$ gcc48 -Wall -Wstrict-aliasing=3 -Wextra -fstrict-aliasing -O2 -S alias-bug.c
reports no warnings.
[Bug libstdc++/52514] --disable-nls changes libstdc++-7.dll export table.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52514 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-03-17 12:30:36 UTC --- this was a side-effect of broken c++config.h (see PR52540) between builds.
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #15 from Pawel Sikora pluto at agmk dot net 2012-03-16 10:27:53 UTC --- (In reply to comment #14) Now, if something got broken lately, like those sed, I have no idea, certainly I didn't change that. But, please post and discuss the issue and tentative fixes on the libstdc++ mailing list, not here. ok, sent: http://gcc.gnu.org/ml/libstdc++/2012-03/msg00103.html
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #12 from Pawel Sikora pluto at agmk dot net 2012-03-15 15:49:09 UTC --- hmm, i see something weird. in source tree the c++config.h contains: # undef _GLIBCXX_EXTERN_TEMPLATE # define _GLIBCXX_EXTERN_TEMPLATE -1 but after make-install the c++config.h contains: # undef _GLIBCXX_EXTERN_TEMPLATE # define _GLIBCXX_EXTERN_TEMPLATE 1 -1
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #13 from Pawel Sikora pluto at agmk dot net 2012-03-15 16:36:33 UTC --- Created attachment 26899 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26899 don't touch with sed the _GLIBCXX_EXTERN_TEMPLATE redefiniton.
[Bug lto/43377] lto decreases C++ stacktrace readability (debuginfo pubnames).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43377 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Pawel Sikora pluto at agmk dot net 2012-03-15 20:21:13 UTC --- seems to be fixed on 4.6+
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #11 from Pawel Sikora pluto at agmk dot net 2012-03-11 19:49:41 UTC --- (In reply to comment #9) Then this is a very old issue, isn't it? Why nobody noticed it before? To be clear, in debug-mode we don't use extern templates only for basic_string (because _GLIBCXX_EXTERN_TEMPLATE becomes -1 when _GLIBCXX_DEBUG is defined), all the other facilities remain the same still use extern tamplate. This is in order to enable debug-mode checks also at -O0 for basic_string. Now, I don't see why a few less extern template can make a difference on mingw in terms of correctness of use_facet or anything else, but if that's really the case due to fundamental limitations somehwhere, we can trade it for the -O0 basic_string checks on the affected systems, I have no problems with that (note that, AFAICS, the problem will not go away with a new C++11 conforming string class, unless we decide to not export from the .so parts of basic_string) i'm not sure the problem is in std::string details. in the debug-mode the use_facet is no more extern template and instantiates in client code, especially the static facet's field like std::locale::id. is this 'id' and other static details correctly initialized in (non-extern-template) debug-mode?
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #7 from Pawel Sikora pluto at agmk dot net 2012-03-10 13:14:18 UTC --- Created attachment 26871 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26871 testcase
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #8 from Pawel Sikora pluto at agmk dot net 2012-03-10 13:16:45 UTC --- i've compared the .ii files with and without _GLIBCXX_DEBUG definition. the debug version doesn't contain 'extern template (...)' for some classes. i suppose there're odr violations (global locale objects?) in debug mode. it may work on linux due to elf's weak binding feature but explicit dllimport/export exposes problem on windows.
[Bug libstdc++/52540] New: std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540
Bug #: 52540
Summary: std::use_facet throws bad_cast when compiled with
_GLIBCXX_DEBUG
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
Target: x86_64-w64-mingw32
#include iostream
#include locale
#include cstring
#include ctime
int main()
{
std::tm tm;
std::time_t tt;
std::time( tt );
tm = *std::localtime( tt );
std::locale lc( C );
std::cout.imbue( lc );
std::time_put char const timeFacet = std::use_facet std::time_put
char ( std::cout.getloc() );
char const pattern[] = %x %X;
timeFacet.put( std::cout, std::cout, std::cout.fill(), tm, pattern,
pattern + std::strlen( pattern ) );
}
$ x86_64-w64-mingw32-g++ main.cpp -o main-release.exe -g2
$ x86_64-w64-mingw32-g++ main.cpp -o main-debug.exe -g2 -D_GLIBCXX_DEBUG
release-run:
Starting program: main-release.exe
[New Thread 2776.0xdbc]
Breakpoint 1, main () at main.cpp:7
7 {
(gdb) n
10 std::time( tt );
(gdb)
11 tm = *std::localtime( tt );
(gdb)
12 std::locale lc( C );
(gdb)
13 std::cout.imbue( lc );
(gdb) p lc
$2 = {static none = 0, static ctype = 1, static numeric = 2, static collate =
4, static time = 8, static monetary = 16,
static messages = 32, static all = 63, _M_impl = 0x626e9460, static
_S_classic = 0x626e9460, static _S_global = 0x626e9460,
static _S_categories = 0x626eadc0, static _S_once = {done = 1, started = 0}}
(gdb) c
Continuing.
03/09/12 11:53:50
Program exited normally.
debug-run:
Starting program: main-debug.exe
[New Thread 2704.0xd4c]
Breakpoint 1, main () at main.cpp:7
7 {
(gdb) l
2 #include locale
3 #include cstring
4 #include ctime
5
6 int main()
7 {
8 std::tm tm;
9 std::time_t tt;
10 std::time( tt );
11 tm = *std::localtime( tt );
(gdb) n
10 std::time( tt );
(gdb)
11 tm = *std::localtime( tt );
(gdb)
12 std::locale lc( C );
(gdb)
13 std::cout.imbue( lc );
(gdb) p lc
$1 = {static none = 0, static ctype = 1, static numeric = 2, static collate =
4, static time = 8, static monetary = 16,
static messages = 32, static all = 63, _M_impl = 0x626e9460, static
_S_classic = 0x626e9460, static _S_global = 0x626e9460,
static _S_categories = 0x626eadc0, static _S_once = {done = 1, started = 0}}
(gdb) n
14 std::time_put char const timeFacet = std::use_facet
std::time_put char ( std::cout.getloc() );
(gdb)
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID | --- Comment #14 from Pawel Sikora pluto at agmk dot net 2012-03-06 18:36:06 UTC --- (In reply to comment #13) Hmm, this looks to me like an boost-issue and seems to me not being related to gcc itself. The cause might be that symbol-mangling has changed and boost doesn't specifies it on its export-table? I will close this bug as invalid. 1). please don't close this issue as invalid - orignal topic is fixed on 4.7. will it be backported to 4.6? (i have an adjusted patch). 2). i've found the core issue for problem mentioned in comment 12. the --disable-nls configure option causes missing x64 .dll exports but this is imho a bug (libstdc++ headers allow boost to use locale support but linking fails later). i've --enabled-nls and it works fine.
[Bug libstdc++/52514] New: --disable-nls changes libstdc++-7.dll export table.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52514 Bug #: 52514 Summary: --disable-nls changes libstdc++-7.dll export table. Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Target: x86_64-w64-mingw32 Build: x86_64-gnu-linux hi, configuring gcc-4.6 with --disable-nls for x86_64-w64-mingw32 target changes the libstdc++-7.dll exports. here's the diff: --- nls-enabled.txt 2012-03-06 09:25:36.450096471 +0100 +++ nls-disabled.txt 2012-03-06 09:25:05.493428971 +0100 @@ -62,39 +62,6 @@ _ZN11__gnu_debug19_Safe_sequence_base18_M_detach_singularEv _ZN11__gnu_debug19_Safe_sequence_base22_M_revalidate_singularEv _ZN11__gnu_debug19_Safe_sequence_base7_M_swapERS0_ - _ZN9__gnu_cxx3__712__atomic_addEPVii - _ZN9__gnu_cxx3__717__pool_alloc_base12_M_get_mutexEv - _ZN9__gnu_cxx3__717__pool_alloc_base16_M_get_free_listEy - _ZN9__gnu_cxx3__717__pool_alloc_base9_M_refillEy - _ZN9__gnu_cxx3__718__exchange_and_addEPVii - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE5uflowEv - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE6xsgetnEPcx - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE6xsputnEPKcx - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE7seekoffExNS2_12_Ios_SeekdirENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE7seekposENS2_4fposIiEENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE8overflowEi - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE9pbackfailEi - _ZN9__gnu_cxx3__718stdio_sync_filebufIcNSt3__711char_traitsIcEEE9underflowEv - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE5uflowEv - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE6xsgetnEPwx - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE6xsputnEPKwx - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE7seekoffExNS2_12_Ios_SeekdirENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE7seekposENS2_4fposIiEENS2_13_Ios_OpenmodeE - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE8overflowEt - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE9pbackfailEt - _ZN9__gnu_cxx3__718stdio_sync_filebufIwNSt3__711char_traitsIwEEE9underflowEv - _ZN9__gnu_cxx3__727__verbose_terminate_handlerEv - _ZN9__gnu_cxx3__76__poolILb0EE10_M_destroyEv - _ZN9__gnu_cxx3__76__poolILb0EE13_M_initializeEv - _ZN9__gnu_cxx3__76__poolILb0EE16_M_reclaim_blockEPcy - _ZN9__gnu_cxx3__76__poolILb0EE16_M_reserve_blockEyy - _ZN9__gnu_cxx3__76__poolILb1EE10_M_destroyEv - _ZN9__gnu_cxx3__76__poolILb1EE13_M_initializeEv - _ZN9__gnu_cxx3__76__poolILb1EE16_M_get_thread_idEv - _ZN9__gnu_cxx3__76__poolILb1EE16_M_reclaim_blockEPcy - _ZN9__gnu_cxx3__76__poolILb1EE16_M_reserve_blockEyy - _ZN9__gnu_cxx3__79free_list6_M_getEy - _ZN9__gnu_cxx3__79free_list8_M_clearEv _ZNK10__cxxabiv117__class_type_info10__do_catchEPKSt9type_infoPPvj _ZNK10__cxxabiv117__class_type_info11__do_upcastEPKS0_PKvRNS0_15__upcast_resultE _ZNK10__cxxabiv117__class_type_info11__do_upcastEPKS0_PPv @@ -1524,9 +1491,6 @@ _ZNSt3__713runtime_errorD0Ev _ZNSt3__713runtime_errorD1Ev _ZNSt3__713runtime_errorD2Ev - _ZNSt3__714__convert_to_vIdEEvPKcRT_RNS_12_Ios_IostateERKPi - _ZNSt3__714__convert_to_vIeEEvPKcRT_RNS_12_Ios_IostateERKPi - _ZNSt3__714__convert_to_vIfEEvPKcRT_RNS_12_Ios_IostateERKPi _ZNSt3__714basic_ifstreamIcNS_11char_traitsIcEEE4openEPKcNS_13_Ios_OpenmodeE _ZNSt3__714basic_ifstreamIcNS_11char_traitsIcEEE4openERKNS_12basic_stringIcS2_NS_9allocatorIcNS_13_Ios_OpenmodeE _ZNSt3__714basic_ifstreamIcNS_11char_traitsIcEEE5closeEv @@ -2225,8 +2189,6 @@ _ZNSt3__716invalid_argumentD0Ev _ZNSt3__716invalid_argumentD1Ev _ZNSt3__716invalid_argumentD2Ev - _ZNSt3__717__copy_streambufsIcNS_11char_traitsIcxPNS_15basic_streambufIT_T0_EES7_ - _ZNSt3__717__copy_streambufsIwNS_11char_traitsIwxPNS_15basic_streambufIT_T0_EES7_ _ZNSt3__717__gslice_to_indexEyRKNS_8valarrayIyEES3_RS1_ _ZNSt3__717__throw_bad_allocEv _ZNSt3__717__timepunct_cacheIcE12_S_timezonesE @@ -2358,8 +2320,6 @@ _ZNSt3__720__throw_out_of_rangeEPKc _ZNSt3__720__throw_system_errorEi _ZNSt3__721_Rb_tree_rotate_rightEPNS_18_Rb_tree_node_baseERS1_ - _ZNSt3__721__copy_streambufs_eofIcNS_11char_traitsIcxPNS_15basic_streambufIT_T0_EES7_Rb - _ZNSt3__721__copy_streambufs_eofIwNS_11char_traitsIwxPNS_15basic_streambufIT_T0_EES7_Rb _ZNSt3__721__ctype_abstract_baseIcED0Ev _ZNSt3__721__ctype_abstract_baseIcED1Ev _ZNSt3__721__ctype_abstract_baseIwED0Ev @@ -2741,32 +2701,6 @@ _ZNSt3__79basic_iosIwNS_11char_traitsIwEEED0Ev _ZNSt3__79basic_iosIwNS_11char_traitsIwEEED1Ev
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #17 from Pawel Sikora pluto at agmk dot net 2012-03-06 21:04:40 UTC --- (In reply to comment #15) (In reply to comment #14) i've found the core issue for problem mentioned in comment 12. the --disable-nls configure option causes missing x64 .dll exports but this is imho a bug (libstdc++ headers allow boost to use locale support but linking fails later). i've --enabled-nls and it works fine. This is why we ask for configure options in bug reports - you hadn't mentioned anything about --disable-nls I agree it's a bug if --disable-nls has any effect on libstdc++ exports. i've filled this issue as PR52514.
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #1 from Pawel Sikora pluto at agmk dot net 2012-03-04 13:54:09 UTC --- looks like .init_array vs. .ctors problem.
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-03-04 14:16:29 UTC --- you should specify explicit initialization order to avoid gpf, e.g.: static std::mapint, int m __attribute__((init_priority(101))); static void insert() __attribute__((constructor(102)));
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #12 from Pawel Sikora pluto at agmk dot net 2012-03-04 19:36:30 UTC --- with current 4.6.4 i've noticed a new undefined reference during boost_rexeg.dll linking: (...) Creating library file: bin.v2/libs/regex/build/gcc-mingw-4.6.4/release/inlining-on/target-os-windows/threadapi-win32/threading-multi/libboost_regex.dll.abin.v2/libs/regex/build/gcc-mingw-4.6.4/release/inlining-on/target-os-windows/threadapi-win32/threading-multi/cpp_regex_traits.o: In function `boost::re_detail::cpp_regex_traits_basechar::imbue(std::__7::locale const)': /home/users/pluto/buildenv/linux/x86_64-w64-mingw32/boost_1_49_0/./boost/regex/v4/cpp_regex_traits.hpp:216: undefined reference to `bool std::__7::has_facetstd::__7::messageschar (std::__7::locale const)' $ x86_64-w64-mingw32-objdump -t cpp_regex_traits.o|egrep '_ZN.+has_facet.+messages' [325](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x _ZNSt3__79has_facetINS_8messagesIcbRKNS_6localeE i see a has_facet in symbols table: $ x86_64-w64-mingw32-objdump -t libstdc++-7.dll|egrep '_ZN.+has_facet.+messages' [13096](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00093880 _ZNSt3__79has_facetINS_8messagesIcbRKNS_6localeE [21476](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x000938e0 _ZNSt3__79has_facetINS_8messagesIwbRKNS_6localeE but they aren't present in export-address-table. any ideas?
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 --- Comment #3 from Pawel Sikora pluto at agmk dot net 2012-02-16 23:10:34 UTC --- (In reply to comment #1) I am unable to reproduce this on F16, GNU ld version 2.21.53.0.1-6.fc16 20110716 Copyright 2011 Free Software Foundation, Inc. Can you give me some more information about your ld, and include any special flags used to get the warnings. Thanks. you need to use ld-gold for gcc build and configure gcc with --enable-symvers=gnu. the problem is in the libstdc++-v3/config/abi/pre/gnu.ver: grep shows duplicated lines: gnu.ver:_ZNKSs11_M_disjunctEPKc; gnu.ver:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw; gnu.ver:_ZNKSs11_M_disjunctEPKc; gnu.ver:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw; full build log attached.
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 --- Comment #2 from Pawel Sikora pluto at agmk dot net 2012-02-16 23:09:45 UTC --- Created attachment 26687 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26687 build log.
[Bug c++/52231] New: [missed optimization/diagnostics] address-of-reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52231
Bug #: 52231
Summary: [missed optimization/diagnostics] address-of-reference
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
int singleton();
void foo();
void bar()
{
int a = singleton();
int b = singleton();
if ( a == 0 ) == useless stmt (not diagnosed/not optimized)
foo();
a = 5;
if ( b != 5 )
foo();
}
in c++ the adress of refer
$ g++ 0.cpp -O2 -Wall -Wextra -fdump-tree-optimized -c cat
0.cpp.143t.optimized
void bar() ()
{
int D.2079;
int D.2078;
int D.2074;
bb 2:
D.2078_1 = singleton ();
D.2079_3 = singleton ();
if (D.2078_1 == 0B)
goto bb 3;
else
goto bb 4;
bb 3:
foo ();
bb 4:
*D.2078_1 = 5;
D.2074_5 = *D.2079_3;
if (D.2074_5 != 5)
goto bb 5;
else
goto bb 6;
bb 5:
foo (); [tail call]
bb 6:
return;
}
[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649 --- Comment #10 from Pawel Sikora pluto at agmk dot net 2012-02-04 11:26:24 UTC --- (In reply to comment #9) Author: tromey Date: Mon Jan 30 16:25:11 2012 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183732 could you backport this for 4.6 ?
[Bug target/51907] New: SIGSEGV in _Unwind_GetIP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51907
Bug #: 51907
Summary: SIGSEGV in _Unwind_GetIP
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
Target: x86_64-w64-mingw32
hi,
the following code compiled for x86_64-w64-mingw32 crashes inside libgcc:
#include cstdio
#include unwind.h
namespace backtracexx
{
_Unwind_Reason_Code helper( struct _Unwind_Context* ctx, void* )
{
std::printf( helper( ctx = %p ) = , (void*)ctx );
_Unwind_Ptr ip = _Unwind_GetIP( ctx );
std::printf( ip = %p\n, (void*)ip );
return _URC_NO_REASON;
}
void scan()
{
_Unwind_Backtrace( reinterpret_cast _Unwind_Trace_Fn ( helper
), 0 );
}
}
int main()
{
backtracexx::scan();
}
d:\testd:\mingw64\bin\x86_64-w64-mingw32-g++ example.cpp -g2 -o example.exe
d:\testd:\mingw64\bin\x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=d:\mingw64\bin\x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=d:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../build/gcc/src/configure --target=x86_64-w64-mingw32
--prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/bu
ild/build/root
--with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--enable-languages=all,obj-c++ --enable-fu
lly-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.7.0 20111220 (experimental) (GCC)
(gdb) r
Starting program: d:\test/example.exe
[New Thread 2448.0xaa8]
helper( ctx = 0022FDD0 ) =
Program received signal SIGSEGV, Segmentation fault.
0x6cecea63 in _Unwind_GetIP (context=0x22fdd0) at
../../../../../build/gcc/src/libgcc/unwind-sjlj.c:214
214 ../../../../../build/gcc/src/libgcc/unwind-sjlj.c: No such file or
directory.
in ../../../../../build/gcc/src/libgcc/unwind-sjlj.c
(gdb) bt
#0 0x6cecea63 in _Unwind_GetIP (context=0x22fdd0) at
../../../../../build/gcc/src/libgcc/unwind-sjlj.c:214
#1 0x00401529 in backtracexx::helper (ctx=0x22fdd0) at example.cpp:9
#2 0x6cecee55 in _Unwind_Backtrace (trace=0x401500
backtracexx::helper(_Unwind_Context*, void*),
trace_argument=0x0) at ../../../../../build/gcc/src/libgcc/unwind.inc:295
#3 0x00401564 in backtracexx::scan () at example.cpp:15
#4 0x0040157d in main () at example.cpp:21
[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649 --- Comment #5 from Pawel Sikora pluto at agmk dot net 2012-01-17 16:06:01 UTC --- (In reply to comment #3) Tom, I assume the plan for the libstdc++ python printers is to have a python/libstdcxx/v7/printers.py for the libstdc++.so.7 library, right? As we have that version today when using versioned namespaces (see PR 48698) do you think we should have that v7 file today? Or while the only difference between v6 and v7 is the nested inline namespace do you think just adding (__7::)? to the regexes for the v6 printers is better (at least for now)? i've another issue vith v7 and c++0x - std::list (gdb) p l $1 = std::__debug::list Traceback (most recent call last): File /usr/share/python2.7/site-packages/libstdcxx/v6/printers.py, line 78, in children RuntimeError: No type named std::__norm::_List_nodestd::__7::basic_stringchar, std::__7::char_traitschar, std::__7::allocatorchar . afaics there's __cxx1998 namespace in action not handled by pretty printers.
[Bug driver/36485] gcc driver incorrectly assumes existence of $(prefix)/usr/lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36485 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2012-01-10 18:53:41 UTC --- (In reply to comment #2) This is expected as you are expected to build all multilibs when building GCC for a cross really. i'm using a --disable-multilib option for explicit/pure x86_64 cross-compiler and don't expect any mutlilib files/dirs really. You won't convince me that is a user bug :)
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #11 from Pawel Sikora pluto at agmk dot net 2012-01-10 19:56:08 UTC --- (In reply to comment #10) Thanks guys. This looks good, and is in trunk. Pawel, thanks for noticing this. Please note that namespace versioning was updated for 4.7.x to bring this experimental feature up to the final C++11 spec. can we get this fix for upcoming 4.6.4? it doesn't touch default libstdc++ configuration and fixes bug in non-primary target. looks safe.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #6 from Pawel Sikora pluto at agmk dot net 2011-12-28 16:06:47 UTC --- btw, i've tested the default allocator with std::__7 and the i686-pc-mingw32 toolchain works fine while the x86_64-pc-mingw32 reports undefined reference to .text$_ZN9__gnu_cxx3__713new_allocatorIiE8allocateEyPKv[__gnu_cxx::__7::new_allocatorint::allocate(unsigned long long, void const*)] so, there's a bug with symbol exporting not directly related to mt_allocator. _Znwj vs. _Znwy issue?
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #7 from Pawel Sikora pluto at agmk dot net 2011-12-28 19:51:55 UTC --- please apply following obvious patch: --- gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver.orig 2011-12-28 12:43:50.0 +0100 +++ gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver 2011-12-28 20:25:36.603040153 +0100 @@ -42,9 +42,9 @@ __once_proxy; # operator new(size_t) -_Znw[jm]; +_Znw[jmy]; # operator new(size_t, std::nothrow_t const) -_Znw[jm]RKSt9nothrow_t; +_Znw[jmy]RKSt9nothrow_t; # operator delete(void*) _ZdlPv; @@ -52,9 +52,9 @@ _ZdlPvRKSt9nothrow_t; # operator new[](size_t) -_Zna[jm]; +_Zna[jmy]; # operator new[](size_t, std::nothrow_t const) -_Zna[jm]RKSt9nothrow_t; +_Zna[jmy]RKSt9nothrow_t; # operator delete[](void*) _ZdaPv; it fixes new/delete exports for x86_64-pc-mingw32. mt-allocator needs more exports...
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2011-12-27 09:32:11 UTC --- i'm using the mt allocator for large std containers with small fixed-size objects. the mt's flexible pool configuration and alloc/free speed are an advantage over the simple new (malloc/free) allocator and i'd like to avoid reinventing the wheel with yet another pool allocator.
[Bug libstdc++/51673] New: undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 Bug #: 51673 Summary: undefined references / libstdc++-7.dll Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Created attachment 26182 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26182 testcase with libstdc++-6/7.dll with gcc crosscompiler configured for target x86_64-pc-mingw32 with --enable-symvers=gnu-versioned-namespace --enable-libstdcxx-allocator=mt i'm getting linker errors on trivial testcase. /home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb18allocateEyPKv[__gnu_cxx::__7::__mt_allocint, __gnu_cxx::__7::__common_pool_policy__gnu_cxx::__7::__pool, true ::allocate(unsigned long long, void const*)]+0x63): undefined reference to `operator new(unsigned long long)' /home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb18allocateEyPKv[__gnu_cxx::__7::__mt_allocint, __gnu_cxx::__7::__common_pool_policy__gnu_cxx::__7::__pool, true ::allocate(unsigned long long, void const*)]+0x142): undefined reference to `__gnu_cxx::__7::__pooltrue::_M_reserve_block(unsigned long long, unsigned long long)' /home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb110deallocateEPiy[__gnu_cxx::__7::__mt_allocint, __gnu_cxx::__7::__common_pool_policy__gnu_cxx::__7::__pool, true ::deallocate(int*, unsigned long long)]+0x6d): undefined reference to `__gnu_cxx::__7::__pooltrue::_M_reclaim_block(char*, unsigned long long)' afaics the libstdc++7.dll doesn't export e.g. _Znwy* symbols while libstdc++-6.dll looks fine in this area: $ 86_64-pc-mingw32-objdump -p libstdc++-6.dll|grep _Znw [3472] _Znwy [3473] _ZnwyRKSt9nothrow_t
[Bug libstdc++/51649] New: pretty printers don't handle std::__7:: namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649
Bug #: 51649
Summary: pretty printers don't handle std::__7:: namespace
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
the libstdc++ pretty printers don't work for gcc configured
with --enable-symvers=gnu-versioned-namespace.
e.g. it prints std::string as:
(gdb) p s
$1 = {
static npos = 18446744073709551615,
_M_dataplus = {
std::__7::allocatorchar = {
__gnu_cxx::__7::__mt_allocchar,
__gnu_cxx::__7::__common_pool_policy__gnu_cxx::__7::__pool, true = {
__gnu_cxx::__7::__mt_alloc_basechar = {No data fields}, No data
fields}, No data fields},
members of std::__7::basic_stringchar, std::__7::char_traitschar,
std::__7::allocatorchar ::_Alloc_hider:
_M_p = 0x4d7220 foo bar
}
}
[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649 --- Comment #1 from Pawel Sikora pluto at agmk dot net 2011-12-21 11:53:23 UTC --- adding '(__7::)?' to regex patterns should be ok.
[Bug libstdc++/51142] [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 --- Comment #6 from Pawel Sikora pluto at agmk dot net 2011-11-16 17:19:51 UTC --- any plans to 4.6 backport?
[Bug libstdc++/51142] New: [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51142 Bug #: 51142 Summary: [C++0x] map::erase(key) doesn't compile with -D_GLIBCXX_DEBUG. Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Created attachment 25828 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25828 testcase $ LANG=C make g++ -Wall -std=c++0x t.cpp -c --save-temps -D_GLIBCXX_DEBUG In file included from /usr/include/c++/4.6.2/debug/map:34:0, from /usr/include/c++/4.6.2/map:66, from t.cpp:2: /usr/include/c++/4.6.2/debug/map.h: In member function 'std::__debug::map_Key, _Tp, _Compare, _Allocator::size_type std::__debug::map_Key, _Tp, _Compare, _Allocator::erase(const key_type) [with _Key = boost::variantbool, _Tp = unsigned int, _Compare = std::lessboost::variantbool , _Allocator = std::allocatorstd::pairconst boost::variantbool, unsigned int , std::__debug::map_Key, _Tp, _Compare, _Allocator::size_type = long unsigned int, std::__debug::map_Key, _Tp, _Compare, _Allocator::key_type = boost::variantbool]': t.cpp:10:15: instantiated from here /usr/include/c++/4.6.2/debug/map.h:295:6: error: call of overloaded 'erase(std::__debug::mapboost::variantbool, unsigned int::_Base_iterator)' is ambiguous /usr/include/c++/4.6.2/debug/map.h:295:6: note: candidates are: /usr/include/c++/4.6.2/bits/stl_map.h:613:7: note: std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::iterator std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::erase(std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::const_iterator) [with _Key = boost::variantbool, _Tp = unsigned int, _Compare = std::lessboost::variantbool , _Alloc = std::allocatorstd::pairconst boost::variantbool, unsigned int , std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::iterator = std::_Rb_tree_iteratorstd::pairconst boost::variantbool, unsigned int , std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::const_iterator = std::_Rb_tree_const_iteratorstd::pairconst boost::variantbool, unsigned int ] /usr/include/c++/4.6.2/bits/stl_map.h:643:7: note: std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::size_type std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::erase(const key_type) [with _Key = boost::variantbool, _Tp = unsigned int, _Compare = std::lessboost::variantbool , _Alloc = std::allocatorstd::pairconst boost::variantbool, unsigned int , std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::size_type = long unsigned int, std::__cxx1998::map_Key, _Tp, _Compare, _Alloc::key_type = boost::variantbool] make: *** [all] Error 1
[Bug other/50916] -Os, -D_FORTIFY_SOURCE breaks strcpy others if inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50916 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #4 from Pawel Sikora pluto at agmk dot net 2011-10-30 10:46:48 UTC --- (In reply to comment #3) $ pwd /home/users/arekm/gcc-4.6.2/host-x86_64-unknown-linux-gnu/stage1-gcc/include-fixed $ LC_ALL=C grep -r strcpy . ./nss/secport.h:#define PORT_Strcpy strcpy grep: ./qt4/phonon: No such file or directory ./slang/slang.h:SL_EXTERN char *SLstrcpy(register char *, register char *); Actually I don't see gcc fixincl fixing these glibc headers. gcc's fixincl doesn't touch bits/string3.h which redefines some str* functions.
[Bug tree-optimization/50847] New: missed diagnostics for dead code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
Bug #: 50847
Summary: missed diagnostics for dead code.
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
int bar()
{
throw 42;
return 0; // dead code
}
void zoo( int i )
{
return throw -1;
i = 7; // dead code
}
it would be nice to see some (new -Wunused-statement?) warnings for marked
lines.
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210 --- Comment #9 from Pawel Sikora pluto at agmk dot net 2011-10-07 18:22:25 UTC --- Created attachment 25442 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25442 testcase
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210 --- Comment #11 from Pawel Sikora pluto at agmk dot net 2011-10-07 18:45:57 UTC --- (In reply to comment #10) (In reply to comment #9) Created attachment 25442 [details] testcase I think those are hard to optimize really since those are inline-asm really. And the unsigned short one gets optimized correctly. ahhh, glibc uses a generic i386 implementation (ror+xchg) in byteorder.h while it has an optimized byteswap.h for i486+ :(
[Bug libstdc++/50348] -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2011-09-22 11:23:14 UTC --- (In reply to comment #3) I think that, unless not imposed by the standard (why??) the visibility of namespace std SHALL NOT BE forced to default part of the std:: (exceptions typeinfo symbols) must be visible-by-default for proper throw-catch/dynamic_cast working across shared libs boundaries.
[Bug c++/50400] New: compiler accepts invalid X::Impl::Impl::Impl::.....::foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50400
Bug #: 50400
Summary: compiler accepts invalid
X::Impl::Impl::Impl::.::foo
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
struct X { struct Impl; };
struct X::Impl {
Impl();
void foo();
};
X::Impl::Impl() {
void ( X::Impl::* ptr )() = X::Impl::Impl::Impl::Impl::Impl::foo;
}
gcc-4.6-20110908 and clang++ accept this code while e.g. MSVC reports
an error: C3083: '{ctor}': the symbol to the left of a '::' must be a type
[Bug libstdc++/50348] New: -fvisibility=hidden doesn't hide stl implementation details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50348
Bug #: 50348
Summary: -fvisibility=hidden doesn't hide stl implementation
details.
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
$ cat x.hpp
#ifndef x_hpp
#define x_hpp
#include vector
struct X { void foo(); };
typedef std::vector X VX;
VX bar() __attribute((visibility( default )));
#endif
$ cat x.cpp
#include x.hpp
VX bar() { return VX(); }
$ g++ -fvisibility=hidden -fvisibility-inlines-hidden -fPIC x.cpp -Wall -shared
-o libx.so -s
$ readelf -sW libx.so | grep -v UND | c++filt
Symbol table '.dynsym' contains 20 entries:
Num:Value Size TypeBind Vis Ndx Name
2: 07b0 0 FUNCGLOBAL DEFAULT 10 _init
3: 09f8 0 FUNCGLOBAL DEFAULT 13 _fini
6: 090c30 FUNCGLOBAL DEFAULT 12 bar()
7: 092a26 FUNCWEAK DEFAULT 12 std::vectorX,
std::allocatorX ::vector()
8: 092a26 FUNCWEAK DEFAULT 12 std::vectorX,
std::allocatorX ::vector()
9: 094426 FUNCWEAK DEFAULT 12 std::_Vector_baseX,
std::allocatorX ::_Vector_base()
10: 095e61 FUNCWEAK DEFAULT 12 std::_Vector_baseX,
std::allocatorX ::_Vector_impl::_Vector_impl()
11: 095e61 FUNCWEAK DEFAULT 12 std::_Vector_baseX,
std::allocatorX ::_Vector_impl::_Vector_impl()
12: 099c26 FUNCWEAK DEFAULT 12
std::allocatorX::allocator()
13: 09b610 FUNCWEAK DEFAULT 12
__gnu_cxx::new_allocatorX::new_allocator()
14: 094426 FUNCWEAK DEFAULT 12 std::_Vector_baseX,
std::allocatorX ::_Vector_base()
15: 099c26 FUNCWEAK DEFAULT 12
std::allocatorX::allocator()
16: 09b610 FUNCWEAK DEFAULT 12
__gnu_cxx::new_allocatorX::new_allocator()
17: 1dc0 0 NOTYPE GLOBAL DEFAULT ABS _edata
18: 1dc0 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
19: 1dd0 0 NOTYPE GLOBAL DEFAULT ABS _end
imho the std::vector details shouldn't have default visiblity in this case.
