headers
Feng Wang | 1 Dec 2003 05:02
Picon

[gfortran, patch] Old patches needed to apply.

Hi, Paul
   I think the two patches you said ok have not applied 
yet. Please help me apply. I have no CVS access writing.
Thanks.

The first Changelog entry:

2003-12-01  Feng Wang  <fengwang <at> nudt.edu.cn>

       * gfortran.fortran-
torture/excute/intrinsic_fraction_exponent.f90: Fix an 
error about checking the equal of floating point 
numbers and a return type error of EXPONENT intrinsic 
function.
       * gfortran.fortran-
torture/excute/intrinsic_scale.f90: Fix an error about 
checking the equal of floating point numbers and delete 
a variable.

The second:

2003-12-01  Feng Wang  <fengwang <at> nudt.edu.cn>

        * io.c (gfc_match_format): Check if missing 
format label.

  Feng Wang


(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Dan Nicolaescu
 | 
1 Dec 2003 07:41






Picon





compiling SPEC2000 and SPEC95 with gfortran



I tried to compile the fortran (both f77 and f90) benchmarks from
SPEC2k and 95 with gfortran.

Things look quite good!

From 168.wupwise, 171.swim, 172.mgrid, 173.applu from SPEC2000 and 
101.tomcatv, 102.swim, 107.mgrid, 125.turb3d, 141.apsi, 145.fpppp
from SPEC95 compile just fine. I haven't tried to run any of the
binaries.

178.galgel, 187.facerec, 189.lucas, 191.fma3d, 200.sixtrack, 301.apsi from SPEC2000
and 103.su2cor, 104.hydro2d, 110.applu, 146.wave5 from SPEC95 had various
issues:

- some needed some unimplemented features: 
        gfc_todo: Not Implemented: arrays of strings
        gfc_todo: Not Implemented: Unable to find scalarization loop specifier
        gfc_todo: Not Implemented: CHARACTER inside COMMON or EQUIVALENCE

- some had various compilation problems, problems that are reflected in
  the following PRs:
	http://gcc.gnu.org/PR13248
	http://gcc.gnu.org/PR13249
	http://gcc.gnu.org/PR13251
	http://gcc.gnu.org/PR13253
	http://gcc.gnu.org/PR13254
	http://gcc.gnu.org/PR13255
	http://gcc.gnu.org/PR13257


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Paul Brook
 | 
2 Dec 2003 00:21






Gravatar





Re: [gfortran, patch] Old patches needed to apply.


On Monday 01 December 2003 4:02 am, Feng Wang wrote:
> Hi, Paul
>    I think the two patches you said ok have not applied
> yet. Please help me apply. I have no CVS access writing.
> Thanks.

Applied.

If you do need patches applying rather then just approving, please say so 
when you submit the patches. I loose track of who has write access to CVS 
and who doesn't.

Paul







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Jiri Pittner
 | 
2 Dec 2003 14:36






Picon





option for default 64-bit integers on Opteron and itanium



Dear gcc and gnu fortran developers,

I would like to ask whether there are already plans  / if not then to suggest
implementation of the following functionality specific to 64-bit architecture
AMD Opteron and Intel Itanium:

Some large old number crunching codes written mainly in  Fortran 77
combined with a bit of C have to be translated so that variables
declared (implicitly) as integer or int in C are translated as 64-bit integers,
otherwise one cannot fully benefit of the 64-bit hardware, or even the code
does not run at all (due to the usual array offset trick used in Fortran 77
to access malloc()ed memory).

Commercial compilers (Intel, Portland group) offer such option called
usually -i8, and similar one -r8 which makes real*4 -> real*8.

I think this feature would be very useful to many people who do scientific computation.

With best regards,

Jiri Pittner







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Paul Brook
 | 
2 Dec 2003 15:01






Gravatar





Re: option for default 64-bit integers on Opteron and itanium


On Tuesday 02 December 2003 1:36 pm, Jiri Pittner wrote:
> Commercial compilers (Intel, Portland group) offer such option called
> usually -i8, and similar one -r8 which makes real*4 -> real*8.

gfortran does supports both these, except the commandline swith to enable it 
seems to be broken. The corresponding 128-bit double precision types are 
only partially implemented, although adding the required intrinsics is a 
fairly straighforward task.
Your desctiption of the effect of -r8 is slightly innaccuate. It changes the 
default real kind to 8. real*4 and real(kind=4) are still 32-bit types.

Paul







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Jiri Pittner
 | 
2 Dec 2003 15:15






Picon





Re: Re: option for default 64-bit integers on Opteron and itanium



Dear Paul,

thanks for information.

> > Commercial compilers (Intel, Portland group) offer such option called
> > usually -i8, and similar one -r8 which makes real*4 -> real*8.
> 
> gfortran does supports both these, except the commandline swith to enable it 
> seems to be broken. The corresponding 128-bit double precision types are 
> only partially implemented, although adding the required intrinsics is a 
> fairly straighforward task.
Do you mean the command line frontend gcc/g77 or the command line arguments
of the actual compiler executables? Is there any simple way around how to get 
the functionality?
I do not need any 128-bit ones.

> Your desctiption of the effect of -r8 is slightly innaccuate. It changes the 
> default real kind to 8. real*4 and real(kind=4) are still 32-bit types.
You are right, I meant just the change of the default. Actually I do not need this one anyway.

Jiri







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Paul Brook
 | 
2 Dec 2003 15:40






Gravatar





Re: option for default 64-bit integers on Opteron and itanium


On Tuesday 02 December 2003 2:15 pm, Jiri Pittner wrote:
> Do you mean the command line frontend gcc/g77 or the command line
> arguments of the actual compiler executables? Is there any simple way
> around how to get the functionality?

It's the dirver executable (ie. gcc/gfortran) that looses/rejects the 
switches because they don't conform to the normal conventions for code 
generations switches. We'll probably just end up renaming the options to 
-f<something>.
Invoking the compiler executable (f951) directly will allow you to use these 
switches.

N.B. I'm talking about the new fortran[95] frontend, which is still 
incomplete and under development on the tree-ssa branch. I'm not aware of 
any similar options for g77, though I could be wrong.

Paul







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


HUANG Chun
 | 
3 Dec 2003 13:46






Picon

Favicon





fixed bug in substring


Hi,

! Prorgam to test Substring
subroutine substr(Tom)
   character(*) Tom
   character(7) John
   John=Tom(3:)
   if (.not.lle(John, "4567890")) call abort
end

program teststr
   character(10) Tom
   Tom = '1234567890'(:10)
   call substr(Tom)
end

"Segment fault" error happens because start/end point is null. Fixed.

=========
Index: fortran/ChangeLog
===================================================================
RCS file: /home/cvs/gcc/gcc/fortran/ChangeLog,v
retrieving revision 1.1.1.1
diff -c -3 -p -r1.1.1.1 ChangeLog
*** fortran/ChangeLog   3 Dec 2003 22:06:40 -0000       1.1.1.1
--- fortran/ChangeLog   4 Dec 2003 00:54:04 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2003-12-03  Huang Chun <chunhuang73 <at> hotmail.com>

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


HUANG Chun
 | 
3 Dec 2003 14:47






Picon

Favicon





fixed bug in intrinsic "index"


Hi,

Fixed bug in intrinsic index.

Huang Chun

=========
Index: ChangeLog
===================================================================
RCS file: /home/cvs/gcc/libgfortran/ChangeLog,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 ChangeLog
*** ChangeLog   3 Dec 2003 22:07:08 -00001.1.1.1
--- ChangeLog   4 Dec 2003 05:46:08 -0000
***************
*** 1,3 ****
--- 1,7 ----
+ 2003-12-03  Huang Chun <chunhuang73 <at> hotmal.com>
+
+       * intrinsics/string_intrinsics.c (string_index): Fixed error.
+
  2003-11-30  Paul Brook  <paul <at> nowt.org>

        * runtime/memory.c (push_context): Remove.
Index: intrinsics/string_intrinsics.c
===================================================================
RCS file: /home/cvs/gcc/libgfortran/intrinsics/string_intrinsics.c,v
retrieving revision 1.1.1.1
diff -c -p -r1.1.1.1 string_intrinsics.c
*** intrinsics/string_intrinsics.c      3 Dec 2003 22:07:09 -0000       

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


canqun
 | 
3 Dec 2003 14:55






Picon





Re-implement COMMON and EQUIVALENCE


Hi,

I re-implemented COMMON and EQUIVALENCE. The attached 
files are:
   trans-common.c: replace the old one.
   common.diff.txt: diff file for other part of 
gfortran.
   common.f90: testcase.

To let it work, you must 
make 'update_alignment_for_field' defind in 'gcc/stor-
layout.c' public.

Canqun Yang

2003-12-02  Canqun Yang  <canqun <at> nudt.edu.cn>

 	* trans-common.c: Re-implement COMMON blocks 
and EQUIVALENCE lists.
 	* trans-equivalence.c: Remove.
 	* trans-decl.c (gfc_get_symbol_decl): Update 
to match.
 	(gfc_generate_function_code): Ditto.
 	* trans-array.c (gfc_conv_array_parameter): 
Ditto. 
	* trans.h: Ditto.
 	* Make-lang.in: Remove 'trans-equvalence.o' 
from F95_OBJS. Add
 	'stor-layout.o' to F95_ADDITIONAL_OBJS.
 	* gfortran.h (struct gfc_equiv): Add 

(Continue reading)






Permalink
| Reply
| 18 comments  
| 



  

  

  

  


  





    



Gmane