On Wed, 25 May 2016, Nathan Sidwell wrote: > On 05/25/16 09:28, Alexander Monakov wrote: > > On Wed, 25 May 2016, Nathan Sidwell wrote: > > > > > This patch reimplements crt0 as C rather than assembly. That means > > > it;ll be > > > good with 32 bit addresses. I've also completely moved abort and exit > > > into > > > newlib (a fork on github), which had it's own copies that failed to set > > > the > > > exit code. Things happened to work because they were never found, being > > > hidden by the ones provided in crt0.s. You'll need to update your newlib > > > sources for exit codes to continue to work. > > > > Doesn't this break offloading compilation? > > It won't -- but you're right about .weak not being undefined-is-zero.
With today's trunk and newlib, if I run make check-target-libgomp RUNTESTFLAGS=c.exp=abort-2.c in the output I see: Running ../../../../gcc/libgomp/testsuite/libgomp.oacc-c/c.exp ... FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/abort-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -O0 (test for excess errors) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/abort-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -O2 (test for excess errors) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/abort-2.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -O2 (test for excess errors) and libgomp.log has: unresolved symbol __exitval_ptr collect2: error: ld returned 1 exit status mkoffload: fatal error: /home/am/ww/i/bin//x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status compilation terminated. lto-wrapper: fatal error: /home/am/ww/i/libexec/gcc/x86_64-pc-linux-gnu/7.0.0//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status compiler exited with status 1 Am I missing anything? > > > Or is that something nvptx-run should check for and initialize? > > > > The interface between nvptx-run and crt0 would need to change to allow that. > > That is exactly what I'm suggesting. nvptx-run looks for a __soft_stack > symbol and goes poking at it before launch. It is possible, but it seems it's enough to set up soft stacks under #ifdef __nvptx_softstack__ in __main. Is that fine? Alexander
