headers
Tobias Burnus | 1 Nov 2009 17:07
Picon

[Patch, Fortran] PR 41872 - Fixes for allocatable scalars (part 1)

Hello,

allocatable scalars have several issues. This patch fixes the some of
them. (For more issues, see PR.)

Especially the following now works:

* Passing allocatable scalars as argument. The problem before was that
the allocatable scalar was passed by value and not by reference.

* Auto-deallocation of allocatable actual arguments when passing them to
allocatable INTENT(OUT) dummies.

* Going out of scope does no longer nullify the variable; this is not
needed as the variable cannot be accessed. (missed optimization)

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias
Attachment (alloc_scalar.diff): text/x-patch, 6588 bytes
Permalink | Reply | 3 comments |
headers
Tobias Burnus | 1 Nov 2009 18:51
Picon

Re: [Patch, Fortran] PR 41872 - Fixes for allocatable scalars (part 1)

Daniel Kraft wrote:
> Tobias Burnus wrote:
>> allocatable scalars have several issues. This patch fixes the some of
>> them. [...]
> I'm just wondering if that "large" new code block for deallocating
> allocatable scalars passed to INTENT(OUT) can't be somehow be
> simplified -- actually, there should already be code to do this for
> non-scalar allocatables; is it possible to merge this somehow?  But I
> guess it's not, because stuff is probably too different there.

Committed as Rev. 153795. Thanks for the review. I think it is not easy
to simplify the code: Large parts are the same both there are enough
differences that one only trades one kind of ifs with another one.

I think the proper way would be to rewrite some of the allocatable
handling stuff. One might consider this for 4.6 if GCC gets a new array
descriptor. Actually, I do not like that the caller and not the callee
deallocates intent(OUT) variables. I wonder how this should work with
BIND(C) and the new TR 29113.

Tobias
Permalink | Reply | 1 comment |
headers
Hans Horn | 1 Nov 2009 20:53

equivalence croakage

Folks,

just trying to make the switch from g77 to gfortran (and from gcc3 to gcc4).
When compiling some legacy f77 code that uses f77 equivalence 
statements, I get barfed at with the following (32bit environment):

<During initialization>

Error: Overlapping unequal initializers in EQUIVALENCE at (1)

Doesn't tell at all where the shit is happening.

This code happens to compile with various f77 compilers (aix xlf, g77).

I collected all the equivalence statements from the offending f77 source 
(all more or less variations of the same theme):

       subroutine dud
       IMPLICIT NONE
       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
       Real*8    rDummy(1), XSTORE

       Equivalence(CSTORE(1),XSTORE,ISTORE)
       Equivalence(CSTORE1(1),ISTORE1)
       Equivalence(cDummy(1), iDummy(1), rDummy(1))

       end

this just happens to compile w/o a problem.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Tobias Burnus | 1 Nov 2009 21:54
Picon

Re: equivalence croakage

Hans Horn wrote:
> just trying to make the switch from g77 to gfortran (and from gcc3 to
> gcc4).
> When compiling some legacy f77 code that uses f77 equivalence
> statements, I get barfed at with the following (32bit environment):

Which version of the compiler? It is compiled here with gfortran 4.1.2
up to 4.5.0(experimental) without any warning (default options).

With "-pedantic" I get:

Warning: Non-CHARACTER object 'xstore' in default CHARACTER EQUIVALENCE
statement at (1)

which is OK.

Tobias
Permalink | Reply | 0 comments |
headers
Tim Prince | 1 Nov 2009 22:04
Picon
Favicon

Re: equivalence croakage

Hans Horn wrote:

>       subroutine dud
>       IMPLICIT NONE
>       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
>       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
>       Real*8    rDummy(1), XSTORE
> 
>       Equivalence(CSTORE(1),XSTORE,ISTORE)
>       Equivalence(CSTORE1(1),ISTORE1)
>       Equivalence(cDummy(1), iDummy(1), rDummy(1))
> 
>       end
> 
> this just happens to compile w/o a problem.
> 

It's somewhat surprising that you could compile this stuff with multiple 
f77 compilers.  Not all f77 compilers support all the non-standard 
extensions
(1) real*8
(2) EQUIVALENCE of character and non-character data types
(3) initialization in declaration under f77
So, what you have shown here are not f77 equivalence.  Surely, gfortran 
should complain if you turned on standards checking.

The notations Error:  ....... at (1) generally refer to a previous 
attempt to quote a source line and follow it with a line containing 1 in 
the same column as the referenced problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kargl | 2 Nov 2009 01:30
Picon

Re: equivalence croakage

