Dear All,
Somewhat belatedly, I have applied the patch to 5 branch and have
committed as revision 228952.
Closing the PR forthwith.
Paul
On 24 May 2015 at 09:51, Paul Richard Thomas
wrote:
> Dear Andre,
>
> I'll put both points right. Thanks for pointing them out.
>
> Cheers
>
> Paul
>
> On 23
Dear Andre and Mikael,
Thanks for the reviews and the discussion about the name of the
temporary. I went for "source" in the end. The "expr3" was merely
meant to align with the expression
Following Andre's suggestion, I left his additions to another time;
especially since the patch was headin
On Thu, 28 May 2015 16:58:44 +0200
Mikael Morin wrote:
> Le 27/05/2015 23:09, Steve Kargl a écrit :
> > On Wed, May 27, 2015 at 06:24:25PM +0200, Mikael Morin wrote:
> >> Le 27/05/2015 16:07, Andre Vehreschild a ?crit :
> >>> Hi Paul, hi Mikael,
> >>>
> >>> about renaming the identifier emitted:
Le 27/05/2015 23:09, Steve Kargl a écrit :
> On Wed, May 27, 2015 at 06:24:25PM +0200, Mikael Morin wrote:
>> Le 27/05/2015 16:07, Andre Vehreschild a ?crit :
>>> Hi Paul, hi Mikael,
>>>
>>> about renaming the identifier emitted: I would like to keep it short.
>>> Remember,
>>> there is always a n
On Wed, May 27, 2015 at 06:24:25PM +0200, Mikael Morin wrote:
> Le 27/05/2015 16:07, Andre Vehreschild a ?crit :
> > Hi Paul, hi Mikael,
> >
> > about renaming the identifier emitted: I would like to keep it short.
> > Remember,
> > there is always a number attached to it, which makes it unique.
Le 27/05/2015 16:07, Andre Vehreschild a écrit :
> Hi Paul, hi Mikael,
>
> about renaming the identifier emitted: I would like to keep it short.
> Remember,
> there is always a number attached to it, which makes it unique. Furthermore
> does "alloc_source_tmp" sound unnecessarily long to me. It t
Hi Paul, hi Mikael,
about renaming the identifier emitted: I would like to keep it short. Remember,
there is always a number attached to it, which makes it unique. Furthermore
does "alloc_source_tmp" sound unnecessarily long to me. It tastes like we do
not trust the unique identifier mechanism est
Dear Andre,
I am perfectly happy with renaming the rename to "source". I was
attempting to distinguish "atmp" coming from trans-array.c from this
temporary; just as an aid to any possible future debugging.
The rework of the patch looks fine to me as well. Do you want to
commit or should I do so?
On Mon, May 25, 2015 at 07:33:12PM +0200, Mikael Morin wrote:
> Le 25/05/2015 09:30, Paul Richard Thomas a ?crit :
> > Dear All,
> >
> > Lets see if I can get it right this time :-)
> >
> > Note that I have changed the name of the temporary variable in
> > trans_allocate from 'atmp' to 'expr3' so
hello Andre,
Le 25/05/2015 12:24, Andre Vehreschild a écrit :
> Hi Paul,
>
> I am not quite happy with the naming of the temporary variable. When I
> initially set the prefix to "atmp" this was because the variable would be an
> array most of the time and because of the number appended to it shou
Le 25/05/2015 09:30, Paul Richard Thomas a écrit :
> Dear All,
>
> Lets see if I can get it right this time :-)
>
> Note that I have changed the name of the temporary variable in
> trans_allocate from 'atmp' to 'expr3' so that it is not confused with
> array temporaries.
I agree with Andre willin
Hi Paul,
I am not quite happy with the naming of the temporary variable. When I
initially set the prefix to "atmp" this was because the variable would be an
array most of the time and because of the number appended to it should be unique
anyway. However I would like to point out that disclosing an
Dear All,
Lets see if I can get it right this time :-)
Note that I have changed the name of the temporary variable in
trans_allocate from 'atmp' to 'expr3' so that it is not confused with
array temporaries. I am not suree how much of the testcase is
pertinent after the reform of the evaluation of
Hi Paul,
thanks for the answers. I did not want to be nasty, but was just wondering, if
I only I had those problems. Given furthermore, that reviews are sparse lately,
I thought it might help, when a glitch was removed before a reviewer put his
head into it :-)
I am curious though, why we loose m
Dear Andre,
I'll put both points right. Thanks for pointing them out.
Cheers
Paul
On 23 May 2015 at 19:52, Andre Vehreschild wrote:
> Hi Paul,
>
> does this patch apply to current trunk cleanly? I get an issue with the last
> hunk, because all of the prerequisites are gone since r223445. The s
Dear Andre,
To answer your fist question - no, it doesn't. I was working with my
laptop, which is over slow when it comes to
updating. I should have realised that since you are working in this
area that there might be a problem. I discovered it when I did an
update on my workstation this afternoon
Hi Paul,
does this patch apply to current trunk cleanly? I get an issue with the last
hunk, because all of the prerequisites are gone since r223445. The string copy
is completely handled by the trans_assignment at the bottom of the if
(code->expr3) block. Therefore I doubt the patches last hunk is
Dear All,
This patch started out fixing a single source of memory leak and then
went on to fix various other issues that I found upon investigation.
The fortran ChangeLog entry is sufficiently descripive that I do not
think that there is a need to say more.
Bootstrapped and regtested on x86_64/F
18 matches
Mail list logo