Steve Kargl | 26 Sep 01:34
Picon

Re: GNU Fortran

On Sun, Sep 25, 2005 at 04:21:19PM -0700, Alexander Verhaeghe wrote:
> Hello,
> 
> I downloaded GNU Fortran and I have a lot of trouble
> with it. There is no decent explanation on how this
> works, a lot of info which is not usefull. Not all
> Fortran code is supported, MODULE statement? USE
> statement? global constants? global structs?,

What exactly did you download?

> interface with Win32 all features that apparently do
> not work with GNU Fortran, a lot of questions
> unanswered. If I have to look hours to find this and
> still didn't find anything, then something is wrong!
> Free software may be good, but most of the time,
> explanation is (very?) poor, almost never a decent
> IDE, no samples, ... Microsoft and Borland they have
> at least very good editors and complete environments
> and big KB. Of course You cannot do that since it's
> free. That's the price I guess we have to pay for
> having no support. I'm wondering is this usefull?

Your rant is not useful.  No one is forcing you to
use gfortran (or more likely g77).  If you're happy
with Borland's Fortran compiler then use it (of course,
Borland doesn't have a Fortran compiler).  If you're
happy with Microsoft's Fortran compiler, then use it
(of course, Microsoft doesn't have a Fortran compiler).

--

-- 
Steve

(Continue reading)

Andrew Pinski | 26 Sep 01:38
Picon

Re: GNU Fortran


On Sep 25, 2005, at 7:34 PM, Steve Kargl wrote:


> If you're happy with Microsoft's Fortran compiler, then use it > (of course, Microsoft doesn't have a Fortran compiler).
Microsoft had a fortran compiler, I think they still do. -- Pinski
Paul Brook | 26 Sep 02:14
Favicon

Re: [patch, fortran] Unformatted array IO performance improvement

> Anyway, I found the reason: The size of the array elements is stored
> in "index_type dtype" in the descritor, and the size is retrieved by
> shifting 6 bits to the right. Thus on 32-bit platforms the maximum
> size is 2**24, or 16 MB. Is there any practical need for arrays of >16
> MB characters, or can we say this is an implementation limit and
> nobody will care?
>
> > Can you pass the length of a character array the same way that
> > the recent patches to the reshape arrays introduced?
>
> You mean a transfer_array_char library entry point with an extra
> argument specifying the length of the characters, and leaving the size
> in the descriptor for sizeof(char)=1? Yes, I guess that would be one
> way. 

This is the correct solution. When writing the array descriptor stuff I got 
this wrong. The descriptor field should be the character kind, not the 
length.

> Another could be to simply make the dtype field 64 bits on all 
> platforms.
>
> >  I think this
> > would also be more consistent with the size of an array not being
> > consistent with its string length.
>
> Hmm, I think support for non-8-bit chars will require some major
> surgery of the formatted transfer routines. I'm not sure I want to go
> there now.

Maybe not, but it would be nice to get to a state where it could be 
implemented without changing the format of array descriptors, preferably 
without changing the ABI at all.

Paul

(Continue reading)

Steve Kargl | 26 Sep 02:32
Picon

Re: GNU Fortran


On Sun, Sep 25, 2005 at 07:38:28PM -0400, Andrew Pinski wrote: > > On Sep 25, 2005, at 7:34 PM, Steve Kargl wrote: > > >If you're happy with Microsoft's Fortran compiler, then use it > >(of course, Microsoft doesn't have a Fortran compiler). > > Microsoft had a fortran compiler, I think they still do. >
Microsoft hasn't sold a Fortran compiler for a long time. Microsoft got out of the market when Digital released Digital Visual Fortran (DVF), which became Compaq Visual Fortran (CVF), which was subsequently merged with (or replaced by) Intel Visual Fortran (IVF). -- -- Steve
Jerry DeLisle | 26 Sep 03:10
Picon

Status on older regressions

Hi folks,

I have tried Janne's latest patches and all looks good here!  What progress we 
have seen in just the last month or so.  Congratulations to everyone!

I have a few question about the test results:

                 === gfortran Summary ===

# of expected passes            9508
# of unexpected failures        2
# of expected failures          4
# of unsupported tests          8

The two unexpected failures are in elemental.f90.  I know there is a pr out for 
that but was wondering if anyone was working on it?  Is there a time line or 
target release for this?

Secondly,

How are the expected failures marked as such?  Are they marked in the test files 
themselves so that I may grep for them.  I am curious about the 4 expected 
failures since these have been showing here for a long time.

Thanks for info,

Jerry

Brooks Moses | 26 Sep 04:46
Picon
Favicon

Re: GNU Fortran

Alexander Verhaeghe wrote:
> I downloaded GNU Fortran and I have a lot of trouble
> with it. There is no decent explanation on how this
> works, a lot of info which is not usefull.

Where did you download it from?

Where did you look for an explanation on how it works?

GNU Fortran is free software.  That means that people are free to 
repackage it and redistribute it, and a lot of people do.  Thus, there 
are many places you could have downloaded it from, and many places you 
could have looked for explanations, and many of them aren't up-to-date 
or particularly complete.  We have no way of knowing where the problem 
is if you don't give us actual details.

> Not all
> Fortran code is supported, MODULE statement? USE
> statement? global constants? global structs?,
> interface with Win32 all features that apparently do
> not work with GNU Fortran, a lot of questions
> unanswered.

The current version of GNU Fortran, as available on all of the official 
download sites, supports all of these things.  (Except, maybe, some of 
the Win32 interface things -- I'm not sure what you're asking for there, 
as the Fortran 95 standard does not mention Win32.)

> If I have to look hours to find this and
> still didn't find anything, then something is wrong!

Yes, something is wrong.

Without you telling us what methods you looked to find, and what you 
looked at, it's impossible to tell what is wrong, however.

For instance, did you look at the official GNU Fortran webpage, which 
contains links to a number of methods to download the latest releases, 
and to the official documentation for the program?  It's here:
   http://gcc.gnu.org/fortran

If you looked at that, what particular questions do you have that it 
(Continue reading)

Alan Modra | 26 Sep 05:24
Picon

gfortran.dg/large_real_kind_1.f90

I've been playing with enabling 128-bit long doubles for
powerpc64-linux, and noticed large_real_kind_1 failing.  A little
investigation says either the test is broken, or libgfortranio/write.c
write_float needs tweaking.  In case of the former, the following
adjusts the test to suit current output.  Of course, I might also be
completely off-base, and '(G20.10E5)' should output something other than
'           +Infinity' for huge(x).

	* gfortran.dg/large_real_kind_1.f90: Tweak for +/-Infinity output.

Index: gcc/testsuite/gfortran.dg/large_real_kind_1.f90
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gfortran.dg/large_real_kind_1.f90,v
retrieving revision 1.1
diff -u -p -r1.1 large_real_kind_1.f90
--- gcc/testsuite/gfortran.dg/large_real_kind_1.f90	23 Jun 2005 18:50:19 -0000	1.1
+++ gcc/testsuite/gfortran.dg/large_real_kind_1.f90	26 Sep 2005 03:20:21 -0000
@@ -61,8 +61,8 @@ program test

   write (c1,'(G20.10E5)') x
   write (c2,'(G20.10E5)') -x
-  if (c2(1:1) /= '-') call abort
-  c2(1:1) = ' '
+  if (c2(12:12) /= '-') call abort
+  c2(12:12) = '+'
   if (c1 /= c2) call abort

   x = tiny(x)

--

-- 
(Continue reading)

Paul Thomas | 26 Sep 06:45
Picon

Re: [PATCH, fortran] Constraints for equivalence members and private types - Ping

I know that preventing gfortran from doing things might not be the 
flavour of the month but might I remind you all of this patch and a 
question it contained?

>As a general remark, I had started to implement the constraints in symbol.c(check_conflict) but found
that the majority of the equivalence constraints were to be found in resolve.c. I therefore elected to put
the rest there too.
>
In fact it was not just the majority but all those that could not be put 
in match.c.  ASFAIK the reason is that half of the constraints, which 
involve more than one symbol, sit most naturally in resolve.c and the 
single symbol constraints have been put with them for convenience.  I 
have a version ready to go that puts these latter in check_conflict.

Note that both versions exist and so it would be no extra work to submit 
either.  What do you want?

>
>I have only made the constraint on equivalence mixing of numeric/character/structure subject to the
-std=f95 option for g77 compatibility. I do not think that this would make any sense for any of the others
but I am open to suggestions there.
>
I have moved on with this point, having re-read the F95 standard.  I 
have now implemented a check of sequences to see of what type they are 
and allow numeric[/character] sequences to be mixed with 
numeric[/character] variables, when -std=f95 is used.  I have not 
checked that the types are default.

This patch will, therefore, be resubmitted tonight or tomorrow.

Best regards

Paul T

(Continue reading)

Paul Thomas | 26 Sep 06:48
Picon

Re: [Patch, fortran] Fix for PR23446 - Ping


Paul Thomas wrote: > :ADDPATCH fortran: > > This one is relatively easy: check_restricted was being too restrictive > when checking indices of formal argument lists. Since several levels of > indirection are positioned between the information that this is a formal > argument list and the error, a flag and an interface function are > deployed. > > The testcase checks the correct functioning for three different forms of > assumed shape array in a contained procedure. > > Bubblestrapped and regtested on FC3/Athlon1700. > > OK for mainline and 4.03, when open? > > Paul T > > =================================================================== > > 2005-09-21 Paul Thomas <pault <at> gcc.gnu.org> > > PR fortran/23446 > * gfortran.h: Primitive for gfc_is_formal_arg. > * resolve.c(gfc_is_formal_arg): New function to signal across > several function calls that formal argument lists are being > processed. > (resolve_formal_arglist): Set/reset the flag for gfc_is_formal_arg. > *expr.c(check_restricted): Add check, via gfc_is_formal_arg, if > symbol is part of an formal argument declaration. > > 2005-09-21 Paul Thomas <pault <at> gcc.gnu.org> > > PR fortran/23446 > * gfortran.dg/host_dummy_index_1.f90: New test. > > > > Index: gcc/gcc/fortran/gfortran.h > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/fortran/gfortran.h,v > retrieving revision 1.87 > diff -c -p -r1.87 gfortran.h > *** gcc/gcc/fortran/gfortran.h 17 Sep 2005 18:57:59 -0000 1.87 > --- gcc/gcc/fortran/gfortran.h 21 Sep 2005 20:35:32 -0000 > *************** int gfc_elemental (gfc_symbol *); > *** 1793,1798 **** > --- 1793,1799 ---- > try gfc_resolve_iterator (gfc_iterator *, bool); > try gfc_resolve_index (gfc_expr *, int); > try gfc_resolve_dim_arg (gfc_expr *); > + int gfc_is_formal_arg (void); > > /* array.c */ > void gfc_free_array_spec (gfc_array_spec *); > Index: gcc/gcc/fortran/resolve.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/fortran/resolve.c,v > retrieving revision 1.54 > diff -c -p -r1.54 resolve.c > *** gcc/gcc/fortran/resolve.c 18 Sep 2005 05:50:01 -0000 1.54 > --- gcc/gcc/fortran/resolve.c 21 Sep 2005 20:35:39 -0000 > *************** static code_stack *cs_base = NULL; > *** 43,48 **** > --- 43,58 ---- > > static int forall_flag; > > + /* Nonzero if we are processing a formal arglist. The corresponding > function > + resets the flag each time that it is read. */ > + static int formal_arg_flag = 0; > + > + int > + gfc_is_formal_arg (void) > + { > + return formal_arg_flag; > + } > + > /* Resolve types of formal argument lists. These have to be done > early so that > the formal argument lists of module procedures can be copied to the > containing module before the individual procedures are resolved > *************** resolve_formal_arglist (gfc_symbol * pro > *** 71,76 **** > --- 81,88 ---- > || (sym->as && sym->as->rank > 0)) > proc->attr.always_explicit = 1; > > + formal_arg_flag = 1; > + > for (f = proc->formal; f; f = f->next) > { > sym = f->sym; > *************** resolve_formal_arglist (gfc_symbol * pro > *** 217,222 **** > --- 229,235 ---- > } > } > } > + formal_arg_flag = 0; > } > > > Index: gcc/gcc/fortran/expr.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/fortran/expr.c,v > retrieving revision 1.29 > diff -c -p -r1.29 expr.c > *** gcc/gcc/fortran/expr.c 17 Sep 2005 18:57:59 -0000 1.29 > --- gcc/gcc/fortran/expr.c 21 Sep 2005 20:35:42 -0000 > *************** check_restricted (gfc_expr * e) > *** 1679,1685 **** > || sym->attr.dummy > || sym->ns != gfc_current_ns > || (sym->ns->proc_name != NULL > ! && sym->ns->proc_name->attr.flavor == FL_MODULE)) > { > t = SUCCESS; > break; > --- 1679,1686 ---- > || sym->attr.dummy > || sym->ns != gfc_current_ns > || (sym->ns->proc_name != NULL > ! && sym->ns->proc_name->attr.flavor == FL_MODULE) > ! || gfc_is_formal_arg ()) > { > t = SUCCESS; > break; > > > ===============host_dummy_index_1.f90=============== > > ! { dg-do run } > ! Tests the fix for PR23446. > ! > ! Contributed by Paul Thomas <pault <at> gcc.gnu.org> > ! > PROGRAM TST > INTEGER IMAX > INTEGER :: A(4) = 1 > IMAX=2 > > CALL S(A) > CALL T(A) > CALL U(A) > if ( ALL(A.ne.(/2,2,3,4/))) CALL ABORT () > > CONTAINS > SUBROUTINE S(A) > INTEGER A(IMAX) > a = 2 > END SUBROUTINE S > SUBROUTINE T(A) > INTEGER A(3:IMAX+4) > A(5:IMAX+4) = 3 > END SUBROUTINE T > SUBROUTINE U(A) > INTEGER A(2,IMAX) > A(2,2) = 4 > END SUBROUTINE U > ENDPROGRAM TST > > > >
(Continue reading)

Janne Blomqvist | 26 Sep 08:14
Picon
Picon

Re: [patch, fortran] Unformatted array IO performance improvement

On Sun, Sep 25, 2005 at 09:55:34PM +0200, Thomas Koenig wrote:
> On Sun, Sep 25, 2005 at 09:26:45PM +0300, Janne Blomqvist wrote:
> > :ADDPATCH fortran:
> > 
> > Ok, here is yet another updated version of the patch. The most
> > significant difference compared to previous versions is that the
> > transfer_array library entry point now has a second argument 'charlen'
> > which specifies the length of the characters in case the type is
> > character. For non-character types the frontend just generates a
> > constant which is not used. This extra argument is needed because the
> > charlen which is stored in the descriptor is clobbered if charlen >
> > 2**24. It also makes it possible to support non-8-bit charset later on
> > if we wish.
> 
> This is OK for mainline.

Great! Could someone commit it, as I don't have commit privileges?

> This should pretty much lay PR 16339 and 21820
> to rest (maybe you could mention them in the ChangeLog).

I guess you mean 16339 and 23363? 

21820 uses implied do loops, so doesn't use transfer_array(). 21820
was significantly improved by my recent already committed patch that
got rid of mmap. We still lose to ifort though, so I don't know if it
should be kept open or not.

--

-- 
Janne Blomqvist

(Continue reading)


Gmane