>> Sorry for the belated review.
>>
>> + bool ptr = sym->attr.pointer || sym->attr.allocatable
>> +|| (sym->ts.type == BT_CLASS
>> +&& CLASS_DATA (sym)->attr.class_pointer);
>>
>>
>> That looks quite imbalanced. Why do you not take care of
>> CLASS_DATA(sym)
Hi,
> Sorry for the belated review.
>
> + bool ptr = sym->attr.pointer || sym->attr.allocatable
> +|| (sym->ts.type == BT_CLASS
> +&& CLASS_DATA (sym)->attr.class_pointer);
>
>
> That looks quite imbalanced. Why do you not take care of
> CLASS_DATA(sym)->at
Janus Weil wrote:
Ok for trunk?
Sorry for the belated review.
+ bool ptr = sym->attr.pointer || sym->attr.allocatable
+|| (sym->ts.type == BT_CLASS
+&& CLASS_DATA (sym)->attr.class_pointer);
That looks quite imbalanced. Why do you not take care of
CL
>> Looking at gfc_class_initializer, I have the impression that it does not
>> handle initialization of unlimited polymorphic variables/components. I don't
>> know whether initialization is permitted, but my feeling is that the
>> following should work:
>>
>> type t
>> class(*), pointer :: x
>> e
Hi Tobias,
> Sorry, I currently have only a shaky internet connection and also no access
> to my development system.
sounds like holidays :)
> Looking at gfc_class_initializer, I have the impression that it does not
> handle initialization of unlimited polymorphic variables/components. I don't
Janus Weil wrote:
ping!
Sorry, I currently have only a shaky internet connection and also no
access to my development system.
Looking at gfc_class_initializer, I have the impression that it does not
handle initialization of unlimited polymorphic variables/components. I
don't know whether i
ping!
2013/7/30 Janus Weil :
>> The attached update fixes it, and thus should hopefully be
>> regression-free. It also renames 'gfc_class_null_initializer' to
>> 'gfc_class_initializer', since it now also does other initializations
>> beside EXPR_NULL.
>>
>> Will do another regtest to make sure i
2013/7/30 Janus Weil :
>>> The attached new version should do the right thing now. At least it
>>> shows the correct dump for the original test case as well as yours. It
>>> is currently being regtested.
>>
>> unfortunately it shows a couple of runtime problems with type-bound
>> operators:
>>
>>
>> The attached new version should do the right thing now. At least it
>> shows the correct dump for the original test case as well as yours. It
>> is currently being regtested.
>
> unfortunately it shows a couple of runtime problems with type-bound operators:
>
> FAIL: gfortran.dg/class_defined_op
2013/7/29 Janus Weil :
> Hi Tobias,
>
>>> here is a fix for class pointer initialization.
>>
>> I think the patch looks reasonable.
>
> well, it may appear so ...
>
>
>> Additionally, the CLASS are wrongly initialized: You only set "_data"
>> (indirectly as it is the first field/component of the cl
Hi Tobias,
>> here is a fix for class pointer initialization.
>
> I think the patch looks reasonable.
well, it may appear so ...
> Additionally, the CLASS are wrongly initialized: You only set "_data"
> (indirectly as it is the first field/component of the class) but you do not
> set the _vptr
Hi Janus,
Janus Weil wrote:
here is a fix for class pointer initialization.
I think the patch looks reasonable. However, as soon as I try to use the
variable, I get an ICE in write_global_declarations -> symtab_get_node.
It works if one moves the targets into a module.
I wonder whether the
Hi all,
here is a fix for class pointer initialization. The problem was that
'gfc_get_symbol_decl' did not recognize class pointers properly. The
first version of the patch posted in the PR induced problems with NULL
initialization of class pointers, which are fixed by the attached
second version.
13 matches
Mail list logo
