Hello, It looks like std::atomic<float> does is not fully implemented. I get an undefined reference to its operator float: libtool: link: g++ -Wall -I/usr/include -I../../src -I../../src -g -O2 -std=c++0x -DNDEBUG -o .libs/psynth_unit_test psynth_unit_test-psynth_unit_test.o [... a big list of object files ...] -L/usr/lib64 -lboost_unit_test_framework-mt -lboost_filesystem-mt -lboost_signals-mt -lboost_system-mt ../psynth/.libs/libpsynth.so -Wl,-rpath -Wl,/home/raskolnikov/usr/lib ../psynth/.libs/libpsynth.so: undefined reference to `atomic<float>::operator float() const' A similar bug happened when I tried std::atomic<my_enum> with "my_enum" being a "enum class my_enum : int", I got an undefined reference to the "store ()" method instead. I am using GCC 4.6 as included in Debian Sid: g++ --version g++ (Debian 4.6.0-13) 4.6.1 20110611 (prerelease) apt-cache show libstdc++6-4.6-dev Package: libstdc++6-4.6-dev Source: gcc-4.6 Version: 4.6.0-13 Anyways, thanks a lot for your hard work implementing C++11 :) JP
Testcase?
Created attachment 24553 [details] Test case for the "undefined reference" on atom<float> bug raskolnikov@nexus9:~$ make CXXFLAGS=-std=c++0x test_atom g++ -std=c++0x test_atom.cpp -o test_atom /tmp/ccS68VP3.o: In function `main': test_atom.cpp:(.text+0x18): undefined reference to `std::atomic<float>::operator float() const' collect2: ld returned 1 exit status make: *** [test_atom] Error 1
It looks like C++11 only defines atomic<integral> and atomic<T*>, so a link-time error on atomic<float> seems ok, no?
(In reply to comment #3) > It looks like C++11 only defines atomic<integral> and atomic<T*>, so a > link-time error on atomic<float> seems ok, no? Sorry, please ignore the above comment, I should have read the standard properly before posting.
You are right, I thought it worked for all fundamental types but reviewing the proposal [1] makes me realise I was wrong. It remains unclear wether user defined enums should work ... Thanks a lot for the fast reply and sorry for the mistake. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html
(In reply to comment #5) > You are right, I thought it worked for all fundamental types but reviewing the > proposal [1] makes me realise I was wrong. It remains unclear wether user > defined enums should work ... According to 29.5.1 in the draft standard i have (n3242): "There is a generic class template atomic<T>. The type of the template argument T shall be trivially copyable (3.9)." That wording is in several older drafts, too, going back to at least March 2010, so it's not new and probably won't change. So it *should* work for all fundamental types, and even user-defined types (classes) provided they're trivially copyable. Both float and scoped enums are trivially copyable, so atomic<float> and atomic<some_enum_class_type> should work. What the standard says about integral types is just that specializations already exist for them (like specialization atomic<int> exists, and publicly inherits from atomic_int).
Yup, it should work, but it's not fully implemented yet Severity is not "major" though, it's a missing feature in the experimental C++0x mode, let's not pretend it's a serious problem for anyone.
Mine
This is no longer present on 4.7.x branch. I'm going to add this test case in any case.
Author: bkoz Date: Fri Feb 3 21:10:00 2012 New Revision: 183878 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183878 Log: 2012-02-03 Benjamin Kosnik <bkoz@redhat.com> PR libstdc++/49445 Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic/cons/49445.cc Modified: trunk/libstdc++-v3/ChangeLog
Fixed in 4.7
*** Bug 53899 has been marked as a duplicate of this bug. ***