On Mon, 3 Sep 2018 at 11:07, Janne Blomqvist wrote:
>
> On Mon, Sep 3, 2018 at 1:39 AM Bernhard Reutner-Fischer
> wrote:
>>
>> On Sun, 15 Jul 2018 at 13:20, Thomas Koenig wrote:
>>
>> + au = (async_unit *) xmalloc (sizeof (async_unit));
>>
>> I'd XCNEW (async_unit) and omit all those NULL and
On Mon, Sep 3, 2018 at 1:39 AM Bernhard Reutner-Fischer <
rep.dot@gmail.com> wrote:
> On Sun, 15 Jul 2018 at 13:20, Thomas Koenig wrote:
>
> + au = (async_unit *) xmalloc (sizeof (async_unit));
>
> I'd XCNEW (async_unit) and omit all those NULL and 0 stores.
> You should use the scalar alloc
On Sun, 15 Jul 2018 at 13:20, Thomas Koenig wrote:
> So, here is the final version. I would really like to get this
> into trunk, and out of the way, so Nicolas and I can focus on
> other things.
>
> So, OK?
[I know i'm late as it was already applied]
For me it would be easier to read the locki
> Le 15 juil. 2018 à 21:35, Rainer Orth a écrit
> :
>
> Hi Jerry,
>
>> On 07/15/2018 11:46 AM, Rainer Orth wrote:
>>> Hi Jerry,
>>>
Hmm, interesting. Which linux are you using?
>>>
>>> Fedora 27.
>>
>> Works for me. Fedora 28. Do not know for other OS's
>
> just tried Solaris 11/x86
Am 15.07.2018 um 19:47 schrieb Rainer Orth:
Because this does not appear to work with Linux. I, like
most gfortran developers, work on Linux, and I would like to
catch any failure during regression-testing on my own system,
if possible.
huh, what doesn't work? I've just finished an x86_64-pc-li
Hi Jerry,
> On 07/15/2018 11:46 AM, Rainer Orth wrote:
>> Hi Jerry,
>>
>>> Hmm, interesting. Which linux are you using?
>>
>> Fedora 27.
>
> Works for me. Fedora 28. Do not know for other OS's
just tried Solaris 11/x86: works just as well. I could try Mac OS X
10.7, but that build would take qui
On 07/15/2018 11:46 AM, Rainer Orth wrote:
Hi Jerry,
Hmm, interesting. Which linux are you using?
Fedora 27.
Rainer
Works for me. Fedora 28. Do not know for other OS's
Jerry
Hi Jerry,
> Hmm, interesting. Which linux are you using?
Fedora 27.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
On 07/15/2018 10:47 AM, Rainer Orth wrote:
Hi Thomas,
However, I still don't understand why you insist on the hack with
putting the async_io_*.f90 tests into the libgomp testsuite. Why not
just make the pthread requirement explicit with
{ dg-require-effective-target pthread }
{ dg-additional-
On 07/15/2018 07:21 AM, Rainer Orth wrote:
Hi Thomas,
I am currently testing the patch at
https://gcc.gnu.org/ml/fortran/2018-07/msg8.html
so far, so good!
IMO the tests should go to gfortran.dg (they pass my tests).
I put the asycn_io_*.f90 tests into libgomp.fortran because,
under L
Hi Thomas,
>> However, I still don't understand why you insist on the hack with
>> putting the async_io_*.f90 tests into the libgomp testsuite. Why not
>> just make the pthread requirement explicit with
>>
>> { dg-require-effective-target pthread }
>> { dg-additional-options "-pthread" }
>>
>> an
On 07/15/2018 04:19 AM, Thomas Koenig wrote:
Hi everybody,
I am currently testing the patch at
https://gcc.gnu.org/ml/fortran/2018-07/msg8.html
so far, so good!
IMO the tests should go to gfortran.dg (they pass my tests).
I put the asycn_io_*.f90 tests into libgomp.fortran because,
un
Hi Rainer,
I've now regtested the patch on i386-pc-solaris2.11 and
sparc-sun-solaris2.11: no regressions and the new tests all PASS.
Thanks, that is good news!
However, I still don't understand why you insist on the hack with
putting the async_io_*.f90 tests into the libgomp testsuite. Why
Hi Thomas,
>> I am currently testing the patch at
>> https://gcc.gnu.org/ml/fortran/2018-07/msg8.html
>>
>> so far, so good!
>
>> IMO the tests should go to gfortran.dg (they pass my tests).
>
> I put the asycn_io_*.f90 tests into libgomp.fortran because,
> under Linux, gfortran.dg does not li
Hi everybody,
I am currently testing the patch at
https://gcc.gnu.org/ml/fortran/2018-07/msg8.html
so far, so good!
IMO the tests should go to gfortran.dg (they pass my tests).
I put the asycn_io_*.f90 tests into libgomp.fortran because,
under Linux, gfortran.dg does not link in pthrea
I have done a full regression testing with the patch at
https://gcc.gnu.org/ml/fortran/2018-07/msg4.html + Rainer’s patch
at https://gcc.gnu.org/ml/fortran/2018-07/msg7.html
I am currently testing the patch at
https://gcc.gnu.org/ml/fortran/2018-07/msg8.html
so far, so good!
IMO the
Hi Thomas,
> Ah, I see what was wrong.
>
> The attached patch should fix this.
it almost did the trick indeed. With the new patch, only two failures
remain:
FAIL: gfortran.dg/flush_1.f90 -O0 execution test
FAIL: gfortran.dg/flush_1.f90 -O1 execution test
FAIL: gfortran.dg/flush_1.f90 -O
Hi Rainer,
However, may
(all?) gfortran tests now SEGV. One example is
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
Segmentation Fault
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfe1b1f03
Hi Thomas,
> another test run on i386-pc-solaris2.11 is underway. However, may
> (all?) gfortran tests now SEGV. One example is
the good news is: all three libgomp.fortran/async_io_?.f90 tests now
PASS for both 32 and 64-bit, as do gfortran.dg/f2003_inquire_1.f03 and
gfortran.dg/f2003_io_1.f03.
Hi Thomas,
> the attached patch is the third take on Nicolas' and my patch
> for implementing asynchronous I/O. Some parts have been reworked, and
> several bugs which caused either incorrect I/O or hangs have been
> fixed in the process.
>
> I have to say that getting out these bugs has been muc
Hello world,
the attached patch is the third take on Nicolas' and my patch
for implementing asynchronous I/O. Some parts have been reworked, and
several bugs which caused either incorrect I/O or hangs have been
fixed in the process.
I have to say that getting out these bugs has been much hard
21 matches
Mail list logo
