https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124554
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Indeed, it seems as if this is a gcn/nvptx newlib problem. Looking at std.ii,
there is:
extern "C" {
void longjmp (jmp_buf __jmpb, int __retval) __attribute__((__noreturn__));
int setjmp (jmp_buf __jmpb) __attribute__((__returns_twice__));
}
without anything interesting before. 'jmp_buf' not being declared seems to be
the main issue, even if I don't understand the 'void' issue.
* * *
On the libstdc++ side:
* Since the regression-causing commit, std.cc is build as it is now linked:
am_libmodulesconvenience_la_OBJECTS = std.lo std.compat.lo
The file is created as:
std.cc: std.cc.in std-clib.cc.istd.cc.in std-clib.cc.inn
cat $^ > $@
which contains:
libstdc++-v3/src/c++23/std-clib.cc.in:// 17.13.3 <csetjmp>
libstdc++-v3/src/c++23/std-clib.cc.in: using std::jmp_buf;
libstdc++-v3/src/c++23/std-clib.cc.in: using std::longjmp;
albeit the header inclusion is via
libstdc++-v3/src/c++23/std.cc.in:#include <bits/stdc++.h>
That file is in the build directory but actually just a link to the source
dirs'
libstdc++-v3/include/precompiled/stdc++.h
and has
// 17.4.1.2 Headers
// C
// Don't include cassert, it's not suitable for PCH or header unit.
...
#include <csetjmp>
which has the content as shown in comment 0.
* * *
For the amdgcn / nvptx side:
- If one typedefs "jmp_buf" the std.cc will compile. In the mentioned
machine/setjmp.h, it is defined as:
#ifdef _JBLEN
#ifdef _JBTYPE
typedef _JBTYPE jmp_buf[_JBLEN];
#else
typedef int jmp_buf[_JBLEN];
#endif
#endif
The question is only what is needed here ...
- and if having it being compiled here, what is actually required to make it
work (if possible)
* * *
Thus, this boils down to:
- Can it (easily) be fixed in Newlib for gcn + nvptx
- If not, can/should it either be excluded from libstdc++'s std++.h or should
it be implemented as stub lib newlib or … ?
