Non-portable constructs in the UPC++ implementation

[Paul Hargrove]

Purpose:

This issue is a central place to record known instances of non-portable constructs in the UPC++ implementation.

How to use this issue:

This issue should remain on the current milestone unless/until the list becomes empty.

Add one Comment for each known portability problem when discovered and for each major change in status (such as opening or closing a problem-specific issue). Where possible, it would be ideal to edit the initial comment to append updates rather than having several interleaved streams (no "reply" in Issues, only in PRs).

This issue is intended to maintain a list of the problems, not to discuss them in detail.
Discussion of individual problem should take place in specific issues.
However, discussion of portability in general is fine.

Where issues are already open for problems, this issue should link to them.
Otherwise a short description and/or link to other discussion is sufficient.

[Paul Hargrove]

Use of __builtin_assume_aligned is described in Issue 248

RESOLVED via pull request 169

[Paul Hargrove]

Non-portable usage of std::aligned_storage, std::aligned_alloc and posix_memalign are described in Issue 246.

RESOLVED

[Paul Hargrove]

In PR #110 we identified unconditional use of __attribute__((always_inline)).
This does not yet have a problem-specific issue.

RESOLVED in PR110.
Only remaining instance is within dl_malloc.c where is is guarded by #if defined(__GNUC__)

[Paul Hargrove]

In PR #110 Dan identified use of gnu-style inline asm.
This does not yet have a problem-specific issue, but this PR comment describes the problem.

[Dan Bonachea]

Bulk roll-over of unresolved issues to next milestone

[Dan Bonachea]

This was discussed in the 2020-02-12 meeting and deferred indefinitely, as this is a "collection" issue