Re: [PATCH, fortran] Clean-up mpfr (ab)use.

Jerry DeLisle wrote:
---- snip ----
>>
> Sending        ChangeLog
> Sending        arith.c
> Sending        intrinsic.texi
> Sending        simplify.c
> Transmitting file data ....
> Committed revision 136239.
> 
> 
Reverted wrong commit of intrinsic.texi.
Sending        ChangeLog
Sending        intrinsic.texi
Transmitting file data ..
Committed revision 136249.

Jerry

Re: [Patch, Fortran] attribute declaration outside of INTERFACE body (PR36361)

> here is my patch for PR36361, including test cases, regtested on
> i686-pc-linux-gnu with no
> failures. It also includes the one-line fix from PR36275 comment #3.

I have modified the fix for PR36275 a little, so that it also fixes
PR36322, which is actually related. Both are based on a sub-optimal
mechanism for copying the typespec for a PROCEDURE from its interface
(which happens in "resolve_symbol"). Before, the elements of ts were
just copied one by one (missing a few, which caused the problems). Now
I made sure that all of them are copied, an that the way of doing this
still works even if new elements are added in the future.

I also added a test case for PR36322.

> There is just one thing I need someone's opinion on: The new test case
> interface_24.f90 has some slight issues regarding error recovery.

I'd still like to hear some thoughts on this.

Cheers,
Janus

Index: gcc/testsuite/gfortran.dg/interface_24.f90
===================================================================
--- gcc/testsuite/gfortran.dg/interface_24.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/interface_24.f90	(revision 0)
@@ -0,0 +1,66 @@
+! { dg-do compile }
+!

Definition of _gfortran_os_error?

Hello,

I'm writing a mixed C++/Fortran program and recently I came into a linker 
error about _gfortran_os_error, when linking with g++ and -lgfortran:

$ g++ cbfg.o cbf.o -o cbf4 -lgfortran
cbf.o: In function `rellenar_array':
/home/alberto/testsFortran/c_binding3.f90:20: undefined reference to 
`_gfortran_os_error'

 On the other hand, if I link with gfortran and -lstdc++, it works although 
objdump says that symbol is undefined:

$ gfortran cbfg.o cbf.o -o cbf4 -lstdc++

$ objdump -tT ./cbf4 | grep os_error
0000000000000000       F *UND*  000000000000002c              
_gfortran_os_error@@GFORTRAN_1.0
0000000000000000      DF *UND*  000000000000002c  GFORTRAN_1.0 
_gfortran_os_error

I really wanted to link with g++ instead of gfortran, does anyone know which 
special flag is using gfortran at linking time in order to bypass that error?

My specs:

gcc version 4.2.4 (Debian 4.2.4-1)
gcc version 4.3.1 20080523 (prerelease) (Debian 4.3.0-5)

Thank you,

Re: Definition of _gfortran_os_error?

Sorry, I realized my specs weren't written correctly, here are the correct 
ones:

g++: gcc version 4.2.4 (Debian 4.2.4-1)
gfortran: gcc version 4.3.1 20080523 (prerelease) (Debian 4.3.0-5)

Re: Definition of _gfortran_os_error?

> $ g++ cbfg.o cbf.o -o cbf4 -lgfortran
> cbf.o: In function `rellenar_array':
> /home/alberto/testsFortran/c_binding3.f90:20: undefined reference to
> `_gfortran_os_error'

It looks to me like a case of getting the wrong library linked in: I
see your gfortran is not the same as your g++; are you sure you don't
have a gfortran-4.2 around that gets linked instead of the 4.3
libraries?

FX

--

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

Re: Definition of _gfortran_os_error?

Hello Alberto,

Alberto Luaces wrote:
> I'm writing a mixed C++/Fortran program and recently I came into a linker 
> error about _gfortran_os_error, when linking with g++ and -lgfortran
>   
Are you by chance mixing different gfortran versions? For instance g++ 
and one gfortran under /usr/bin and a newer gfortran under 
"/home/alberto/gfortran" (or wherever)?

That could explain the problems. Then g++ picks up 
/usr/lib/libgfortran.so* and gfortran picks up another libgfortran.

