Status of deferred type parameters and ALLOCATE

All, 

Here's a short status report on the deferred type parameter
and F2003 ALLOCATE features that I've been implementing.  
I'm making slow but steady progress on both features.
Unfortunately, the two features are sufficiently intertwined
that one cannot be committed without the other (imho).  
Here's a preview, consider

   program test
   implicit none
   character(:), allocatable :: fmt
   allocate(character(3) :: fmt)
   fmt = 'abc'
   print *, fmt, len(fmt)
   deallocate(fmt)
   allocate(character(6) :: fmt)
   fmt = 'abcdef'
   print *, fmt, len(fmt)
   end program test 

REMOVE:kargl[293] gfc4x -o z -fdump-tree-original t.f90
REMOVE:kargl[294] ./z
 abc              6
 abcdef           6

Note 1: The 6 in the first line of output should probably
        be 3.  This difference is caused by the way I currently
        fiddle with the length component of the charlen structure
        during the parsing and matching stage.

[Patch, fortran] PR40646 - ICE assigning array return value from type-bound procedure

The attached is verging on obvious.

Bootstrapped and regtested on FC9/x86_64 - OK for trunk?

Cheers

Paul

2009-07-04  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/40646
	* trans-expr.c (gfc_trans_arrayfunc_assign): Make sure that the
	esym field of the expression is filled and use is_proc_ptr_comp
	in the condition.

2009-07-04  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/40646
	* gfortran.dg/func_assign_3.f90 : New test.

--

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c	(revision 149062)
+++ gcc/fortran/trans-expr.c	(working copy)
@@ -4356,6 +4356,11 @@

gfortran for windows binaries 21042009

Dear Sirs,

I have a problem with this binary. After installation the compiler starts
but terminates with exit code 5 of the linker. It seems to be in the
collect phase.

Is there any workaround or an older version that works?

Best regards,

Berthold Lankl

Possible bug with assigning array return value from type-bound procedure?

Hello all,

I've been exploring new Fortran 2003 features using gfortran 4.4 and a I
have come across an issue that seems like it may be a bug.

Basically, I have a type bound procedure that is a function which returns an
array. I can call the function as part of a write statement and I get output
that looks like an array. However, when I try to assign the output to an
array variable of the correct dimensions I get an internal compiler error.

I was about to submit a bug report to the GCC Bugzilla, but figured I would
check here since it is highly probable that the bug might lie on my side of
the keyboard.

A short test file that reproduces the problem for me is:

module bugTestMod
  implicit none

  type:: boundTest
  contains
    procedure, nopass:: test => returnMat
  end type boundTest

contains

  function returnMat( a, b ) result( mat )
    integer:: a, b
    double precision, dimension(a,b):: mat 

Donate for text link

Hi Gnu,

