Dear Andre,
Don't worry about the lack of a laptop. I am on to it :-)
Paul
On 17 January 2015 at 16:14, Andre Vehreschild wrote:
> Dear Paul,
>
> Setting _Len to one by default should be quite simple. When I remember
> correctly, then there is only one place where the current code sets it to
Cancel that - It should be multiplies by kind, shouldn't it ? :-) OK,
string length it is. We will probably have to set _len = 1 for other
dynamic types, though, so that the pointer arising from an array
reference is base_address + _len*vptr->size*index
Cheers
Paul
On 17 January 2015 at 13:44, P
Dear Andre,
I am open to either - what do the others think?
The reason why I am for differentiating between unlimited_polymorphic
objects and the deferred length character arrays is because of the
difference in the way in which arrays are accessed. The former uses
pointer arithmetic and the latte
Dear Andre,
Perhaps, rather than calling the new component _len, we should call it
_mem_size or some such?
Cheers
Paul
On 9 January 2015 at 11:52, Andre Vehreschild wrote:
> Hi all, hi Paul,
>
> I started to implement the changes requested below, but I stumbled over an
> oddity:
>
> For a defe
Hi all, hi Paul,
I started to implement the changes requested below, but I stumbled over an
oddity:
For a deferred length kind4 char array, the length of the string is stored
without multiplication by 4 in the length variable attached. So when we now
decide to store the length of the string in an
Dear Andre,
Thanks for the patch. As I have said to you, off list, I think that
the _size field in the vtable should contain the kind information and
that the _len field should carry the length of the string in bytes. I
think that it is better to optimise array access this way than to
avoid the di
Hi Janus, hi Paul, hi Tobias,
Janus: During code review, I found that I had the code in
gfc_get_len_component() duplicated. So I now reintroduced and documented the
routine making is more commonly usable and added more documentation. The call
sites are now simplify.c (gfc_simplify_len) and trans-e
Hi Andre,
I have posted my results with your patch (and those for pr63851) at
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02408.html.
I don’t see any problem with unlimited_polymorphic_2.f90. However the character
lengths are now wrong (they are 0) with your old patch for pr60289 at
https
Hi all,
here is my next try on proposing a patch for the issue in pr60255. It took me
quite some time to understand the intricacies with handling variables
associated in a select type. I think I got most of the issues fixed now:
- Added generation of _len component for each unlimited polymorphic
Dear Andre,
The patch causes an ICE for the test gfortran.dg/unlimited_polymorphic_1.f03:
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:236
f951: internal compiler error: Abort trap: 6
gfc: internal compiler error: Abort trap: 6 (program f951)
Abort
Reduced test fo
Hi Paul,
> s/furure/future/ :-)
Hups, fixed.
> Why are you using a double underscore in get__len_component?
Because the component is called _len. The routine should be called "get _len
component", but spaces aren't allowed :-) Anyways, does this violate some style
guide? Should I remove one of
Dear Paul,
The problem for oo.f90 is pr 55901.
I am updating my working tree with Andre’s patch.
Cheers,
Dominique
> Le 8 déc. 2014 à 21:20, Paul Richard Thomas a
> écrit :
>
> Dear Andre,
>
> s/furure/future/ :-)
>
> Why are you using a double underscore in get__len_component?
>
> More
Hi all,
please find attached a more elaborate patch for pr60255. I totally agree that
my first attempt was just scratching the surface of the work needed.
This patch also is *not* complete, but because I am really new to gfortran
patching, I don't want to present a final patch only to learn then,
> the testcase should check that the code generated is actually working,
> not just that the ICE disappeared.
I agree. Note that there is a test in the comment 3 of PR60255 that
can be used to check the run time behavior (and possibly check the
vtab issue).
Dominique
Le 07/08/2014 15:40, Andre Vehreschild a écrit :
> Hi,
>
> in the bugtracker for PR60255 janus proposed to fix the bug by removing
> the error and additionally checking if the character array length
> declaration is deferred, which leaves the the charlen to be 0
> (gcc/fortran/class.c (find_intrin
Hi,
in the bugtracker for PR60255 janus proposed to fix the bug by removing
the error and additionally checking if the character array length
declaration is deferred, which leaves the the charlen to be 0
(gcc/fortran/class.c (find_intrinsic_vtab) 2418-2420).
My contribution to that patch is the
16 matches
Mail list logo
