This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, OOP] PR 43388: [F2008] ALLOCATE with MOLD=


Am 13.06.2010 20:16, schrieb Janus Weil:
>>>> I believe that this is handled in the patch:
>>>> +      else if (e->ts.type == BT_CLASS)
>>>> +       init_e = gfc_default_initializer (&ts.u.derived->components->ts);
>>> Right.
>>
>> But doesn't this use the base type for initialization while the
>> effective type should be used?
> 
> Yes, this is the issue I was talking about in my original post. My
> proposal was to extend the vtab structure to hold the default
> initialization. What do you think about this?

First, I think you should note this in the PR as written before.
Secondly, I also do not have a better idea than saving it in the vtable.


>>>>> * The constraint C637 (cf. above) does not seem to be checked for.
>> Re-reading I agree that that's a possible reading, though I think my
>> reading is more likely;
> 
>> also technically as it avoids the precedence
>> ambiguity of having MOLD and SOURCE in the same statement
> 
> What precedence ambiguity? I don't see any.

Well, assume for a moment that both SOURCE and MOLD are allowed. Now, if
you have SOURCE= and MOLD=, from where do you copy the type-spec from
SOURCE or from MOLD?

If you use the one of SOURCE, then MOLD is useless. If you use the one
of MOLD then most of the time MOLD and SOURCE need to be identical -
otherwise, it will only work in the very few cases where the two types
are type compatible, e.g. assigning an integer to a real.

>> and I do not
>> see a case where it makes sense and would more in more than a very
>> constructed example.
>
> One might interpret the situation as taking the dynamic type from MOLD
> and the data init from SOURCE. Although I'm not sure how useful that
> is as a feature ...

Well, as said: I fail to construct a useful example where it can make
sense, using
  CLASS(*), ALLOCATABLE :: foo
  ALLOCATE ( foo, source=5, mold=3.0)
does not really count. And with derived types I fail to see any type
compatibility.


> Unfortunately I don't have access to any other compiler supporting
> this feature (is there any?). Can someone check if NAG supports MOLD
> and if yes if it allows SOURCE together with MOLD?

I cannot try NAG but I can try crayftn:


$ cat test.f90
integer, allocatable :: a, b, c
allocate (a, source=b)
allocate (a, mold=c)
allocate (a, source=b, mold=c)
end

$ ftn test.f90
/opt/cray/xt-asyncpe/3.9/bin/ftn: INFO: linux target is being used

allocate (a, source=b, mold=c)
                    ^
ftn-1922 crayftn: ERROR $MAIN, File = test.f90, Line = 4, Column = 21
  Only one source-expr may be specified for an ALLOCATE statement.


Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]