>>> FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
>
> This seems to be a bug in the test suite. It tries to find out whether an id
> is pending that is never initialized.
>
>>> FAIL: gfortran.dg/f2003_io_1.f03 -O*
>
> And another bug in the test suite. This time the wait
Hi Nicolas,
a few other nits:
* The current patch has a large number of GNU Coding Style violations,
many catched by contrib/check_GNU_style.{sh,py}.
* Others are partially pre-existing (additional blank before formal
paramater name as in
+destroy_adv_cond (struct adv_cond * ac)
and
Hi Jakub,
>> I do note that if one has, say, 8 files and only one
>> file uses async IO, then during linking of the 8 *.o
>> files to make the final execute -lpthread must be added.
>> How doesn't gfortran communicate that to the loader?
>
> ELF doesn't a way to do this, you'd need to add a
On Tue, Jun 05, 2018 at 11:47:21PM -0700, Steve Kargl wrote:
> I have not looked at the source code, but do have a question.
> With -fopenmp, gfortran automatically adds -lpthread to
> the command line. Is it possible during the parsing
Even if it wouldn't, libgomp.so.1 depends on
On Wed, Jun 06, 2018 at 08:34:57AM +0300, Janne Blomqvist wrote:
> On Wed, Jun 6, 2018 at 3:43 AM, Jerry DeLisle wrote:
>
> > On 06/05/2018 06:58 AM, Rainer Orth wrote:
> >
> >> Hi Nicolas,
> >>
> >> Because they were originally intended for the gfortran test suite, but I
> >>> couldn't run it
On Wed, Jun 6, 2018 at 3:43 AM, Jerry DeLisle wrote:
> On 06/05/2018 06:58 AM, Rainer Orth wrote:
>
>> Hi Nicolas,
>>
>> Because they were originally intended for the gfortran test suite, but I
>>> couldn't run it there because of libpthread. I will change the numbering
>>> scheme.
>>>
>>
>> the
On 06/05/2018 06:58 AM, Rainer Orth wrote:
Hi Nicolas,
Because they were originally intended for the gfortran test suite, but I
couldn't run it there because of libpthread. I will change the numbering
scheme.
the way that libpthread dependency is currently handled seems weird to
me: right
Hi Nicolas,
> Because they were originally intended for the gfortran test suite, but I
> couldn't run it there because of libpthread. I will change the numbering
> scheme.
the way that libpthread dependency is currently handled seems weird to
me: right now it is only dragged in via -fopenmp,
Hi Dominique and Rainer,
First of all thanks for testing!
Hi Dominique, Nicolas,
I have applied your patch on top of revision r261130 on
x86_64-apple-darwin17 (SSD with APFS file system).
I've tried it on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
I also see two regressions
FAIL:
Hi Dominique, Nicolas,
> I have applied your patch on top of revision r261130 on
> x86_64-apple-darwin17 (SSD with APFS file system).
I've tried it on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
> I also see two regressions
>
> FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
>
>
Hi Nicolas,
I have applied your patch on top of revision r261130 on x86_64-apple-darwin17
(SSD with APFS file system).
The only remaining failure on my own tests is for the test (pr35840)
write(10,*, asynchronous="Y"//"E"//trim("S "))
end
giving at run time
At line 1 of file pr35840.f90
11 matches
Mail list logo