public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
@ 2015-10-04 18:24 clyon at gcc dot gnu.org
2015-10-05 6:44 ` [Bug libstdc++/67843] " clyon at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: clyon at gcc dot gnu.org @ 2015-10-04 18:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843
Bug ID: 67843
Summary: experimental/filesystem/iterators/directory_iterator.c
c fails on armv5t
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
./experimental/filesystem/iterators/directory_iterator.cc fails when compiled
with -march=armv5t:
*** Error in `./directory_iterator.exe': malloc(): memory corruption:
0x40b787f7 ***^M
To reproduce it, you can build an armv7* toolchain, can compile this testcase
with -march=armv5t, and execute the result.
I chose the libstdc++ category for the time being, but it could very well be
target dependent bug (since it works on armv7-a for instance).
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
2015-10-04 18:24 [Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t clyon at gcc dot gnu.org
@ 2015-10-05 6:44 ` clyon at gcc dot gnu.org
2015-10-05 10:16 ` clyon at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: clyon at gcc dot gnu.org @ 2015-10-05 6:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843
--- Comment #2 from Christophe Lyon <clyon at gcc dot gnu.org> ---
I am not sure what kind of helpful information I can provide.
Can you build a cross-compiler (x86 -> armv7-a)?
This is what I do and I haven't seen the ICE you mention (I was using r228286).
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
2015-10-04 18:24 [Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t clyon at gcc dot gnu.org
2015-10-05 6:44 ` [Bug libstdc++/67843] " clyon at gcc dot gnu.org
@ 2015-10-05 10:16 ` clyon at gcc dot gnu.org
2015-10-07 22:11 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: clyon at gcc dot gnu.org @ 2015-10-05 10:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843
--- Comment #3 from Christophe Lyon <clyon at gcc dot gnu.org> ---
I can attach a statically linked binary, if that helps.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
2015-10-04 18:24 [Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t clyon at gcc dot gnu.org
2015-10-05 6:44 ` [Bug libstdc++/67843] " clyon at gcc dot gnu.org
2015-10-05 10:16 ` clyon at gcc dot gnu.org
@ 2015-10-07 22:11 ` redi at gcc dot gnu.org
2015-10-07 22:41 ` redi at gcc dot gnu.org
2015-10-09 13:52 ` clyon at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2015-10-07 22:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've just realised this is probably the same issue as PR42734
If you compile for armv5 then shared_ptr uses a mutex internally, because armv5
doesn't support the necessary atomics. The library is compiled for armv7, so
its shared_ptr uses atomics. When you pass a shared_ptr from an object
compiled with armv5 to a library compiled as armv7 they disagree on the size
and layout of the object, and all hell breaks loose.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
2015-10-04 18:24 [Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t clyon at gcc dot gnu.org
` (2 preceding siblings ...)
2015-10-07 22:11 ` redi at gcc dot gnu.org
@ 2015-10-07 22:41 ` redi at gcc dot gnu.org
2015-10-09 13:52 ` clyon at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2015-10-07 22:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 36458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36458&action=edit
Require consistent shared_ptr lock policy
Maybe we should solve this by forcing a linker error when an object doesn't
have the same lock policy as the library.
This patch causes the shared_ptr tests to FAIL when run with -march=i386, with
this error:
include/bits/shared_ptr_base.h:160: undefined reference to `void
std::__check_lock_policy<(__gnu_cxx::_Lock_policy)1>()
Instead of corrupting the heap at run-time the tests fail to link because the
library only has a definition for
std::__check_lock_policy<(__gnu_cxx::_Lock_policy)2>()
The same thing should work for arm and other targets where the availability of
atomics depends on -march.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t
2015-10-04 18:24 [Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t clyon at gcc dot gnu.org
` (3 preceding siblings ...)
2015-10-07 22:41 ` redi at gcc dot gnu.org
@ 2015-10-09 13:52 ` clyon at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: clyon at gcc dot gnu.org @ 2015-10-09 13:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843
--- Comment #8 from Christophe Lyon <clyon at gcc dot gnu.org> ---
I've tested the patch you attached.
It needs a slight modification because it does not apply to current trunk:
_GLIBCXX_READ_MEM_BARRIER;
_GLIBCXX_WRITE_MEM_BARRIER;
have been replaced by:
__atomic_thread_fence (__ATOMIC_ACQ_REL);
I then ran the tests as I usually do (build a armv7-a toolchain, force
-march=armv5t when running make check), and the test FAILed:
/tmp/ccyPksY2.o: In function
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)1>::_M_release()':^M
/home/christophe.lyon/src/GCC/builds/gcc-fsf-trunk/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/shared_ptr_base.h:160:
undefined reference to `void
std::__check_lock_policy<(__gnu_cxx::_Lock_policy)1>()'^M
[....]
If I don't force -march=armv5t (and use the default armv7-a), the test PASSes.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-10-09 13:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-04 18:24 [Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t clyon at gcc dot gnu.org
2015-10-05 6:44 ` [Bug libstdc++/67843] " clyon at gcc dot gnu.org
2015-10-05 10:16 ` clyon at gcc dot gnu.org
2015-10-07 22:11 ` redi at gcc dot gnu.org
2015-10-07 22:41 ` redi at gcc dot gnu.org
2015-10-09 13:52 ` clyon at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).