[PATCH] Integration of parallel standard algorithms for c++17

Thomas Rodgers trodgers@redhat.com
Thu Mar 21 22:19:00 GMT 2019


Fixed up change log.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20190321-1-pstl-integration.patch.bz2
Type: application/x-bzip2
Size: 76426 bytes
Desc: pstl integration patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190321/71f2ffed/attachment.bz2>
-------------- next part --------------

Thomas Rodgers writes:

> Jonathan Wakely writes:
>
>> On 20/03/19 14:05 -0700, Thomas Rodgers wrote:
>>
>>>
>>>Fixed a failing test.
>>
>> Thanks. Apart from the changelog issue I mentioned on IRC, the only
>> other required change I see is in include/Makefile.am:
>>
>> @@ -1480,7 +1512,9 @@ install-headers:
>> 	$(mkinstalldirs) $(DESTDIR)${host_installdir}/../ext
>> 	for file in ${ext_host_headers}; do \
>> 	  $(INSTALL_DATA) $${file} $(DESTDIR)${host_installdir}/../ext; done
>> -
>> +	$(mkinstalldirs) ($DESTDIR)${gxx_include_dir}/${pstl_builddir}
>>
>> This needs to be $(DESTDIR) not ($DESTDIR).
>>
>> ***
>>
>> I also see a couple of things that we probably can't fix for now, but
>> I'll mention them anyway for later consideration.
>>
>> In <bits/glue_execution_defs.h> there's a local include using ""
>> instead of <> (see PR libstdc++/88066 for a similar case I changed
>> recently):
>>
>> #include "execution_defs.h"
>>
>> We could fix that one, but then *all* the relative includes in
>> include/pstl/*  use "" too. Do you think upstream would change to use
>> #include <pstl/blah.h> instead of #include "blah.h" ? It looks like
>> upstream uses <pstl/include/...> instead so maybe that's something to
>> change in your script to import the upstream code.
>>
>> Even if we fix it, TBB headers use "" instead of <>.  And it might not
>> be a problem for any compiler except GCC, because only we support the
>> silly -I- option that makes this matter.
>>
>>
>> I also noticed that simply including <execution> (even if you don't
>> use anything from it) will cause a link-time dependency on TBB:
>>
>> /usr/bin/ld: /tmp/ccd7w5Oo.o: in function `tbb::interface7::task_arena::current_thread_index()':
>> /usr/include/tbb/task_arena.h:358: undefined reference to `tbb::interface7::internal::task_arena_base::internal_current_slot()'
>> collect2: error: ld returned 1 exit status
>>
>> This dependency comes from <tbb/partioner.h> which is included by
>> <tbb/parallel_scan.h> which is included by <bits/execution_defs.h>.
>>
>> I think that's OK for now, as no existing code using GCC includes the
>> <execution> header (because it doesn't exist yet). It would be good if
>> we can find a way to solve that eventually though. Maybe the eventual
>> solution will just be a non-TBB backend using OpenMP.
>>
>> Exporting something like this from libstdc++.so would work, but is
>> disgusting (and presumably "tbb::interface7" changes from release to
>> release?"):
>>
>> extern "C" [[__gnu__::__weak__]]
>> int
>> _ZN3tbb10interface78internal15task_arena_base21internal_current_slotEv()
>> { return -1; }



More information about the Gcc-patches mailing list