On Wed, Dec 6, 2023 at 11:12 PM Alexandre Oliva <ol...@adacore.com> wrote:
>
> On Dec 6, 2023, Thomas Schwinge <tho...@codesourcery.com> wrote:
>
> > As I understand things, this cannot be implemented (at the call site) for
> > nvptx, given that the callee's stack is not visible there: PTX is unusual
> > in that the concept of a "standard" stack isn't exposed.
>
> Not even when one PTX function calls another? Interesting. I'd hoped
> that with control over entering and leaving strub contexts, one could
> (manually) ensure they'd run in the same execution domain. But if not
> even that is possible, it will render the current strub implementation
> entirely unusable for this target indeed.
>
> Now, it doesn't seem to me that the build errors being experienced have
> to do with that, but rather with lack of or incomplete support for
> __builtin_{frame,stack}_address(). Are those errors expected when using
> these builtins on this target? I'd have expected them to compile, even
> if something went wrong at runtime.
>
>
> > Instead of allowing "strub" pieces that can be implemented, should this
> > whole machinery generally be disabled (forced '-fstrub=disable', or via a
> > new target hook?)? The libgcc functions should then not get defined
> > (thus, linker error upon accidental use), or should just '__builtin_trap'
> > if that makes more sense? Need an effective-target for the test cases.
>
> > Alternatively, we may also leave the generic middle end handling alive,
> > and 'sorry' (or similar) in the nvptx back end, as necessary?
>
> Disabling the runtime bits is easy, once we determine what condition we
> wish to test for. I suppose testing for target support in the compiler,
> issuing a 'sorry' in case the feature is required, would provide
> something for libgcc configure and testsuite effective-target to test
> for and decide whether to enable runtime support and run the tests.
There's always the possibility to hardcode target triplets we don't support
of course.
Richard.
> --
> Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
> Free Software Activist GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