If that is the case, try -L <path to gfortran lib> -lgfortran.

Tobias

Re: Definition of _gfortran_os_error?

FX, Tobias

thank you both. As you said, the problem came from the g++ version, since if I 
do

$ g++-4.3 -lgfortran cbf.o cbfg.o -o cbf4

(that is, explicitly linking g++ 4.3 and gfortran 4.3 instead of g++ 4.2 
against gfortran 4.3) it works.

As Debian default g++ is 4.2 and gfortran is 4.3, I thought that they could 
safely work with each other object files. Now I see that this is not always 
the case and will match both compiler versions in the future.

Regards,

Alberto

El Lunes 02 Junio 2008ES 11:38:17 Tobias Burnus escribió:
> Hello Alberto,
>
> Alberto Luaces wrote:
> > I'm writing a mixed C++/Fortran program and recently I came into a linker
> > error about _gfortran_os_error, when linking with g++ and -lgfortran
>
> Are you by chance mixing different gfortran versions? For instance g++
> and one gfortran under /usr/bin and a newer gfortran under
> "/home/alberto/gfortran" (or wherever)?
>
> That could explain the problems. Then g++ picks up

Memory leaks in allocatable components

Dear All,

As some of you might know, I have been claiming as an excuse for
inaction of all sorts that I am busy trying to sort out memory leaks
in allocatable components.  Since this excuse is becoming so well
worn, I thought that I had better explain what I am up to!

To a good approximation, the problems are entirely associated with
structure components.  There are memory leaks with forall and where
assignments.  However, these are easily fixed as they were for
ordinary assignments.

Most usually, the problems are specific to nested constructors, each
with allocatable components, although that is not the whole story. I
have tried all sorts of kludges to get this right but, at the end of
the day, it is a fundamental problem with the functions called by
trans-expr.c(gfc_conv_structure) that is to blame:- namely, the gfc_se
structure is not passed to them so that the -pre and -post blocks are
not available.  Not only does this put these functions outside of the
gfortran norms but it prevents the kind of clean-up that is required
here. Thus, I am working on this reform of the translation of
structure constructors to begin with and will return to allocatable
components right away afterwards.  Once there is a post-block that is
accessible to the innermost parts, eg. gfc_trans_subcomponent_assign,
then we can de-allocate memory assigned to allocatable components,
following a final deep copy to the lhs of the assignment.  This is
what is done everywhere else in gfortran.

Bear with me!

Re: Memory leaks in allocatable components

> Thus, I am working on this reform of the translation of
> structure constructors to begin with and will return to allocatable
> components right away afterwards.  Once there is a post-block that is
> accessible to the innermost parts, eg. gfc_trans_subcomponent_assign,
> then we can de-allocate memory assigned to allocatable components,
> following a final deep copy to the lhs of the assignment.  This is
> what is done everywhere else in gfortran.

It really sounds like the good way to do it (and quite consistent  
with how it's done everywhere else in the front-end either).

Keep up the good work!
FX

--

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: [Patch, Fortran] attribute declaration outside of INTERFACE body (PR36361)

Janus Weil wrote:
> There is just one thing I need someone's opinion on: The new test case
> interface_24.f90 has some slight issues regarding error recovery. For
> "f2" and "f5" I commented out some lines of (normally valid) code, to
> get rid of excess errors:
>
>
>   dimension :: f2(4)
>   interface
>     real function f2()  ! { dg-error "outside its INTERFACE body" }
>     !end function
>   end interface
>
> Otherwise I get an additional error like:
>
>     end function
>       1
> Error: Expecting END INTERFACE statement at (1)
>
> Is this acceptable for a test case? Or should I rather use additional
> dg-errors to catch all of the excess errors? Right now I see no easy
> way to completely get rid of these recovery issues.
>   
Commenting the "end function" is OK as is to add another "dg-error 
"Expecting END FUNCTION".

> I have modified the fix for PR36275 a little, so that it also fixes
> PR36322, which is actually related.
Can you add PR36322 to ChangeLog? Additionally, note that for PR36275 
only comment 2 is fixed while comment 0 remains unfixed. (Please add a