Re:

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

Re:Updating the TO DO list.

[Feng Wang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312, Size: 1437 bytes --]


 --- Paul Brook <paul@codesourcery.com> µÄÕýÎÄ£º> 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)
>
I have implemented ASSIGN, assigned goto and the integer variable can be used
in i/o statements. But it is still at test. ASAP I will give the patch.

> Paul
>  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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:

[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:

[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:

[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:

[DavidLNewton]

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

Re:

[DavidLNewton]

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

(no subject)

[Damian Rouson]

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:

[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

(no subject)

[mscfd]

> 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?
Martin

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

(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
>
>