(no subject)

[Mamadou Diop]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

I am a retired scientist and have some fortan programs and looking for an open source fortran compiler.
Regards ?

Mamadou Diop

Envoyé à partir de Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour Windows

Re:

[Arjen Markus]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

Hello,

gfortran is certainly an option, I use an installation from equation.com,
but there are other possibilities as well. The best solution does depend a
bit on your actual requirements.

Regards,

Arjen

Op di 22 aug 2023 om 15:06 schreef Mamadou Diop via Fortran <
fortran@gcc.gnu.org>:

> I am a retired scientist and have some fortan programs and looking for an
> open source fortran compiler.
> Regards ?
>
> Mamadou Diop
>
> Envoyé à partir de Courrier<https://go.microsoft.com/fwlink/?LinkId=550986>
> pour Windows
>
>

Re:

[Richard Biener]

On Wed, Mar 10, 2021 at 8:39 PM mscfd via Fortran <fortran@gcc.gnu.org> wrote:
>
> > which version of gfortran, and which operating system?
> I have seen this on two different Linux distros on x86 with a recently compiled version, but also some time ago with an older gfortran 10 version.
>
> Using helgrind on a simple omp do loop with write to a character variable, I get some possible data races in Libgfortran/io/unit.c. There a newunits array is allocated and possibly reallocated in "newunit_alloc". According to the lock outputs from helgrind I see that this routine is called even if output into character variable is done. Now "newunit_alloc" uses a lock to avoid having several thread all over the place. But newunit_free also writes to newunits array. And this routine does not obtain a lock itself (see comment in unit.c) So in theory it can happen that newunit_alloc reallocated newunits, and newunit_free writes to it just at this time. As I also use 18 threads the initial size of 16 does not suffice and reallocation does probably indeed happen.
> Also acces to newunit_lwi is not protected as well (and complained about by helgrind).
>
> Could it be that the corresponding write routine in transfer.c which calls newunit_free does not obtain the necessary lock. I cannot find it (which does not count much).
>
> Any thoughts?

try obtaining the locks around the places you figured and see if your
problem goes away?

> Martin

Re:

[Arjen Markus]

I tried this with Intel Fortran and that accepts the code as well.
Variations in the code do not resolve the problem (different basic
type for arg, using dimension(:), without the nopass attribute).

I suggest you create a PR for this.

Regards,

Arjen

Op zo 26 jul. 2020 om 06:50 schreef Damian Rouson
<damian@sourceryinstitute.org>:
>
> I believe the gfortran error message below is incorrect.  Gfotran 8, 9 and
> 10 give the same message.  The code below compiles cleanly with the NAG
> Fortran compiler.
>
> Damian
>
> ± cat shape-mismatch.f90
> module foobar
>   type foo
>   contains
>     procedure, nopass :: bar
>   end type
>   interface
>     module subroutine bar(arg)
>       character(len=*) arg(:)
>     end subroutine
>   end interface
> contains
>   module procedure bar
>   end procedure
> end module
>
> ± gfortran -c shape-mismatch.f90
> shape-mismatch.f90:12:22:
>
>    12 |   module procedure bar
>       |                      1
> Error: Shape mismatch in argument 'arg' at (1)
>
> ± gfortran --version
> GNU Fortran (GCC) 10.1.0

Re:

[DavidLNewton]

http://conceptceab.com/chopartisticshaunmitchell/?f2n3l1g6t3x7z1b5v8a1z1

Re:

[DavidLNewton]

http://fsentertainment.nl/arrangementbrilliantstephenmurphy/?g5h9f6v2i9f9z1d8p0n3v3

Re:

[Lee Millward]

Hi Tobias,

On 7/6/07, Tobias Burnus <burnus@ph2.uni-koeln.de> wrote:
> Hi Lee,
>
> I only glanced at your patch.
>
> Lee Millward wrote:
> > * gfortran.dg/cmplx_intrinsic_1.f90
> >       * gfortran.dg/pr32222.f90: New test.
> >       * gfortran.dg/pr32238.f90: New test.
> >       * gfortran.dg/pr32242.f90: New test
>
> You miss something like
> ! { dg-do run }
> or
> ! { dg-do compile }

Isn't this on by default?

> For those test cases with modules, you should add
>
> ! { dg-final { cleanup-modules "MODULE_NAME" } }
>
> to delete the .mod files after compilation.
>

Thanks for that, I didn't know about that directive so I'll add it in
and retest.

Cheers,
Lee.

Re:

[Tobias Burnus]

Hi Lee,

I only glanced at your patch.

Lee Millward wrote:
> * gfortran.dg/cmplx_intrinsic_1.f90
>	* gfortran.dg/pr32222.f90: New test.
>	* gfortran.dg/pr32238.f90: New test.
>	* gfortran.dg/pr32242.f90: New test

You miss something like
! { dg-do run }
or
! { dg-do compile }

For those test cases with modules, you should add

! { dg-final { cleanup-modules "MODULE_NAME" } }

to delete the .mod files after compilation.

Tobias

Re:

[FX Coudert]

> Your patch text was mangled various ways by various mail readers  
> (all off line this afternoon).

And I almost missed your mail because it landed in my spam folder :)

> After I performed the mandatory quarterly Windows repair, and  
> applied the changes in vim, it works for cygwin.
> I'm attempting to attach my reconstruction of your patch, along  
> with the testsuite run prior to patch

I think you meant "after the patch", because otherwise it doesn't  
make sense, as c_by_val_1.f is not flagged as a failure.

I commited the patch to trunk (as rev. 123768), thanks for testing. I  
also saw that gfortran.dg/intrinsic_intkinds_1.f90 is failing, could  
you post the related testsuite log excerpt ($builddir/gcc/testsuite/ 
gfortran/gfortran.log, grep for FAIL)?

Thanks again,
FX

Re:

[Paul Richard Thomas]

FX,

>  30865, 30882, 31011, 30883, 30870, 31163, 30879, 31188

All of these are now cleared - they are most decidedly not regressions;

I did the same with 31163 and 30531.

>  The rule is: "if it ain't a
>  regression (wrt g77 or 4.1), it ain't backported", but we can also
>  decide otherwise for specific cases.

If anybody wants to appeal these as specific cases, I'll be happy to
backport them.

Cheers

Paul

-- 
Saint Augustine - "O Lord, help me to be pure, but not yet"

Re:

[Paul Brook]

On Sunday 07 December 2003 1:47 pm, S. Bosscher wrote:
> > > Implementing ASSIGN probably comes under this category as well.
> >
> > This would go into the g77 compatibility department ?
>
> Yes.
>
> It's also in the top 5 of my TODO list, as you know, since we
> also need it to be able to compile SPEC ;-)

In that case, you might want to consider not using computed gotos (in the C 
sense) to implement this. I'm of the opinion that it would be better to 
translate assigned gotos into select with normal gotos. All assigned goto 
labels must be within the same program unit as the label. It should be 
fairly easy to build an indexed list of targets, and use the index as the 
assigned value and the consdition for the switch.

I haven't actually done any bechmarks, but I would expect the optimizers to 
translate this into code at least as good as using a [C] computed goto. It 
avoids problems on machines where sizeof (void*) > KIND(0), and allows us 
to take advantage of statements like
GOTO foo (100, 200)

Paul