[Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[Bug libstdc++/67843] New: experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[clyon at gcc dot gnu.org]

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).

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[clyon at gcc dot gnu.org]

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).

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[clyon at gcc dot gnu.org]

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.

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

[clyon at gcc dot gnu.org]

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.