This is now backported to the devel/omp/gcc-11 branch (OG11).
Andrew
On 09/12/2021 11:41, Andrew Stubbs wrote:
On 02/12/2021 16:43, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 04:31:36PM +0000, Andrew Stubbs wrote:
On 02/12/2021 16:05, Andrew Stubbs wrote:
On 02/12/2021 12:58, Jakub Jelinek wrote:
I've tried modifying offload_handle_link_vars but that spot
doesn't catch
the omp_data_sizes variables emitted by
libgomp.c-c++-common/target_42.c,
which was one of the motivating examples.
Why doesn't catch it? Is the variable created only post-IPA?
I'd think that it should have been created before IPA, streamed and
therefore I don't understand why you don't see it after streaming
LTO in.
On closer inspection it does, in fact, catch it as you'd expect, but
then the variable is no longer marked public when it gets to
pass_omp_target_link::execute, so something somewhere is resetting it.
More investigation is needed....
The "whole-program" pass is removing the public flag. That's probably
working as intended, and I assume it is run for offload code on purpose?
So you'd stick it somewhere into e.g. symbol_table::compile
after ipa_passes call, guarded with #ifdef ACCEL_COMPILER ?
I've given up on this approach, and switched to loading the symbol
addresses from the table directly. The relocation issues that I had with
older assemblers/linkers do not seem to be a problem any more.
This patch requires only a single symbol to be forced global, and since
that's one that I create in mkoffload there is no issue with previous
definitions.
I think I can approve this myself, but if you have any observations I'm
happy to hear them.
Andrew
