Hi all,
sorry, I forgot to svn-add the testcases for the patch of pr60322. I fixed this
with commit r222478.
My apologies for the oversight.
Regards,
Andre
On Thu, 23 Apr 2015 13:34:16 +0200
Andre Vehreschild ve...@gmx.de wrote:
Hi Paul, hi all,
Paul, thanks for the review. I have
Hi Paul, hi all,
Paul, thanks for the review. I have commited this as r222361.
Regards,
Andre
On Thu, 16 Apr 2015 21:13:31 +0200
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
Hi Andre,
The delta patch is OK for trunk and eventual backport to 5.2.
Thanks for all the
Hi Andre,
The delta patch is OK for trunk and eventual backport to 5.2.
Thanks for all the hard work
Paul
On 14 April 2015 at 19:00, Andre Vehreschild ve...@gmx.de wrote:
Hi all,
during further testing of a big Fortran software I encounter two bugs with
class arrays, that are somehow
Hi all,
during further testing of a big Fortran software I encounter two bugs with
class arrays, that are somehow connected to pr60322. I therefore propose an
extended patch for pr60322. Because Paul has already reviewed most the extended
patch, I give you two patches:
1. a full patch, fixing
Hi Paul, hi all,
Paul, thanks for the review. Answers to your questions are inline below:
On Sun, 5 Apr 2015 11:13:05 +0200
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
snip
+ /* The dummy is returned for pointer, allocatable or assumed rank arrays.
+ The check for pointerness
Dear Andre,
Well, time passed and it didn't get done. Too much going on at the moment!
As you say, the patch bootstraps and regtests on x86_64, FC21 in my case.
I am now very reluctant to mess around with the gcc-5 release. Thus, I
think that this patch must be committed to 5.2 and 6.0, when
Dear Andre,
I am in the UK as of last night. Before leaving, I bootstrapped and
regtested your patch and all was well. I must drive to Cambridge this
afternoon to see my mother and will try to get to it either this
evening or tomorrow morning. There is so much of it and it touches
many places; so
Dear Andre,
Everything works as expected with your new patch.
I have changed the test for pr57305 to
use iso_c_binding
implicit none
integer :: i
real, target :: e
class(*), allocatable, target :: a(:)
do i = 1, 3
e = i
call add_element_poly(a,e)
select type (a)
type is (real)
Hi Andre,
Le 24 mars 2015 à 18:06, Andre Vehreschild ve...@gmx.de a écrit :
Hi all,
I have worked on the comments Mikael gave me. I am now checking for
class_pointer in the way he pointed out.
Furthermore did I *join the two parts* of the patch into this one, because
keeping both in
Hi Dominique, hi all,
you are absolutely right, Dominique: I missed the part of pr60322_base_*.
But this time it is there and furthermore does solve the allocate( mold=e) and
the loc(e) issue.
Paul: I have simplified your patch by only checking whether the
arg_expr.ts.type == BT_CLASS. All
Dear Andre,
Dominique pointed out to me that the 'loc' patch causes a ICE in the
testsuite. It seems that 'loc' should provide the address of the class
container in some places and the address of the data in others. I will
put my thinking cap on tonight :-)
Cheers
Paul
On 23 March 2015 at
Hi all,
I have worked on the comments Mikael gave me. I am now checking for
class_pointer in the way he pointed out.
Furthermore did I *join the two parts* of the patch into this one, because
keeping both in sync was no benefit but only tedious and did not prove to be
reviewed faster.
Paul,
Hi Mikael,
thanks for looking at the patch. Please note, that Paul has sent an addendum to
the patches for 60322, which I deliberately have attached.
26/02/2015 18:17, Andre Vehreschild a écrit :
This first patch is only preparatory and does not change any of the
semantics of gfortran at
26/02/2015 18:17, Andre Vehreschild a écrit :
This first patch is only preparatory and does not change any of the semantics
of
gfortran at all.
Sure?
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index ab6f7a5..d28cf77 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@
Le 23/03/2015 13:43, Andre Vehreschild a écrit :
Hi Mikael,
thanks for looking at the patch. Please note, that Paul has sent an addendum
to
the patches for 60322, which I deliberately have attached.
26/02/2015 18:17, Andre Vehreschild a écrit :
This first patch is only preparatory and
Hi Mikael,
This pointer stuff is very difficult to swallow to me.
I totally understand. When doing the patch I had to restart twice, because I
mixed up the development on the class arrays so completely, that I couldn't get
it right again.
I understand that for classes, the CLASS_DATA
Le 23/03/2015 16:49, Andre Vehreschild a écrit :
I see your point. Currently I am bootstraping and regtesting some patches for
commit. While this is running, my machine is nearly unusable. I will look into
this as soon, as my machine allows, but probably not before tomorrow.
There is no
Hi all,
please find attached the first part of a two parts patch fixing pr/60322. This
first patch is only preparatory and does not change any of the semantics of
gfortran at all. It only modifies the compiler code to have the
symbol_attribute and the gfc_array_spec in a separate variable in the
18 matches
Mail list logo
