Hi Damian, well F2008 Note 8.30 states:
If the stop-code is an integer, it is recommended that the value also be used as the process exit status, if the processor supports that concept. .... and in F2018 its not even "just a note" anymore, but in 11.4 §2 same sentence as in the note. At least to get determined behavior, both CAF and non-CAF programs should behave the same. - Andre On Thu, 19 Dec 2024 05:25:08 -0800 Damian Rouson <damian@archaeologic.codes> wrote: > I don’t think the standard requires providing the stop code to the > OS, but it recommends doing so. So this is a great idea. Thanks for > working on coarray features. > > Damian > > On Thu, Dec 19, 2024 at 04:14 Andre Vehreschild <ve...@gmx.de> wrote: > > > Hi all, > > > > attached patch fixes a rather old open issue, that I stumbled upon > > while trying to figure, why a test failed on the command line but > > not in the testsuite. The implementation of the STOP command in > > caf_single did not hand the errorcode over to the OS, as does > > non-caf STOP and as it is required by the standard. So I fixed > > that. I also added reporting of exceptions to the coarray (ERROR)? > > STOP routines. For this I have exported the existing function of > > the regular gfortran runtime library. I tried to do this via > > iexport_proto, but was never able to access the routine from the > > caf-library. I always got linker errors. > > > > After fixing caf-STOP the testsuite reported one regression, which I > > also fixed in send_by_ref. > > > > Bootstrapped and regtests ok on x86_64-pc-linux-gnu / F41. Ok for > > mainline? > > > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gcc dot gnu dot org > > -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 178 3837536 * ve...@gmx.de
