>> 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
12 matches
Mail list logo