On Sun, Nov 01, 2009 at 11:53:58AM -0800, Hans Horn wrote:
> Folks,
> 
> just trying to make the switch from g77 to gfortran (and from gcc3 to gcc4).
> When compiling some legacy f77 code that uses f77 equivalence 
> statements, I get barfed at with the following (32bit environment):
> 
> <During initialization>
> 
> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
> 
> Doesn't tell at all where the shit is happening.
> 
> This code happens to compile with various f77 compilers (aix xlf, g77).
> 
> I collected all the equivalence statements from the offending f77 source 
> (all more or less variations of the same theme):
> 
>       subroutine dud
>       IMPLICIT NONE
>       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
>       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
>       Real*8    rDummy(1), XSTORE
> 
>       Equivalence(CSTORE(1),XSTORE,ISTORE)
>       Equivalence(CSTORE1(1),ISTORE1)
>       Equivalence(cDummy(1), iDummy(1), rDummy(1))
> 
>       end
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jerry DeLisle | 2 Nov 2009 02:13
Picon

Re: [Patch, libfortran] Split io.h into multiple include files

On 10/30/2009 04:20 PM, Janne Blomqvist wrote:
> Hi,
>
> the attached patch splits io.h into multiple include files such that a
> few of the components of the I/O library now have their own header
> files. This makes it easier to get a grip on the structure, makes
> dependencies between components slightly easier to grasp, and reduces
> the compilation cascade if one edits one of the new lower level
> headers. Regtested on  x86_64-unknown-linux-gnu, Ok for trunk?
>
Not all that necessary but I have no preferences.  OK

Jerry
Permalink | Reply | 4 comments |
headers
Hans Horn | 2 Nov 2009 04:39

Re: equivalence croakage

Steve Kargl wrote:
> On Sun, Nov 01, 2009 at 11:53:58AM -0800, Hans Horn wrote:
>   
>> Folks,
>>
>> just trying to make the switch from g77 to gfortran (and from gcc3 to gcc4).
>> When compiling some legacy f77 code that uses f77 equivalence 
>> statements, I get barfed at with the following (32bit environment):
>>
>> <During initialization>
>>
>> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
>>
>> Doesn't tell at all where the shit is happening.
>>
>> This code happens to compile with various f77 compilers (aix xlf, g77).
>>
>> I collected all the equivalence statements from the offending f77 source 
>> (all more or less variations of the same theme):
>>
>>       subroutine dud
>>       IMPLICIT NONE
>>       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
>>       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
>>       Real*8    rDummy(1), XSTORE
>>
>>       Equivalence(CSTORE(1),XSTORE,ISTORE)
>>       Equivalence(CSTORE1(1),ISTORE1)
>>       Equivalence(cDummy(1), iDummy(1), rDummy(1))
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Kargl | 2 Nov 2009 05:07
Picon

Re: equivalence croakage

On Sun, Nov 01, 2009 at 07:39:07PM -0800, Hans Horn wrote:
> >>
> >><During initialization>
> >>
> >>Error: Overlapping unequal initializers in EQUIVALENCE at (1)
> >>
> >>Doesn't tell at all where the shit is happening.
> >
> >Please show the complete error message.
> >Please show the actual code causing the problem.
> >Please report the version of gfortran that you are using.
> >Please report the options that you used.
> >
> >I doubt that it's a bug in gfortran.  I suspect it's a
> >bug in your code because using equivalence correctly is
> >actually more difficult than it may appear.
> >
> >  
> 
> Steve,
> 
> I was using gfortran v4.5 and this WAS the entire error message!

No, you did not show the entire error message.  If it includes
a locus, ie., 'EQUIVALENCE at (1)', then a line of code was spit
out.  That's part of the error message.

> commandline used:
> gfc -c -Wuninitialized -Wunused-label -fno-underscoring -fno-f2c 
> -ffixed-line-length-132  -g -gstabs -O  -march=pentium4 -pipe -x
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Burnus | 2 Nov 2009 08:59
Picon

Re: equivalence croakage

Hans Horn wrote:
> Steve Kargl wrote:
>> Please show the complete error message.
>> Please show the actual code causing the problem.
>> Please report the version of gfortran that you are using.
>> Please report the options that you used.
>>   
>
> I was using gfortran v4.5 and this WAS the entire error message!

It does not if you post complete code. As written before, the snippet of
code, which you posted before, works with gfortran.

> The legacy f77 code I was trying to compile was written in the early 90s.

Which does not mean that it is valid. As the error message of gfortran
indicates ("Overlapping unequal initializers in EQUIVALENCE") or the
warning of Open64 ("Warning: Multiple DATA initialization of storage for
.EQUIVA. Some initializations ignored."), your code has a problem:

You cannot initialize the same bit of storage by two different values -
it simply does not work. The compiler can either give an error (as
gfortran does), a warning (as Open64) or silently choose one of them for
initializing (as with ifort). I would argue that giving an error is
sensible, forcing the user to decide which initialization (s)he wants.

(There are several other features which make the code nonconforming to
the standard, but at least those extensions are non-ambiguous.)

> When I remove the initialization of ISTORE/0/, it compiles - surprise.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane