Re: bignum for gfortran

Tobias Burnus wrote:

> And note that gfortran also supports 16-byte-wide integer types, i.e. 
> INTEGER(16).

Exactly.  This "Just Works" on my x86_64-unknown-linux-gnu system:

       integer*16 i, n
       character*80 arg
       call getarg(1,arg)
       read(arg,'(i20)') i
       n = 1
       do i = 1, i
          n = n * i
       enddo
       print*,n
       end

./a.out 32
  263130836933693530167218012160000000

--

-- 
Toon Moene - e-mail: toon <at> moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/ml/gcc/2008-01/msg00009.html

Patch suitable for 4.3?

Hi all,

PR34729 is about runtime error messages emitted by the front-end and
encoded in the executable (like "Allocating an already allocated
array"). When compiled with a non-english locale, these strings are
trimmed to their english length, due to a bug I introduced when I
added localization in the front-end (quite some time ago). I have made
a patch (attached to the PR), which is basically a one-liner. I wonder
if you think it would be suitable for 4.3 or not: it's a simple patch,
but it's not a regression and it's been here for some time without
people reporting it. I have no strong opinion myself.

Thanks for your advice,
FX

--

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

gfortran io

      Hello, 

      I reported in a previous mail a gfortran io bug in the following 
      program 

      program bug 
      double precision x
      character*10 str
      character*10 fmt
      x=1.0 
      write(fmt,120) 3,0 
      write(str,fmt) x
      write(06,*) str 
 120  format('(f',i2,'.',i2,')')
      end 

      This bug seams to be still present (i.e wrong output for x=1.0 and x=7.0) 
      with the latest gcc 2.2 snapshot ? 

clio% /usr/local/mingw32-gcc4.2.3/bin/i686-pc-mingw32-gfortran -o bug bug.f
clio% ./bug 
  0.       
clio%  /usr/local/mingw32-gcc4.2.3/bin/i686-pc-mingw32-gfortran -v 
Using built-in specs.
Target: i686-pc-mingw32
Configured with: /usr/local/src/mingw32-build/source/gcc-4.2-20080123//configure -v
--prefix=/usr/local/mingw32 --target=i686-pc-mingw32
--with-headers=/usr/local/mingw32/i686-pc-mingw32/include --with-gcc --with-gnu-ld
--with-gnu-as --enable-threads --disable-nls --enable-languages=c,fortran,c++

Re: gfortran io

Hello,

> This bug seams to be still present (i.e wrong output for x=1.0 and x=7.0)
> with the latest gcc 2.2 snapshot ?

I take it you meant 4.2. I've checked and this bug is not present in
4.1.2, 4.2.2 or the current branch (to become 4.3.0) on linux. I have
also checked and it does not appear on mingw for 4.3.0. So, this is a
mingw-only, 4.2-only bug, is that correct?

> gcc version 4.2.3 20080123 (prerelease)

Are you building this snapshot yourself or

> It seams to be ok with the following gcc-4.3 ... but I cannot use
> gcc-4.3 which seams to give me crashes elsewhere in my program.

I'll be more than happy to help you find out the possible bugs in
gfortran-4.3 or the possible bugs in your code exposed by
gfortran-4.3, if you start down that path. As a side note: mingw
doesn't officially support gcc-4.x for any value of x smaller than 3.

> Can I expect this bug to be solved in the 4.2.3 version ?

No. The 4.2.3 release process has begun and the version should be
officialy released in the next 24 hours.

For a possible 4.2.4 fix, the rule is that we only fix regressions: if
that was working on the 4.1 branch, we can consider fixing it on a
later released branch. Otherwise, we would need a particularly

Re: 2-d IMSL fft -> gfortran

Peter Bromirski wrote:

> Hello,
> 
>     I have obtained a relatively old fortran code that uses 2-d IMSL
> FFT routines, forward and inverse.
> 
> Is there a gfortran implementation available that I can substitute?
> 

To my knowledge, no. Your best bet for replacement of IMSL for fft routines
would be to use something like fftw3 (www.fftw.org). If you decide to adopt
this route, be prepared to read up the manuals as it is not a drop in
replacement for IMSL routines. Nevertheless, unlike IMSL which is
commercial, fftw3 code is available for free (under GPL).

hth
raju
--

-- 
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/

Question about array types in the front-end

Hi all,

I'm working on a patch to fix the "multiple decls per function"  
issue. Current status is good, except for handling of array  
arguments, and I need a hand in understand how this is handled. This  
is not strictly related to my patch, but lies in the code generated  
by the front-end in its current state, although it is uncovered by  
the patch :(  I'd be happy to get other maintainers' insight on this  
issue, because I'm not too used to array-handling at the tree level.

My patch enables us to reuse already created function decls for a  
given function instead of creating a new one each time. If the  
function declaration comes first or if an explicit interface is used,  
we can create the function decl easily from the formal arglist. For  
implicit interfaces, I chose to recreate the list of argument types  
simply by looking at the types in the actual arglist (in its tree form).

However, in the case where an array is used as argument, that doesn't  
give the same results. For an explicit interface of type

     subroutine test(x)
       integer x(1)
     end subroutine test

the front-end generates for the type of the argument the following tree:

<pointer_type 0x2aae4c1bc3c0
         type <array_type 0x2aae4c1bc000 type <real_type  
0x2aae4c1383c0 real(kind=4)>
             type_2 SF

[Patch, fortran] PR32760 - [4.3 Regression] Error defining subroutine named PRINT

:ADDPATCH fortran:

The fix for this patch was dominated by something that was a bit
peripheral to the original problem.  The original problem was that
match_variable would attempt to patch up the flavor of host associated
symbols too early.  Whilst this could have been fixed up, it is better
to delay to resolution.

The extra bit was due to the STAT tag of allocate/deallocate being
resolved too early; ie. just after matching.  The fix is in principle
the same as that above; delay until resolution.  The difference is
that fixing this necessitated moving the code, lock stock and barrel,
to resolve.c.

The testcase is that of the reporter and the comments #12, #21 and
#25.  In addition, three of the error messages in alloc_stat.f90
changed slightly.

Bootstrapped and regtested on x86_ia64/FC8 - OK for trunk?

Paul

2008-02-02  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/32760
	* resolve.c (resolve_allocate_deallocate): New function.
	(resolve_code): Call it for allocate and deallocate.
	* match.c (gfc_match_allocate, gfc_match_deallocate) : Remove
	the checking of the STAT tag and put in above new function.
	* primary,c (match_variable): Do not fix flavor of host

Re: [Patch, fortran] PR32760 - [4.3 Regression] Error defining subroutine named PRINT

Paul Richard Thomas wrote:
> :ADDPATCH fortran:
> 
> The fix for this patch was dominated by something that was a bit
> peripheral to the original problem.  The original problem was that
> match_variable would attempt to patch up the flavor of host associated
> symbols too early.  Whilst this could have been fixed up, it is better
> to delay to resolution.
> 
> The extra bit was due to the STAT tag of allocate/deallocate being
> resolved too early; ie. just after matching.  The fix is in principle
> the same as that above; delay until resolution.  The difference is
> that fixing this necessitated moving the code, lock stock and barrel,
> to resolve.c.
> 
> The testcase is that of the reporter and the comments #12, #21 and
> #25.  In addition, three of the error messages in alloc_stat.f90
> changed slightly.
> 
> Bootstrapped and regtested on x86_ia64/FC8 - OK for trunk?
> 
Reg tested fine here.  OK for trunk, Super!

Jerry

[Patch, fortran] PR34945 - LBOUND fails for array with KIND(complex) used in zero-sized dimension

:ADDPATCH fortran:

This is one of the four remaining "F95" bugs.  Again, the problem is
due to jumping the gun and trying to do checks before expressions are
resolved.  Here, the check for negative array size was moved from
matching to resolution, so that we can be sure that every expression
that can be simplified has had it done.

Bootstraps and regtests on x86_ia64 - OK for 4.4 when it opens?

Cheers

Paul

2008-02-03  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/34945
	* array.c (match_array_element_spec): Remove check for negative
	array size.
	(gfc_resolve_array_spec): Add check for negative size.

2008-02-03  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/34945
	* gfortran.dg/bounds_check_13.f: New test.

Index: gcc/fortran/array.c
===================================================================
*** gcc/fortran/array.c	(revision 132077)

Re: [Patch, fortran] PR34945 - LBOUND fails for array with KIND(complex) used in zero-sized dimension

Hello,

is it possible to have this in GCC 4.3.
At the moment there are only three (with this) "F95" bugs. It would be 
great, if GCC 4.3 would be without any of these.

Best regards

Andreas

Paul Richard Thomas schrieb:
> :ADDPATCH fortran:
> 
> This is one of the four remaining "F95" bugs.  Again, the problem is
> due to jumping the gun and trying to do checks before expressions are
> resolved.  Here, the check for negative array size was moved from
> matching to resolution, so that we can be sure that every expression
> that can be simplified has had it done.
> 
> Bootstraps and regtests on x86_ia64 - OK for 4.4 when it opens?
> 
> Cheers
> 
> Paul
> 
> 2008-02-03  Paul Thomas  <pault <at> gcc.gnu.org>
> 
> 	PR fortran/34945
> 	* array.c (match_array_element_spec): Remove check for negative
> 	array size.