headers
Jerry DeLisle | 1 Jul 2006 07:18
Picon

[patch,libgfortan] Fis PR27704 Incorrect runtime error on multiple OPEN

:ADDPATCH fortran:

After reviewing the thread referenced in the PR and reviewing the standards, 
this patch fixes this PR by doing two things.

1. On multiple opens, status="scratch" is allowed as an extension.  This is 
accomplished by using notify_std.

2. On multiple opens, status="old" is allowed as permitted by the f95 standard.

Finally as an enhancement, I have modified notify standard to be consistent with 
generate_error and show the locus of the warning or error as appropriate.

The attached test case is given.  Also, fmt_l.f90 will be modified to accomodate 
  the output of the locus.

NOTE: There is some overlap between this patch and FX RFC library cleanup patch. 
  I was looking at FX patch after I finished this one and noticed the proposed 
move notify_std prototype to libgfortran.h.

FX, if you prefer I wait for yours to be OKed and committed, I will redo this 
patch to line up, otherwise, I can commit this one first.  Let me know.

Regression tested.

OK for trunk and 4.1 later?

Regards,

Jerry
(Continue reading)

Permalink | Reply | 8 comments |
headers
FX Coudert | 1 Jul 2006 09:49
Picon

Re: [patch,libgfortan] Fis PR27704 Incorrect runtime error on multiple OPEN

> NOTE: There is some overlap between this patch and FX RFC library 
> cleanup patch.  I was looking at FX patch after I finished this one and 
> noticed the proposed move notify_std prototype to libgfortran.h.
> 
> FX, if you prefer I wait for yours to be OKed and committed, I will redo 
> this patch to line up, otherwise, I can commit this one first.  Let me 
> know.

I have had no positive feedback on my library cleanup patch so I'll wait 
for branching before commiting it.

FX
Permalink | Reply | 0 comments |
headers
Christopher Faylor | 1 Jul 2006 17:56

Re: Notes of the libgcc-math BOF at the summit.

On Fri, Jun 30, 2006 at 02:57:19PM +0200, Richard Guenther wrote:
>Issues of providing both standard conforming and target optimized
>math runtimes for GCC were discussed.

Thanks for posting this.  Since I wasn't able to attend the summit this
year, I really appreciate seeing summaries like this.

cgf
Permalink | Reply | 0 comments |
headers
Paul Thomas | 1 Jul 2006 18:56
Picon

Re: [Patch, fortran] PR28174 - actual args with substring refs and PR28167 - character array constructors

Ping!

> Dominique,
>
>> Paul,
>>
>> In the test gcc/testsuite/gfortran.dg/actual_array_substr_2.f90, are 
>> you that the line:
>>
>>    if (all (x(:)(3:7) .eq. y)) call abort ()
>
This line will be removed: it serves to test the inner workings of the 
patch but is not required by f95.

Thanks, Dominique!

Paul
Permalink | Reply | 0 comments |
headers
Jorge D'elia | 1 Jul 2006 19:32
Picon

64-bit gfortran: troubles with the binaries distributions

Dear GFORTRAN developers,

It is a very good idea the gfortran compiler project for Linux users. 
I try to install the packages for 32 and 64 bit processors from the page

http://gcc.gnu.org/wiki/GFortranBinaries 

where

1) The 32-bit package was downloaded following the link
   "For regular 32-bit processors (i386), download this package"
   http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz
   This installation in a 32-bit PC was sucessfull.

2) But I failed with some of the 64-bit packages following the text
   "For 64-bit AMD-compatible processors (x86_64), download this package"

   http://www.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-trunk-x86_64.tar.gz

   or from the "(directory view)"

   http://www.physik.fu-berlin.de/~tburnus/gcc-trunk/

   where I tried with some binaries of the "Other nightly x86_64 build of 
   gfortran" text, for instance

   http://quatramaran.ens.fr/~coudert/gfortran
   /gfortran-x86_64-linux-20060701.tar.gz

   I followed the "detailed instructions" but any installation was sucessfull
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Prince | 1 Jul 2006 19:31
Picon
Favicon

