Hi All,
This patch makes sure that offsets and bounds are correct in passing
derived types to class formal arrays. It is straightforward enough as
not to require explanation.
Bootstraps and regtests on FC25/x86_64 - OK for trunk?
Paul
2018-02-11 Paul Thomas
PR
PR fortran/56691
* gfortran.dg/type_to_class_4.f03: New test.
On 27 January 2018 at 12:41, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> I am worried that this fix seems to easy by half and so I am posting
> it for approval, rather than committing it as obvio
Hi Janus,
As Steve said, welcome back!
I hope that you will post the news of this fix and the correction of
the testcases on clf. Talking of which, have you posted the problems
that others have found as PRs?
It was one of my long deferred tasks to make a start on validating the
testsuite and to
Hi Steve,
That's OK for trunk and, if you are possessed of the intestinal
fortitude, 6- and 7-branches.
Thanks
Paul
On 7 February 2018 at 02:17, Steve Kargl
wrote:
> The attached patch fixes PR fortran/82049. Prior to this
> patch, gfortran was fouling up
Committed a partial patch as 'obvious' in revision 257363.
Oddly, the failing test in associate_35.f90 is the only one that works
in 7-branch. I have left the PR open and changed the title
accordingly.
Paul
2018-02-04 Paul Thomas
PR fortran/84115
* trans-decl.c
Hi Dominique,
The patch is OK.
By all means open the PR for the missing/confusing diagnostics.
Thanks
Paul
On 4 February 2018 at 13:01, Dominique d'Humières wrote:
> Is the following patch OK? For associate_23.f90 I have restricted should_work
> to two elements, an
2018-02-03 Paul Thomas
PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Instead of gfc_get_dtype
use gfc_get_dtype_rank_type.
2018-02-03 Paul Thomas
PR fortran/84141
PR fortran/84155
*
Hi Uros,
This is an easy one to OK :-) Backport it as far back as your patience allows.
Thanks
Paul
On 2 February 2018 at 10:32, Uros Bizjak wrote:
> Hello!
>
> Attached patch removes two statements with no effect. These two
> statements operate with uninitalized
This fixes the reduced testcase provided by Tom de Vries in comment #7
of the PR. Committed as 'obvious' as r257262. Will await a report from
Tom as to whether or not this fixes the original problem
Paul
2018-01-31 Paul Thomas
PR fortran/84088
* trans-expr.c
I am worried that this fix seems to easy by half and so I am posting
it for approval, rather than committing it as obvious. I would be
obliged if somebody would test it thoroughly.
Bootstraps and regtests on FC23/x86_64 - OK for trunk and 7 branch?
Paul
2018-27-01 Paul Thomas
Hi Jakub,
Thanks for the OK and the help in getting the padding sorted out.
Committed as Committed revision 257065.
Paul
On 24 January 2018 at 20:26, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Hi Jakub,
>
> I have made the changes to the types of the dtype el
Hi All,
Given the delay relative to the start of stage 3, I thought that I had
better deal with this asap:
+ /* TODO: this works on any derived type when
+ it should only work with team_type. */
+ if (team->ts.type != BT_DERIVED)
Why don't you give the team_type derived type
Hi Jakub,
The lateness is indeed embarrassing but couldn't be helped.
> Given above my preference would be to keep version an int, and
> change rank and type to signed char and attribute to signed short.
> That way there will be no padding on either 32-bit or 64-bit targets,
> and the structure
Janne, Thanks.
Jakub, is this OK with you?
Paul
On 23 January 2018 at 19:09, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote:
> On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
> <paul.richard.tho...@gmail.com> wrote:
>> This patch has been triggered by Thomas's re
Committed as 'obvious' in revision 256995.
Closing PR.
Paul
2018-23-01 Paul Thomas
PR fortran/83866
* decl.c (gfc_match_derived_decl): If eos not matched, recover
and emit error about garbage after declaration.
2018-23-01 Paul Thomas
Commit as 'obvious' in revision 256994.
I will attend to 6- and 7-branches in a little while.
Paul
2018-23-01 Paul Thomas
PR fortran/83898
* trans-stmt.c (trans_associate_var): Do not set cst_array_ctor
for characters.
2018-23-01 Paul Thomas
Could somebody please review the patch?
Thanks
Paul
On 23 January 2018 at 06:13, Dominique d'Humières
wrote:
> Dear Paul,
>
> The test suite passed without new regression with both -m32 and -m64.
>
> Thanks for the work,
>
> Dominique
--
"If you can't explain
This patch has been triggered by Thomas's recent message to the list.
Not only did I start work late relative to stage 3 but debugging took
somewhat longer than anticipated. Therefore, to get this committed
asap, we will have to beg the indulgence of the release managers and
prompt review and/or
Ping!
On 8 January 2018 at 14:36, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> I post this patch early last year and did not submit because I was up
> to my eyeballs with PR34640. I just forgot about it until it came up
> on clf a few days ago.
>
> Bootstraps
I post this patch early last year and did not submit because I was up
to my eyeballs with PR34640. I just forgot about it until it came up
on clf a few days ago.
Bootstraps and regtests on FC23/x86_64 - OK for trunk?
Paul
2018-01-08 Paul Thomas
PR fortran/52162
*
This patch adds:
(i) Default initializers for parameterized arrays;
(ii) Fixes ordinary assignment of PDTs by implementing the same deep
copy mechanism as for derived types with allocatable components; and
(iii) Fixes the len parameter checking, which failed where the dummy
type had an assumed
Hi Thomas,
That was well spotted by Steve!
OK for trunk.
Thanks
Paul
On 7 January 2018 at 12:23, Thomas Koenig wrote:
> Am 06.01.2018 um 18:45 schrieb Thomas Koenig:
>>
>> Hello world,
>>
>> the attached patch removes explicit use of dtype in the
>> array intrinsics,
n
>
> On January 1, 2018 at 9:44:59 AM, Paul Richard Thomas
> (paul.richard.tho...@gmail.com) wrote:
>
> Committed to trunk as revision 256065.
>
> Damian, it would be good if you would confirm that there are no issues
> with applying the patch to 7-branch.
>
> Than
Hi Thomas,
Dominique has tested this patch and so, except for a few typos that I
communicated to you on #gfortran, this is good for trunk.
Somewhere, I have a list of situations where finalization is required
but not yet implemented. I'll dig it out and post it on the list.
Thanks
Paul
On 31
Hi Thomas,
This looks very good. OK for trunk.
Thanks
Paul
On 2 January 2018 at 15:53, Thomas Koenig wrote:
> Hello world,
>
> the attached patch implements simplification for cshift completely.
> It also fixes a bug where compile-time simplification was handled
>
Committed to trunk as revision 256065.
Damian, it would be good if you would confirm that there are no issues
with applying the patch to 7-branch.
Thanks for all the help.
Paul
On 28 December 2017 at 19:58, Damian Rouson
wrote:
> I applied the patch the trunk and
Hi All,
OK - I'll hold back until I hear from Damian & Zaak.
Cheers
Paul
On 27 December 2017 at 21:06, Damian Rouson
wrote:
>
> Thanks for the additional information Thomas. It sounds like I should test
> Paul’s patch. I should be able to do so today and will
Hi Thomas,
That's a good question. I have kept Damian in copy. It must be said
that the OpenCoarray folk are more concerned with PR83319, where there
is no problem of binary compatibility. I am awaiting some input from
him.
Cheers
Paul
On 27 December 2017 at 17:50, Thomas Koenig
Hi Thomas,
It will break binary compatibility for caf with scalar,
allocatable/pointer components. This comes about because I decided
that the caf tokens for thes components, should come after all other
components, rather than immediately after the "owner" component. This
has the advantage, that
Hi All,
This patch is very straightforward. The PR itself was fixed by not
freeing the parameterized components on leaving function scope. The
lhs expression in the assignment had pointers to parameterized
components that were overwritten on assignment, thereby causing some
memory leakage. This
OK - thanks for the patch.
Paul
On 26 December 2017 at 12:12, Thomas Koenig wrote:
> Hello world,
>
> this rather self-explanatory patch makes sure we don't get an error
> using reallocation on assignment for inlining matmul when
> we don't have reallocation on
Hi All,
This is a complete rework of the patch and of the original mechanism
for adding caf token fields and finding them.
In this patch, the token fields are added to the derived types after
all the components have been resolved. This is done so that all the
tokens appear at the very end of the
Yes - thanks
Paul
On 10 December 2017 at 17:48, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
> On Sun, Dec 10, 2017 at 05:18:53PM +0000, Paul Richard Thomas wrote:
>> Hi Steve,
>>
>> I see that the implementation of the standard is slightly more
>>
Hi Steve,
I see that the implementation of the standard is slightly more
complicated than I thought.
type :: t(a,b)
integer, kind :: a
integer, len :: b
integer(a) :: v(b)
end type t
type(t(4,:)), allocatable :: z1
type(t(4,10)), allocatable :: z2
allocate (t(4, :) :: z1)
Kargl
<s...@troutmask.apl.washington.edu> wrote:
> On Sat, Dec 09, 2017 at 09:09:14AM +0000, Paul Richard Thomas wrote:
>>
>> This is good for trunk with one proviso:
>>
>> This should mutate from:
>> - /* TODO understand why this error does not appear
Hi Steve,
This is good for trunk with one proviso:
This should mutate from:
- /* TODO understand why this error does not appear but, instead,
- the derived type is caught as a variable in primary.c. */
- if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT)
{
-
t_10.f03 : Correct for error in coding the for
kind 4 component and change the kind check appropriately.
* gfortran.dg/pdt_25.f03 : New test.
On 30 November 2017 at 12:47, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> This patch fixes the above PRs and the additional p
This patch fixes the above PRs and the additional problems in comment
#1 of both 82606 and 82622.
For the main part, the patch consists of 'obvious' tweaks to the PDT
machinery. The exception to this is the chunk in
trans-array.c(set_loop_bounds), which is needed to handle
parameterized array
Committed to 7-branch and trunk and r255205 and r255202 respectively.
Paul
On 26 November 2017 at 18:40, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Dear All,
>
> This regression was caused by the patch for PR81447. The chunk that
> has been modified came
This problem is not really a regression but is a "feature" that was
exposed by my patch for PR81447.
The testcase fails because the caf token for the pointer component is
not present in the type. This is fixed in trans-types.c
(gfc_get_derived_type) in the manner described in the ChangeLog.
Dear All,
This regression was caused by the patch for PR81447. The chunk that
has been modified came about because use association of derived types
in block data, in the presence of a vtable, was trying to add vtable
procedures, which is not allowed. The original patch did not
explicitly target
Dear Dominique,
Committed to trunk as revision 254936.
Thanks for picking up the problem and for redoing the testing.
Regards
Paul
Dear All,
This is not quite an 'obvious' patch but it does speak for itself. If
there are no objections in the meantime, I will commit it tomorrow
evening.
Bootstraps and regtests on FC23/x86_64 - OK for trunk? What about 7-branch?
Cheers
Paul
2017-11-18 Paul Thomas
Dear Dominique,
Please find attached a revised patch that I believe fixes the problem
that you found. The changes are the additions in trans-decl.c.
OK for trunk and 7-branch?
Paul
2017-11-18 Paul Thomas
PR fortran/78990
* expr.c (gfc_is_class_array_function):
Hi Thomas,
This is OK.
Thanks
Paul
On 17 November 2017 at 17:38, Thomas Koenig wrote:
> Hello world,
>
> the attached patch fixes the PR by looking at the function interface if
> one exists.
>
> Regression-tested. OK for trunk?
>
> Regards
>
> Thomas
>
>
Hi Dominique,
Quite suddenly, I am seeing fault too. I don't know what has changed.
I'm on to it.
Thanks
Paul
On 15 November 2017 at 11:40, Dominique d'Humières wrote:
> Hi Paul,
>
> Your patch fixes the ICE and pass the tests. However I see
>
> At line 22 of file
This turned out to be quite a challenging debugging job as often seems
to be the case where the scalarizer is involved. Ultimately, I found
that the testcase compiled when return_t1 was made a pointer and the
resulting code revealed where the problems lay. This modified testcase
now works as well
Committed as obvious in r254624.
I will apply to 6- and 7-branches over the weekend. Although not a
regression, the fix prevents an ICE in a particularly robust way.
Cheers
Paul
2017-11-10 Paul Thomas
PR fortran/82934
* trans-stmt.c (gfc_trans_allocate): Remove
This regression arose from the patch for PR66465, in which the type
check for the associated intrinsic was failing when testing the
association of a procedure pointer component with a procedure pointer.
See the comment in the patch for an explanation as to why this is an
issue. The fix is to
Dear All,
This is a heads up that, in a few hours, I will apply a patch for
PR69739 as 'obvious' unless there are any objections in the mean time.
This regression dates back to the time, nearly seven years ago, when I
did some work on gfc_map_intrinsic_function. I couldn't figure out how
to deal
Committed to 7-branch as revision 254429.
Paul
On 5 November 2017 at 12:44, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Hi Andre and Thomas,
>
> Thanks for looking at this.
>
> I left the condition as it is because it is the same practice as all
&
Hi Steve,
Committed to trunk as revision 254428.
I will follow with 6- and 7-branches later in the week.
Thanks
Paul
On 4 November 2017 at 14:46, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
> On Sat, Nov 04, 2017 at 12:02:58PM +0000, Paul Richard Thomas wrote:
&g
Hi Andre and Thomas,
Thanks for looking at this.
I left the condition as it is because it is the same practice as all
sorts of other parts of gfortran. That said, Thomas's suggestion is I
think the right one.
Committed revision as revision 254427. 7-branch will come later.
Regards
Paul
On 4
Hi Andre,
These patches look fine to me. Thanks for taking account of the array
descriptor change between trunk and 7-branch :-)
OK for trunk and 7-branch.
Thanks
Paul
On 4 November 2017 at 10:27, Andre Vehreschild wrote:
> Ping!
>
> On Wed, 1 Nov 2017 12:27:11 +0100
> Andre
Dear All,
This patch allows the assignment of class array constructors to
derived type arrays. It is straightforward enough that the ChangeLogs
and the comment are sufficient explanation.
Bootstraps and regtests on FC23/x86_64 - OK for all three branches?
Paul
2017-11-04 Paul Thomas
Corrected in trunk in revision 254404.
Cheers
Paul
On 3 November 2017 at 19:22, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> This was already fixed by the patch for PR82375 on trunk, albeit less
> well than the patch applied here. I will correct trunk tomorrow.
&
This was already fixed by the patch for PR82375 on trunk, albeit less
well than the patch applied here. I will correct trunk tomorrow.
Committed as 'obvious' on 6-branch(r254393) and 7-branch(r254389)
after bootstrapping and regtesting.
Cheers
Paul
2017-11-03 Paul Thomas
Dear All,
Please find attached the revised version of the patch following my
late realizations in yesterday's submission.
Cheers
Paul
On 1 November 2017 at 18:22, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Dear All,
>
> This patch is adequately described
Hi Steve,
I read the correspondence on clf and your earlier posting here. With
those in mind, the patch looks to be OK to commit.
Thanks
Paul
On 2 November 2017 at 01:09, Steve Kargl
wrote:
> The attached patch fixes a regression where gfortran was
> issuing
Dear All,
This patch is adequately described by the comment in the second chunk
applied to resolve.c.
Note, however, that the 'unconditionally' is promptly undermined by
the subsequent conditions. I will change the adjective appropriately.
In writing this, I have just realised that
Committed to 7-branch as revision 254293. I will close the PR now.
Cheers
Paul
On 30 October 2017 at 22:16, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Dear Andre,
>
> Committed to trunk as revision 254244.
>
> In order to debug the code, I was f
that I inserted the check for _len > 0 in allocate(). So
> it was me causing the bug. Thanks that you found it. The patch looks good to
> me. Thanks for the work.
>
> - Andre
>
> On Mon, 30 Oct 2017 12:20:20 +
> Paul Richard Thomas <paul.richard.tho...@gmail.com> wrot
Hi Steve,
It looks good to me - OK.
Thanks
Paul
On 30 October 2017 at 18:05, Steve Kargl
wrote:
> The attached patch fixes the failure of gfortran.dg/dtio_13.f90
> on at least FreeBSD. This test has been failing for a very long
> time. In resolve_transfer,
; Hi Paul,
>
> whoopsie, I remember that I inserted the check for _len > 0 in allocate(). So
> it was me causing the bug. Thanks that you found it. The patch looks good to
> me. Thanks for the work.
>
> - Andre
>
> On Mon, 30 Oct 2017 12:20:20 +
> Paul Richard Thoma
Dear All,
This bug took a silly amount of effort to diagnose but once done, the
fix was obvious.
The bug is triggered in this function from the reporter's source file
gfc_graph.F90:
function GraphIterAppendVertex(this,vertex) result(ierr)
!Appends a new vertex to the graph.
Dear All,
Thanks to Dimitry Liakh for both reporting the problem and doing a lot
of the diagnostic work. Once the offending line in a very complicated
code was located, the fix was trivial. Generating a reduced testcase
took rather longer :-)
The comment in the testcase tells the story. The fix
an.dg/pdt_18.f03 : New test.
On 20 October 2017 at 18:17, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Dear All,
>
> The attached patch is pretty clear with the ChangeLogs and is very
> nearly obvious.
>
> Bootstrapped and regtested on FC23/x86_64 - OK for
Dear All,
The attached patch is pretty clear with the ChangeLogs and is very
nearly obvious.
Bootstrapped and regtested on FC23/x86_64 - OK for trunk?
Paul
2017-10-20 Paul Thomas
PR fortran/82586
* decl.c (gfc_get_pdt_instance): Remove the error message that
rter.net> wrote:
> On 10/17/2017 11:33 AM, Paul Richard Thomas wrote:
>> The attached patch has a comment that explains what is going on.
>>
>> Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 7-branch?
>>
>
> Yes, looks OK for both. Thanks.
>
>
The attached patch has a comment that explains what is going on.
Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 7-branch?
Paul
2017-10-17 Paul Thomas
PR fortran/82550
* expr.c (gfc_check_pointer_assign): A use associated procedure
target in a
Good you caught the missing LF. Thanks!
Paul
On 13 October 2017 at 19:29, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
> On Fri, Oct 13, 2017 at 07:06:57PM +0100, Paul Richard Thomas wrote:
>>
>> This patch undoes a side effect of r225447 that had the eff
Dear All,
This patch undoes a side effect of r225447 that had the effect of
eliminating the default intialization of derived type array results.
The patch corrects the offending changes to the condition in resolve_symbol.
Bootstraps and regtests of FC23/x86_64 - OK for trunk, 7- and 6-branches?
Hi Thomas,
I thought that the suggestion to add the original input lines was not
bad. It would be even better if -fdump-tree-original could do that. I
often time find myself putting a line under the spotlight in a
contained subroutine.
Thanks for working on -fdump-parse-tree.
Cheers
Paul
On 8
Dear All,
I ran into Ian Chivers in last week's BCS meeting, who told me that he
had found a PDT bug. My response was to post it on Bugzilla, which he
did promptly :-) So promptly, in fact, that I felt honour bound to
respond in kind.
Please find attached a patch to fix his bug and the
Committed as revision 253400.
Thanks for the review and the test.
Paul
On 1 October 2017 at 14:24, Thomas Koenig wrote:
> Hi Paul,
>
>> The attached patch fixes the PR and most of the remaining, if not all,
>> problems associated with deferred string length targets in
Committed as revision 253362.
Thanks for taking a look at it. I will wait a week or so before
committing to 7-branch.
Paul
On 1 October 2017 at 14:43, Thomas Koenig wrote:
> Hi Paul,
>
>> Bootstraps and regtests on FC23/x86_64 - OK for trunk and 7 branch?
>
>
> OK for
The attached patch fixes the PR and most of the remaining, if not all,
problems associated with deferred string length targets in the
associate construct.
Bootstraps and regtests on FC23/x86_64 - OK for trunk?
Paul
2017-09-29 Paul Thomas
PR fortran/77296
*
Greetings to all,
This patch fixes a bug where the pointer assignment to the derived
component of a class entity was resulting in the base entity's vptr
being set to the vtable of the target. This resulted in the wrong
typebound procedure being called.
The patch corrects the logic in resolve
Hi Steve,
I'll take your word for it on the F2008 contraints. Given that the
patch is very good - OK for trunk.
Thanks
Paul
On 27 September 2017 at 20:36, Steve Kargl
wrote:
> The attached patch fixes PR fortran/81509.
>
> In short, F2008 now allows
2017 at 19:41, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Dear Jerry,
>
> Thanks! Committed as revision 253077.
>
> Cheers
>
> Paul
>
> On 21 September 2017 at 01:52, Jerry DeLisle <jvdeli...@charter.net> wrote:
>> On 09/20/2017 09:45 A
Dear Jerry,
Thanks! Committed as revision 253077.
Cheers
Paul
On 21 September 2017 at 01:52, Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 09/20/2017 09:45 AM, Paul Richard Thomas wrote:
>> In the last update to the Parameterized Derived Types implementation,
>> I fi
In the last update to the Parameterized Derived Types implementation,
I fixed PR60483 as a side effect. I then checked all the ASSOCIATE
bugs and noted that I was responsible for a number of regressions due
to a patch that I applied last year. I determined to fix them and
found that I couldn't
Hi Janus et al.,
I had to do this quickly because of time pressure and I thought it to
be most efficient while the main patch was fresh in my mind.
Committed as revision 252039 with attributions suitably modified.
Thanks
Paul
On 11 September 2017 at 20:50, Janus Weil
Hi Steve,
This looks fine from the fortran side - especially since it involves
removing checks :-)
Thanks
Paul
On 12 September 2017 at 18:34, Steve Ellcey wrote:
> Ping, also adding fort...@gcc.gnu.org which I seem to left out when
> sending this to
Dear Dominique,
That error is perfectly correct. Change the order of the assignment
and the declaration for 'b' and you will see that all is well.
The matching of type parameter specification list follows the same
rules as those of actual arguments, except that deferred and assumed
expressions
Dear Janus,
My profuse apologies for the mis-identification, thereby not giving
you the credit. The testcases will, of course be reattributed.
Best regards
Paul
On 11 September 2017 at 20:50, Janus Weil wrote:
> Hi Paul,
>
>> I have fixed all the PDT bugs that have been
Dear Thomas, dear All,
I have fixed all the PDT bugs that have been reported to me so far in
the attached patch. The patch is straightforward and is commented for
clarity where necessary. Please note that whitespace changes have been
suppressed. For this reason, if you are tempted to try the
Dear All,
The patch has been committed as revision 251925.
I look forward to "feedback" (aka PRs) in the coming weeks. I will
return to Parameterized Derived Types at the end of this month to
clear up some of the known deficiencies (see the notes attached to the
patch submission) and any PRs
Hi Jerry,
That looks good to me - OK for trunk and for backporting.
Thanks for the patch.
Paul
PS Did you have time to think about that rather more difficult bug,
involving a mix of DT descriptors and intrinsic descriptors for the
declared type?
On 21 August 2017 at 03:23, Jerry DeLisle
Hi Thomas,
It looks fine to me. OK for trunk.
Thanks
Paul
PS What about PR34640 ?
On 9 August 2017 at 20:44, Thomas Koenig wrote:
> Am 02.08.2017 um 15:19 schrieb Thomas Koenig:
>>
>> the attached patch is a bit smaller than it looks, because most of
>> it is due
Hi Thomas,
This is 'obvious, I think. Yes, OK for trunk.
Thanks
Paul
On 1 August 2017 at 16:09, Thomas Koenig wrote:
> Am 24.07.2017 um 23:27 schrieb Thomas Koenig:
>>
>> Hello world,
>>
>> the attached patch fixes the PR; patch and test case are rather
>>
Hi Thomas,
This reminds me of project that I once started to translate fortran
into C using a similar option. I gave up in the end because I found it
more convenient to use a tree dump and modify the declarations by
hand. In respect of your query about suggestions, how about outputting
whitespace problems on the
fly.
Best regards
Paul
On 11 July 2017 at 15:48, Jerry DeLisle <jvdeli...@charter.net> wrote:
> On 07/11/2017 07:23 AM, Paul Richard Thomas wrote:
>> Well, a bit earlier than anticipated, here is the final version that
>> puts right all the wrink
Hi Jerry and Thomas,
As Thomas noted, the span field is added in the middle of the
descriptor because the caf token field makes the descriptor variable
length. This is reflected in the change in libgfortran.h.
It has crossed my mind in the last twenty four hours that I should add
some more
Dear All,
We are not quite there yet. Thanks to the posters to the thread on
clf, I have now been convinced that ptr => der_type_array%comp must
return an lbound=1 based descriptor, since the target is not a WHOLE
ARRAY as defined in the standard. In addition, Dominique picked up a
failing
Hi Thomas, Hi All,
Please find attached what I believe is the final version of the patch.
The problem concerning temporaries being generated in lieu of the
descriptor being passed directly - see pointer_array_7.f90 and the
change to subref_array_4.f90. This latter necessitated a thread on clf
to
Hi Thomas,
The patch is OK by me.
Thanks for working on speeding up these library functions. Does the
octave version, mentioned in the clf thread, translate easily into C?
I had to remind myself of how octave cell arrays function. It is
certainly a remarkably concise solution.
Cheers
Paul
On
Hi Thomas,
The timings are impressive! OK for trunk.
Thanks
Paul
On 1 July 2017 at 14:48, Thomas Koenig wrote:
> Hello world,
>
> the attached patch implements the blocked algorithm for
> constant shift for dim > 1 for eoshift0 (which handles
> the case of constant
Paul Thomas <pa...@gcc.gnu.org>
PR fortran/34640
* libgfortran/libgfortran.h: Add span field to descriptor.
On 24 June 2017 at 11:48, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Dear All,
>
> Please find attached a draft patch for the above PR, together w
at 11:48, Paul Richard Thomas
<paul.richard.tho...@gmail.com> wrote:
> Dear All,
>
> Please find attached a draft patch for the above PR, together with PRs
> 40737, 55763, 57019 and 57116. These PRs constitute problems
> associated with the last F95 feature that gfortran does not c
501 - 600 of 1204 matches
Mail list logo