headers
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).
(Continue reading)

Permalink | Reply | 3 comments |
headers
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
Permalink | Reply | 2 comments |
headers
Paul Brook | 26 Sep 02:14
Gravatar

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
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
Permalink | Reply | 0 comments |
headers
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
Permalink | Reply | 0 comments |
headers
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!
(Continue reading)

Permalink | Reply | 1 comment |
headers
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)

Permalink | Reply | 25 comments |
headers
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.
(Continue reading)

Permalink | Reply | 550 comments |
headers
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
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)

Permalink | Reply | 2 comments |

Gmane