Re: 64-bit gfortran: troubles with the binaries distributions

Jorge D'elia wrote:
> Dear GFORTRAN developers,
> 
> It is a very good idea the gfortran compiler project for Linux users. 
> I try to install the packages for 32 and 64 bit processors from the page
> 
> http://gcc.gnu.org/wiki/GFortranBinaries 
> 
> where
> 
> 1) The 32-bit package was downloaded following the link
>    "For regular 32-bit processors (i386), download this package"
>    http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz
>    This installation in a 32-bit PC was sucessfull.
>  
> 2) But I failed with some of the 64-bit packages following the text
>    "For 64-bit AMD-compatible processors (x86_64), download this package"
> 
>    http://www.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-trunk-x86_64.tar.gz
>  
>    or from the "(directory view)"
> 
>    http://www.physik.fu-berlin.de/~tburnus/gcc-trunk/
> 
>    where I tried with some binaries of the "Other nightly x86_64 build of 
>    gfortran" text, for instance
> 
>    http://quatramaran.ens.fr/~coudert/gfortran
>    /gfortran-x86_64-linux-20060701.tar.gz
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Thomas | 2 Jul 2006 07:00
Picon

Re: 64-bit gfortran: troubles with the binaries distributions

Jorge,

Both gmp and mpfr build from source with no difficulty.  In fact, last 
night it took me 15 minutes to do so for a new system.  For both the 
default configurations are fine, so "./configure", "make" and "make 
install" are all you need to do.  It's worthwhile patching the source 
for mpfr, as in the instructions on the download page.  A message was 
emitted, during the configure of mpfr, that the version of gmp was 
apparently incompatible but this has had no effect.

Paul
Permalink | Reply | 0 comments |
headers
François-Xavier Coudert | 3 Jul 2006 15:17
Picon

ATTRIBUTE_UNUSED on used arguments...

While reading through iresolve.c, I noticed two uses of
ATTRIBUTE_UNUSED on a argument that seems to be used. As I don't want
to do anything stupid and I might be missing an obvious point here,
I'm asking for someone to give it a quick look: they are in functions
gfc_resolve_cpu_time and gfc_resolve_random_number.

I plan to commit the following patch after someone can confirm that it
isn't completely stupid:

Index: iresolve.c
===================================================================
--- iresolve.c  (revision 114972)
+++ iresolve.c  (working copy)
 <at>  <at>  -2219,7 +2219,7  <at>  <at> 
 }

 void
-gfc_resolve_cpu_time (gfc_code * c ATTRIBUTE_UNUSED)
+gfc_resolve_cpu_time (gfc_code * c)
 {
   const char *name;

 <at>  <at>  -2243,7 +2243,7  <at>  <at> 

 void
-gfc_resolve_random_number (gfc_code * c ATTRIBUTE_UNUSED)
+gfc_resolve_random_number (gfc_code * c)
 {
   const char *name;
   int kind;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Kargl | 3 Jul 2006 17:58
Picon

Re: ATTRIBUTE_UNUSED on used arguments...

On Mon, Jul 03, 2006 at 03:17:03PM +0200, Fran?ois-Xavier Coudert wrote:
> While reading through iresolve.c, I noticed two uses of
> ATTRIBUTE_UNUSED on a argument that seems to be used. As I don't want
> to do anything stupid and I might be missing an obvious point here,
> I'm asking for someone to give it a quick look: they are in functions
> gfc_resolve_cpu_time and gfc_resolve_random_number.
> 

Patch looks correct to me.  Please commit.

--

-- 
Steve
Permalink | Reply | 1 comment |
headers
François-Xavier Coudert | 3 Jul 2006 18:08
Picon

Re: ATTRIBUTE_UNUSED on used arguments...

> Patch looks correct to me.  Please commit.

Commited on mainline and 4.1.

FX
Permalink | Reply | 0 comments |

Gmane