[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Ingo Müller <2013.bugzilla.gcc.gnu.org at ingomueller dot net> changed: What|Removed |Added CC||2013.bugzilla.gcc.gnu.org@i ||ngomueller.net --- Comment #7 from Ingo Müller <2013.bugzilla.gcc.gnu.org at ingomueller dot net> --- libiberty.a is still installed to /lib/libiberty.a in GCC 4.8.1, even with --disable-install-libiberty set.
[Bug other/58086] New: Installer installs files outside --prefix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58086 Bug ID: 58086 Summary: Installer installs files outside --prefix Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: 2013.bugzilla.gcc.gnu.org at ingomueller dot net The installer of gcc-4.8.1 installs the following files outside the path specifide by --prefix to the configure script: /lib/libiberty.a /lib32/libquadmath.so.0.0.0 /lib32/libgomp.la /lib32/libgij.la /lib32/libmudflapth.la /lib32/libmudflapth.a /lib32/libssp_nonshared.a /lib32/libgfortran.so.3.0.0 /lib32/libquadmath.la /lib32/libgomp.spec /lib32/libgomp.so.1.0.0 /lib32/libitm.a /lib32/libssp_nonshared.la /lib32/libstdc++.a /lib32/libssp.la /lib32/libobjc.la /lib32/libgcj.la /lib32/libgcj_bc.so.1.0.0 /lib32/libstdc++.la /lib32/libobjc.so.4.0.0 /lib32/libsupc++.la /lib32/libitm.la /lib32/libitm.so.1.0.0 /lib32/libgfortran.a /lib32/logging.properties /lib32/libmudflap.la /lib32/libmudflap.so.0.0.0 /lib32/libmudflap.a /lib32/libitm.spec /lib32/libgcj-tools.la /lib32/security/classpath.security /lib32/libmudflapth.so.0.0.0 /lib32/libssp.a /lib32/libgcj_bc.so /lib32/libgfortran.la /lib32/libobjc.a /lib32/libssp.so.0.0.0 /lib32/libgcc_s.so.1 /lib32/libgfortran.spec /lib32/libsupc++.a /lib32/libquadmath.a /lib32/libgomp.a /lib64/libquadmath.so.0.0.0 /lib64/libgomp.la /lib64/libgij.la /lib64/libmudflapth.la /lib64/libmudflapth.a /lib64/libssp_nonshared.a /lib64/libgfortran.so.3.0.0 /lib64/libquadmath.la /lib64/libgomp.spec /lib64/libgomp.so.1.0.0 /lib64/libitm.a /lib64/libssp_nonshared.la /lib64/libstdc++.a /lib64/libssp.la /lib64/libobjc.la /lib64/libgcj.la /lib64/libgcj_bc.so.1.0.0 /lib64/libstdc++.la /lib64/libobjc.so.4.0.0 /lib64/libsupc++.la /lib64/libitm.la /lib64/libitm.so.1.0.0 /lib64/libgfortran.a /lib64/logging.properties /lib64/libmudflap.la /lib64/libmudflap.so.0.0.0 /lib64/libmudflap.a /lib64/libitm.spec /lib64/libgcj-tools.la /lib64/security/classpath.security /lib64/libmudflapth.so.0.0.0 /lib64/libssp.a /lib64/libgcj_bc.so /lib64/libgfortran.la /lib64/libobjc.a /lib64/libssp.so.0.0.0 /lib64/libgcc_s.so.1 /lib64/libgfortran.spec /lib64/libsupc++.a /lib64/libquadmath.a /lib64/libgomp.a /lib32/libgcc_s.so /lib32/libgcj_bc.so.1 /lib64/libgcc_s.so /lib64/libgcj_bc.so.1 I produced this list by executing the following commands: wget http://gcc.cybermirror.org/releases/gcc-4.8.1/gcc-4.8.1.tar.gz tar -xf gcc-4.8.1.tar.gz cd gcc-4.8.1/ ./configure --prefix=/opt/gcc-4.8 --program-suffix=-4.8 make sudo checkinstall #answer some questions sudo dpkg --force-overwrite -i gcc-4.8_4.8.1-1_amd64.deb dpkg then warns about the above list of files been overwritten. I suppose that everything should be installed under PREFIX, instead.
[Bug c++/58542] New: std::atomic<__int128_t>::store broken with -march=corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58542 Bug ID: 58542 Summary: std::atomic<__int128_t>::store broken with -march=corei7 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: 2013.bugzilla.gcc.gnu.org at ingomueller dot net The attached file shows how std::atomic<__int128_t>::store is broken when compiled with --march=corei7. Then relevant code looks like this: std::atomic<__int128_t> i; i = -1; std::cout << std::hex << uint64_t(i>>64) << uint64_t(i) << std::endl; Depending on the compile flags, the program outputs the correct or an incorrect result: $ g++-4.8 -std=c++11 test.cpp -O1 -latomic -o test_right && ./test_right $ g++-4.8 -std=c++11 test.cpp -O1 -march=corei7 -latomic -o test_wrong && ./test_wrong 0 It looks like the upper 64bit are not stored. I tested GCC 4.7.3 and 4.8.1, but I don't have a snapshot at hand -- sorry.
[Bug c++/58542] std::atomic<__int128_t>::store broken with -march=corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58542 --- Comment #1 from Ingo Müller <2013.bugzilla.gcc.gnu.org at ingomueller dot net> --- Created attachment 30901 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30901&action=edit Minimal "working" example of how std::atomic<__int128_t>::store can break.
[Bug c++/56146] New: Erroneous char initialization only in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56146
Bug #: 56146
Summary: Erroneous char initialization only in template
function
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 2013.bugzilla.gcc.gnu@ingomueller.net
Consider the following piece of code:
---
#include
#include
#define INIT_BODY \
int mem_size = 1 << 30; \
\
double start = omp_get_wtime(); \
char* data = new char[mem_size]; \
double end = omp_get_wtime(); \
\
printf( "%f s for new char[%i].\n", end - start, mem_size ); \
delete [] data;
template void init1() { INIT_BODY }
void init2() { INIT_BODY }
int main(int argc, char* argv[])
{
init1(); // with template: takes about a second
init2(); // without template: takes a few microseconds
}
---
I expect the two functions to behave exactly the same way, as they have exactly
the same body. Note that the template parameter of init1 is not used. However,
in init1, the new char array seems to be initialized. As far as I know, new
arrays of PODs should not be initialized by "new". In any way, it is not
understandable why the two functions differ in their behavior.
Note that I use OpenMP just for its handy timer function. Any other timer (and
compiling without -fopenmp) yields the same result. I also measured the number
of minor page faults, which correspond exactly to what I expect for
initializing the new array. Also note that doubling mem_size doubles both the
time and the number of page faults. Last but not least, inverting the order of
the two function calls or repeating them does not change anything.
Conclusion: I think that arrays constructed by "new" are erroneously
initialized when called from a templated function.
I observed the erroneous behavior (as described above) in the following
compilers:
gcc 4.5.3
gcc 4.6.1
gcc 4.6.2
gcc 4.7.1
I observed the correct behavior (both timers yield the same, very small amount
of time) in the following compilers:
gcc 4.4.3
gcc 4.8-20130120
icc 12.1.2
clang: 3.1
If it matters, I am using Ubuntu 10.04.4.
[Bug c++/70758] New: unique_ptr of aligned T calls invalid free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70758
Bug ID: 70758
Summary: unique_ptr of aligned T calls invalid free
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 2013.bugzilla.gcc.gnu.org at ingomueller dot net
Target Milestone: ---
Created attachment 38321
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38321&action=edit
Example c++ program that produces the invalid free.
In a certain situation, the default delete of a unique_ptr calls an
invalid free.
The situation occurs for a struct that as an __attributed__ ((aligned(x))) with
a google dense_hash_map as a member. I haven't been able to figure out what is
special about the dense_hash_map yet. A short version of the code that produces
the bug (full version is attached):
typedef google::dense_hash_map HmType;
typedef struct C {
HmType hm;
} C __attribute__ ((aligned(64)));
int main(int,char**)
{
std::unique_ptr cx( new C[100] );
}
The free called by delete [] called by the deleter of the unique pointer is
invalid: valgrind says it is "56 bytes inside a block of size 8,064 alloc'd".
To reproduce:
1) Install google sparsehash-2.0.3
(https://github.com/sparsehash/sparsehash/releases).
2) Compile and run with valgrind: g++ -std=c++11 uniqueptr.cpp && valgrind
./a.out
Relevant output:
==7631== Invalid free() / delete / delete[] / realloc()
==7631==at 0x4C2A8E0: operator delete[](void*) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7631==by 0x401D3D: std::default_delete::operator()(C*) const (in
/tmp/a.out)
==7631==by 0x4018B4: std::unique_ptr
>::~unique_ptr() (in /tmp/a.out)
==7631==by 0x400D10: main (in /tmp/a.out)
==7631== Address 0x5a07fd8 is 56 bytes inside a block of size 8,064 alloc'd
==7631==at 0x4C298A0: operator new[](unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7631==by 0x400CBB: main (in /tmp/a.out)
Other remark: g++ warns that it ignores attributes on C of the unique_ptr,
but doesn't warn on unique_ptr. Maybe it should ignore the alignment for
the array as well, but doesn't?