Thank you for great OSS project. I would like to make donation for you. 
Could you please place my text link on your homepage 
(http://gcc.gnu.org/fortran/). It would link to my software downloads 
website, anchor text "Software Download".

Please let me know.

Regards,
Martin

[Patch, Fortran] PR 40594: [4.5 Regression] wrong-code

Hi all,

here is my fix for PR40594, a regression caused by my PPC patch
(r147206). The fix is simply reverting one hunk of the PPC patch. I'm
still not sure how and why this hunk got in there in the first place,
but as reverting it gave no regressions, it seems it is unneeded (and
in fact wrong, as Daniel's test case showed).

Daniel: Could you verify that the patch fixes your full code? I have
made sure that the reduced test cases in the PR are ok.

Regtested on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus

2009-06-30  Janus Weil  <janus <at> gcc.gnu.org>

	PR fortran/40594
	* trans-types.c (gfc_get_derived_type): Bugfix, reverting one hunk from
	r147206.

2009-06-30  Janus Weil  <janus <at> gcc.gnu.org>

	PR fortran/40594
	* gfortran.dg/derived_pointer_recursion_2.f90: New.

[Patch, fortran] PR40011 - Problems with -fwhole-file

Dear All,

As promised at the recent #gfortran meeting, I have put some efforts
into the whole file scope business.  At the end of play to day, I have
the following on regtesting with -fwhole-file:

# of expected passes		30821
# of unexpected failures	78
# of expected failures		20
# of unsupported tests		42

All are down to genuine errors in interfaces except:

FAIL: gfortran.dg/func_decl_4.f90  -O   (test for errors, line 7)
FAIL: gfortran.dg/func_decl_4.f90  -O   (test for errors, line 11)
The errors caused by initialising the function result have
disappeared  This has to be trivial.

FAIL: gfortran.dg/func_derived_2.f90  -O1  execution test
Fails with -O1 only!

FAIL: gfortran.dg/import.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/import.f90  -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/import.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/import.f90  -O3 -g  execution test
Fails at -O3
The calls to 'test' and 'bar' are optimized away and all routes lead
to call abort ().

[PATCH]: Use mpc_pow in the fortran frontend

This patch makes use of mpc_pow in the fortran frontend.  Note mpc_pow
is only available in the svn repo for MPC.  I've guarded the uses of
mpc_pow with the appropriate version checks.

The call to mpc_pow replaces two separate areas, a general pow, and
the integer exponent specialization.  The existing fortran integer
exponent code had a problem immortalized in a testcase, and as
discussed here:
http://gcc.gnu.org/ml/fortran/2009-06/msg00267.html
I'm commenting out some lines in one testcase that were incorrect.

I'll reinsert the corrected lines once we've made MPC a
hard-requirement, and assuming this patch is accepted I'll put a note
in PR40302 so I don't forget.

Bootstrapped on x86_64-unknown-linux-gnu with MPC svn (which has
mpc_pow), with mpc-0.6 (no pow), and without MPC.  All three scenarios
had no regressions.

Okay for mainline?

		Thanks,
		--Kaveh

2009-06-26  Kaveh R. Ghazi  <ghazi <at> caip.rutgers.edu>

gcc/fortran:

	* gfortran.h: Define HAVE_mpc_pow.
	* arith.c (complex_reciprocal, complex_pow): If HAVE_mpc_pow,

Is it a bug: data aligment of matrix returned by gemm

This is my first post. Greetings everyone!

I am not sure if the following behaviour is a bug or simply the matter
of my poor understanding of F90 standard so I am not submitting this a 
a formal bug report.

Consider following code:

function matmul_func(a,b)
  real(kind=8),intent(in) :: a(:,:), b(:,:)
  real(kind=8) :: matmul_func(size(a,1),size(b,2))

  call dgemm('N','N',size(a,1),size(b,2),size(a,2),1.0d0,a,size(a,1),&
            &b,size(b,1),0.0d0,matmul_func,size(a,1))

end function

program test
  integer, paramater :: range=2
  real(kind=8) :: a(rank,rank), b(rank,rank), c(2,rank,rank)

  interface
    function matmul_func....
                ....
    end function matmul_func
  end interface

  a(1,:)=1.0d0
  a(2,:)=2.0d0

Fortran pow (complex ** huge) returns NaN instead of Inf ?

Hi,

I'm integrating mpc_pow with the fortran frontend and I'm getting one
regression related to raising a value to a huge integer.

FAIL: gfortran.dg/integer_exponentiation_4.f90  -O   (test for errors, line 
41)
FAIL: gfortran.dg/integer_exponentiation_4.f90  -O   (test for errors, line 
42)
FAIL: gfortran.dg/integer_exponentiation_4.f90  -O  (test for excess errors)

The testcase has on lines 41/42 these statements:

  print *, (2.0,-4.3)**huge(0) ! { dg-error "Arithmetic NaN" }
  print *, (2.0,-4.3)**(-huge(0)) ! { dg-error "Arithmetic NaN" }

I.e. it expects a NaN for both cases.  What I'm getting with MPC is
"Arithmetic overflow" on the first line because it overflows to Inf, and no
error for the second presumably because it underflows to zero.

I think perhaps expecting a NaN here is bogus and is an artifact of the
hand-written algorithm chosen to evaluate complex**int inside the fortran
frontend.  The code is in fortran/arith.c:complex_pow().  I suspect the
algorithm is getting confused somewhere along the way.

E.g. if I write in C:

  cpow (2 - 4.3i, INT_MAX);

I get (Inf - Inf I).

Delta Frost harmonicas and reedplates

Doc and John Hall have worked out an agreement whereby Doc's website stores will be receiving large
quantities of Delta Frost harmonicas beginning the week of 6/29/09, with reedplates to follow several
weeks later. This agreement should more than double the number of both the harmonicas and reedplates
coming into the USA. This is just another example of Doc and John Hall working together to better serve
their customers.

To celebrate this event, we are now taking orders for Delta Frost harmonicas and reedplates and will fill
them in the order in which we receive them. And, if you order Delta Frost harmonicas and reedplates over the
internet, through one of our websites stores, and you place the discount code "DFJUN09" in the comments
section, we will give you a discount of $1.00 on each Delta Frost harmonica and reedplate you order. This
discount is available on orders placed by the end of June 2009. The website stores that offer this discount
include HarpDepot.com, HarpExpress.com, HarpHouse.com, DeltaFrostHarmonicas.com,
1st-In-Harmonicas.com, Kharps.com, and ArmonicaDepot.com.

If you do not want to be on this email list, do a reply and simply write "REMOVE" in your message and you will be
removed from this email list.