headers
Paul Brook | 14 Oct 2003 00:40
Gravatar

[gfortran] Functions returning arrays using wrong calling convention

We were missing the fact that a function returned an array when resolvind 
module procedures. The lead to us using the wrong calling convention.

Patch below applied to tree-ssa branch.

Paul

2003-10-11  Paul Brook  <paul <at> nowt.org>

	* resolve.c (resolve_formal_arglist): Use function result decl in
	preference to function decl.
testsuite
	* gfortran.fortran-torture/execute/retarray_2.f90: New test.

--- clean/tree-ssa/gcc/fortran/resolve.c
+++ gcc/gcc/fortran/resolve.c
 <at>  <at>  -60,9 +60,14  <at>  <at>  resolve_formal_arglist (gfc_symbol * pro

   /* TODO: Procedures whose return character length parameter is not 
constant
      or assumed must also have explicit interfaces.  */
+  if (proc->result != NULL)
+    sym = proc->result;
+  else
+    sym = proc;
+
   if (gfc_elemental (proc)
-      || proc->attr.pointer || proc->attr.allocatable
-      || (proc->as && proc->as->rank > 0))
+      || sym->attr.pointer || sym->attr.allocatable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Brook | 14 Oct 2003 00:42
Gravatar

Re: [gfortran] error in results

On Sunday 12 October 2003 9:13 pm, tcc <at> sentex.net wrote:
> The following code produces erroneous results.
> Hth,
> Douglas Cox

Fixed.

Paul

>  module arrz
>  contains
> function z(a_in,d) result (aout)
> integer :: d
> real :: a_in(d),aout(d)
> aout = a_in*2.0 + 1.0
> end function z
> end module arrz
>
> program testz
> use arrz
> real, dimension(4) :: a = (/ 1.,2.,3.,4. /), b
> integer :: d = 4
> b =  z(a,d)
> print*, b
> end
Permalink | Reply | 0 comments |
headers
Paul Brook | 14 Oct 2003 01:26
Gravatar

[gfortran] Work around frontend bugs.

For various reasons the gfortran parser sometimes creates symbols for 
variables which don't exist. This is fairly harmless, except that things 
fall over later on when we try and create tree nodes for these incomplete 
symbols.

The proper fix would be to avoid createing/adding these symbols. Until such 
a fix appears I've worked around it by ignoring any obviously broken 
symbols.

Applied to tree-ssa branch.

Paul

2003-10-13  Paul Brook  <paul <at> nowt.org>

	* trans-decl.c (generate_local_decl): Don't create junk variables.

--- clean/tree-ssa/gcc/fortran/trans-decl.c
+++ gcc/gcc/fortran/trans-decl.c
 <at>  <at>  -1768,6 +1768,17  <at>  <at>  generate_local_decl (gfc_symbol * sym)
 {
   if (sym->attr.flavor == FL_VARIABLE)
     {
+      /* TODO: The frontend sometimes creates symbols for things which 
don't
+         actually exist.  E.g. common block names and the names of formal
+	 arguments.  The latter are created while attempting to parse
+	 the argument list as a substring reference.
+
+	 The proper fix is to avoid adding these symbols in the first place.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toby White | 14 Oct 2003 16:33
Picon
Picon
Favicon

ICE (array operations)

parabrisas% cat atmfuncs2.f

      subroutine all_phi(nphi)
      integer, intent(out):: nphi

      integer maxlm
      double precision  rmod

      integer, parameter :: maxphi=100

      integer :: ilm(maxphi)
      double precision :: rmax(maxphi)
      logical :: within(maxphi)

      within(1:nphi) = ( rmax(1:nphi) > rmod )
      maxlm = maxval( ilm(1:nphi), mask=within(1:nphi) )

      end subroutine all_phi

parabrisas% gfortran -xf95 atmfuncs2.f                  3:32PM
atmfuncs2.f: In function `all_phi':

atmfuncs2.f:15: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

--

-- 
Dr. Toby White, Dept. of Earth Sciences, Downing Street, Cambridge CB2 3EQ. UK
Email: <tow21 <at> cam.ac.uk>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Zender | 15 Oct 2003 01:31
Picon
Favicon
Gravatar

ICE on iargc()/command_argument_count() etc.

Hi,

I am using CVS gfortran sources from 20031014 on debian unstable i686.

The following fortran90 code shows that neither
command_argument_count(), nor the old backward compatibility function
iargc() work. Presumably nor do getarg() and get_command_argument().
Andy Vaught has implemented iargc() and getarg() in g95.
If someone ports that to gfortran, then I will help test gfortran as
well as g95. 

Thanks!
Charlie

program tst
!  print *, iargc()
  print *, command_argument_count()
end program tst

With command_argument_count():
zender <at> ashes:~/f$ gfortran --version
GNU Fortran 95 (GCC 3.5-tree-ssa 20031014 (merged 20031005))
Copyright (C) 2003 Free Software Foundation, Inc.
zender <at> ashes:~/f$ gfortran -o tst tst.f90
/tmp/cc2IusfD.o(.text+0x3b): In function `MAIN__':
: undefined reference to `command_argument_count__'
collect2: ld returned 1 exit status

With iargc():
zender <at> ashes:~/f$ gfortran -o tst tst.f90
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Kargl | 15 Oct 2003 02:17
Picon

Re: ICE on iargc()/command_argument_count() etc.

On Tue, Oct 14, 2003 at 04:31:31PM -0700, Charlie Zender wrote:
> 
> The following fortran90 code shows that neither
> command_argument_count(), nor the old backward compatibility function
> iargc() work. Presumably nor do getarg() and get_command_argument().

None of these functions are part of the Fortran 95
standard.  The current effort is to implement a 
functioning Fortran 95 compiler.  Once this is
finished adding convenience features will probably 
be undertaken.

BTW, what to you mean by "old backward compatibility
function iargc()"?  iargc() has never been a part of
a Fortran standard.

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Lars Segerlund | 15 Oct 2003 13:56
Picon

A little help needed ..


 I am looking at intrinsic modules for g95, and I have gotten so far as to look through the module interface, (
the files and part of the internal handling ).

 What I have concluded is that it just might be possible to do a fairly straight implementation of intrinsic
modules, ( since only a couple is defined), by using regular .mod files and perhaps a small part in the lib.

 What I would like to know is if anybody have a good tip on where to start looking at the internal type handling.

 It looks like it will be necessary to generate C function calls from intrinsic modules in most cases, ( both
ieee and the C bindings seems to need it ).  So am I right about my assumptions that these modules would be very
hard to, ( or not very optimal), generate as regular modules ?

 I think I will make a first go and then think it all over, since it all has to sink in ...

 I also have a question about backward compability with g77, perhaps it would be nice to have a list with
compability features supported/unsupported ? This way there might be some nice soul's willing to get
started on that part ? ( perhaps even some of the g77 hackers ? ).

 / regards, Lars Segerlund.
Permalink | Reply | 2 comments |
headers
Toon Moene | 15 Oct 2003 20:07
Picon

Re: A little help needed ..

Lars Segerlund wrote:

>  I also have a question about backward compability with g77, 
> perhaps it would be nice to have a list with compability features
> supported/unsupported ?

> This way there might be some nice soul's willing to get started on that part ?
> ( perhaps even some of the g77 hackers ? ).

Yes, I was thinking about adding a category (g77 compatibility) to our 
TODO list once the web pages were approved (I still get checking errors 
on some of them).

--

-- 
Toon Moene - mailto:toon <at> moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)
Permalink | Reply | 0 comments |
headers
Toon Moene | 16 Oct 2003 19:47
Picon

Re: [G95] ICE in IA64

Feng Wang wrote:

> ICE in ia64 linux enviroment.

You can enter bug reports for gfortran/g95 in GCC's bugzilla database
(see the home page of GCC, http://gcc.gnu.org, left column).

Please use the mailing list fortran <at> gcc.gnu.org for new discussions.

Thanks,

--

-- 
Toon Moene - mailto:toon <at> moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)
Permalink | Reply | 0 comments |
headers
Toon Moene | 16 Oct 2003 22:32
Picon

Re: [G95] Cygwin g95

Feng Wang wrote:

[ ... MINLOC / MAXLOC ... ]

> Yes, they are implemented. I tested them in
> i686-pc-linux and passed. Maybe there are some I/O
> bugs in Cygwin.

I tried the following small test program on powerpc-unknown-linux-gnu
with yesterday's compiler:

$ cat minloc.f95
dimension i(1), v(3)
v = (/ 40.0, 25.0, 10.0 /)
print*,v
i = minloc(v)
print*,i
end

and it gives:

$ /usr/tsa/bin/gfortran -static minloc.f95
$ ./a.out
   40.00000        25.00000         10.00000
           0

So the array constructor works; however, minloc shouldn't be 0, but 3.

Hope this helps,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane