https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #14 from Christophe Lyon <clyon at gcc dot gnu.org> --- I think I understand the problem better now, after a few experiments, and a discussion with proot's author. The testcase finishes with a call to execute_command_line with wait=.false, so the main process may complete before the child (execute_command_line) does. In such a case, proot returns the exit code of the last living process, the child in our case, so 127 (command not found). And sometimes it can return 0, depending on the process scheduling on the host. Forcing qemu to dump traces seems to hide the problem, probably because it does change the process schedule. FWIW, I can live with this by flagging this test as 'random' in my GCC-regression testing. Removing the last call execute_command_line(command , wait=.false., exitstat=i) or moving it before call execute_command_line(command , exitstat=i, cmdstat=j) seems to workaround the issue for me.
