11:48, Paul Richard Thomas
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 completely
> implement.
>
>
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 completely
implement.
I want to sound out if this is acceptable as the way to fix these
problem
Hi Fritz,
Yes, that's good for trunk.
Thanks
Paul
On 17 May 2017 at 16:51, Fritz Reese wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79968
>
> All,
>
> The PR suggests unifying diagnostics of the form "%s at %C is a DEC
> extension, enable with ..." I think the patch is obvious/trivia
Hi Jerry,
OK for trunk and for 7-branch after a delay.
Cheers and thanks
Paul
On 17 May 2017 at 06:34, Jerry DeLisle wrote:
> Hi all,
>
> When I first looked at this I thought the minor front end bobble was the
> problem. That turns out to be unrelated but needed to be fixed in trans-io.c
>
>
Hi Jerry and Steve,
Thanks for taking a peek - committed as revision 248129.
I'll commit to 7-branch in a couple of weeks.
Cheers
Paul
On 15 May 2017 at 21:29, Jerry DeLisle wrote:
> On 05/15/2017 04:10 AM, Paul Richard Thomas wrote:
>>
>> The attached bootstraps and reg
The attached bootstraps and regtests on FC23/x86_64 - OK for trunk and
later for 7-branch?
The comment in the patch and the ChangeLog are sufficiently clear that
no further explanation is needed here.
Cheers
Paul
2017-05-15 Paul Thomas
PR fortran/80554
* decl.c (build_sym): In a sub
Hi Jerry,
This patch is good for both trunk and 7-branch.
Thanks!
Paul
On 11 May 2017 at 16:35, Jerry DeLisle wrote:
> And the actual patch ...
>
> On 05/11/2017 08:30 AM, Jerry DeLisle wrote:
>>
>> Hi all,
>>
>> The attached patch fixes this issue by moving the DTIO namelist checks
>> from n
Dear Thomas,
Thanks for doing the testing. Since we are now into 8-branch, I intend
to fix PR34640 completely, using what I learned with this patch.
Cheers
Paul
On 27 April 2017 at 20:33, Thomas Koenig wrote:
> Hello Paul,
>
>> The attached fixes the problem withPR51218 and bootstraps and regt
Hi Jerry,
OK for trunk and 7-branch, when it reopens.
Thanks for keeping Walt happy :-)
Cheers
Paul
On 23 April 2017 at 03:28, Jerry DeLisle wrote:
> Hi all,
>
> The attached patch fixes these issues.
>
> Regression tested on x86_64-pc-linux-gnu. New test attached.
>
> OK for Trunk (8)? I th
Committed as revision 246952.
Thanks for finding this deadwood.
Cheers
Paul
On 16 April 2017 at 20:18, Janus Weil wrote:
> Hi Paul,
>
>> Prompted by this thread, I have just tried eliminating the call and
>> the function altogether. No problem, the regtesting went through
>> without a problem.
Dear Dominique,
The attached fixes the problem withPR51218 and bootstraps and regtests
on FC23/x86_64 - OK for trunk?
Cheers
Paul
2017-04-13 Paul Thomas
PR fortran/34640
* expr.c (gfc_check_pointer_assign): Exclude pointer array
components in test for 'subref_array_pointer' attr
Dear Nicolas,
The reasons are (i) moving country and (ii) the daytime job :-)
I think that in the circumstances somebody else should OK the patch,
although I think that it is perfect in every way possible.
Actually, perhaps it is sufficiently obvious that I would and should
have committed it - O
Hi Janus,
The patch is OK for trunk.
Thanks
Paul
On 7 April 2017 at 17:51, Janus Weil wrote:
> ping!
>
> 2017-03-29 22:25 GMT+02:00 Janus Weil :
>> Hi all,
>>
>> here is a patch that enhances the diagnostics for procedure-pointer
>> assignments, so that procedure-pointer components that need
Dear All,
This is not a fix for the original PR but for the specific case of
pointer array components of derived types that point to components of
arrays of derived types. The original case involving pointer arrays
being passed as actual arguments remains to be done.
The fix is straightforward an
Hi Jerry,
This looks fine to me. OK for trunk.
Thanks for the patch.
Paul
On 25 March 2017 at 13:41, Jerry DeLisle wrote:
> Hi all,
>
> I managed to figure out the rest of this.
>
> Attached is updated full patch. I consolidated the two previous test cases
> into one which checks all four cond
Hi Jerry,
Committed as revision 246476.
Thanks
Paul
On 25 March 2017 at 14:12, Jerry DeLisle wrote:
> On 03/25/2017 06:28 AM, Paul Richard Thomas wrote:
>> Dear All,
>>
>> This regression arose from my patch for PR79382. I have removed the
>> compile time error bu
Dear All,
This regression arose from my patch for PR79382. I have removed the
compile time error but have prevented the ICE by ensuring that the
dtio generic symbol has flavor FL_PROCEDURE. dtio_23.f90 has been
modified to incorporate the test for this PR and not to check for the
now absent error
Dear Nicolas,
This is indeed an obvious fix and it's OK for trunk
However, we would prefer it that you submit even blindingly obvious
patches for a while. You can generally get rapid approval for such
patches by joining us on #gfortran.
Thanks for the patch.
Paul
PS Are you going to have a sta
able
> is BIND(C).
>
> 2017-03-12 Nicolas Koenig
>
> PR fortran/39239
> * gfortran.dg/equiv_constraint_bind_c.f90: New test.
>
>
> On 03/19/2017 01:02 PM, Paul Richard Thomas wrote:
>>
>> Hi Nicolas,
>>
>> Is there some reason tha
Hi Nicolas,
Is there some reason that you didn't use symbol.c(check_conflict)? The
conflict check could be added at line 547. If this results in
repetitions of the error message, then your patch is OK. Otherwise, I
would pop it in there.
Do you have commit rights? ie. have you done the FSF paperw
Dear All,
OK'd by Steve and committed as revision 246256.
Cheers
Paul
On 27 February 2017 at 19:23, Paul Richard Thomas
wrote:
> Dear All,
>
> This bug resulted from a cock-up on my part. The mechanism for
> suppressing .smod files depended on detecting the presence of a modu
February 2017 at 15:58, Paul Richard Thomas
wrote:
> Dear All,
>
> The title in this PR turned out to be a red herring. The problem is with a
> procedure being a dummy in a submodule module procedure declaration; most
> particularly the abreviated form.
>
> The comments in the fix
Hi Jerry,
This is OK for trunk.
Thanks for doing this. Hopefully we will have a really good
implementation of UD-DTIO in time for the release of 7.1.
I am progressing through submodule bugs for the same reason.
Cheers
Paul
On 10 March 2017 at 18:17, Jerry DeLisle wrote:
> Hi all,
>
> The att
Patch committed as obvious/trivial. I didn't think that it warranted a
testcase since there is no way that this one will come back.
Thanks for the report.
Paul
-- Forwarded message --
From: pault at gcc dot gnu.org
Date: 28 February 2017 at 19:32
Subject: [Bug fortran/79739] [
Dear All,
This bug resulted from a cock-up on my part. The mechanism for
suppressing .smod files depended on detecting the presence of a module
procedure by resetting a flag if the module_procedure attribute was
written. Of course, this didn't happen if the module procedure is
private, which rathe
I also forgot the attachment
. ***duuuh***
On 26 February 2017 at 16:01, Paul Richard Thomas
wrote:
> I forgot to switch on 'plain text' mode - apologies
>
> Paul
>
> On 26 February 2017 at 15:58, Paul Richard Thomas
> wrote:
>>
>> Dear All,
>>
I forgot to switch on 'plain text' mode - apologies
Paul
On 26 February 2017 at 15:58, Paul Richard Thomas
wrote:
>
> Dear All,
>
> The title in this PR turned out to be a red herring. The problem is with a
> procedure being a dummy in a submodule module pr
Dear All,
These trivial bugs have been fixed in revision 245603.
2017-02-20 Paul Thomas
PR fortran/79599
* interface.c (check_dtio_arg_TKR_intent): Supply 'must'
missing from error message.
2017-02-20 Paul Thomas
PR fortran/79523
* interface.c (gfc_find_typebound_dtio
Dear All,
Committed as revision 245596.
Thanks for the review.
Paul
On 16 February 2017 at 18:38, Jerry DeLisle wrote:
> On 02/16/2017 03:31 AM, Paul Richard Thomas wrote:
>>
>> Dear All,
>>
>> The fix for the original bug is tested in dtio_24.f90. It is triggered
Hi Everybody,
Committed as revision 245595.
Thanks for the review.
Paul
On 16 February 2017 at 00:38, Jerry DeLisle wrote:
> On 02/15/2017 10:12 AM, Paul Richard Thomas wrote:
>> Dear All,
>>
>> Another straightforward patch, although it took some head scratching
>>
Hi Jerry,
Committed as revision 245582.
Thanks for the review.
Paul
On 16 February 2017 at 00:37, Jerry DeLisle wrote:
> On 02/15/2017 10:01 AM, Paul Richard Thomas wrote:
>> Dear All,
>>
>> This patch is straightforward, verging on 'obvious'.
>>
>>
Hi Everybody,
With Jerry's OK for a commit to trunk, committed as revision 245580.
I will wait a few weeks before a commit to 6-branch.
Cheers
Paul
On 11 February 2017 at 13:24, Paul Richard Thomas
wrote:
> Ping!
>
> On 8 February 2017 at 16:00, Paul Richard Thomas
> w
Dear Jerry,
> OK for trunk. Not applicable for 6-branch
dh! Thanks
> Yes OK as long as we are not in freeze.
This is not, strictly speaking what we all agreed about a year ago; ie
that we would try to abide by gcc conditions. However, I see that
everybody else is committing to their heart'
Dear All,
The fix for the original bug is tested in dtio_24.f90. It is triggered
by the PRIVATE statement in the module and occurs because there is no
such generic interface in the module. Note, however, that there is a
typebound generic interface, which should not be affected by the
PRIVATE state
Dear All,
Another straightforward patch, although it took some head scratching
to realize how simple the fix could be :-)
Bootstraps and regtests on FC23/x_86_64 - OK for trunk and 6-branch?
Cheers
Paul
2017-02-15 Paul Thomas
PR fortran/79434
* parse.c (check_component, parse_union
Dear All,
This patch is straightforward, verging on 'obvious'.
Bootstraps and regtests on FC23/x86_64 - OK for trunk and 6 branch?
Cheers
Paul
2017-02-15 Paul Thomas
PR fortran/79447
* decl.c (gfc_set_constant_character_len): Whitespace.
(gfc_match_end): Catch case where a proc
Ping!
On 8 February 2017 at 16:00, Paul Richard Thomas
wrote:
> Dear All,
>
> The attached rework of the patch functions in the same way as
> yesterday's but is based in resolve.c rather than trans-decl.c. It
> looks to me to be by far cleaner.
>
> Bootstraps and regtes
79344
* resolve.c (fixup_unique_dummy): New function.
(gfc_resolve_expr): Call it for dummy variables with a unique
symtree name.
2017-02-08 Paul Thomas
PR fortran/79344
* gfortran.dg/submodule_23.f90: New test.
On 7 February 2017 at 16:06, Paul Richard Thomas
wrote:
>
Dear All,
This bug generates an ICE because the symbol for dummy 'n' in the
specification expression for the result of 'fun1' is not the same as
the symbol in the formal arglist. For some reason that I have been
unable to uncover, this false dummy is associated with a unique
symtree. The odd thing
Hi Andre,
This is getting to be a bit monotonous :-) OK for trunk.
Thanks for the three patches.
Paul
PS Are you in a position to have a stab at PR79344? This would go a
long way to sorting out Juergen's test suite. Also, this must be the
third time that I have been involved in breaking iso_var
Hi Andre,
This looks to be OK for trunk.
Thanks for the patch.
Paul
On 4 February 2017 at 13:11, Andre Vehreschild wrote:
> Hi all,
>
> attached patch takes the _len-component of unlimited polymorphic objects into
> account, when source-ALLOCATEing an unlimited polymorphic object. The testcase
Hi Andre,
This looks fine to me - OK for trunk.
Thanks
Paul
On 4 February 2017 at 11:59, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes a regression when a polymorphic pointer component was
> present. The results was a double free. The attached patch fixes this, by not
> caring ab
Hi Jakub,
That's OK - thanks
Paul
On 22 January 2017 at 20:38, Jakub Jelinek wrote:
> Hi!
>
> OpenMP 4.5 allows !$omp declare simd, !$omp declare target and !$omp simd
> in pure and elemental procedures. Fixed thusly, bootstrapped/regtested on
> x86_64-linux and i686-linux, committed to trunk.
Hi Jakub,
Yes, of course - OK for trunk.
Thanks
Paul
On 20 January 2017 at 23:32, Jakub Jelinek wrote:
> Hi!
>
> The Fortran FE has huge amounts of -Wformat-security warnings everywhere,
> but in the end they are only a result of a few commonly used things:
> 1) gfc_get_string uses a printf-li
Hi Andre and Dominique,
Apart from s/allows there allocation/allows their allocation/ this is
OK for trunk.
Given the scale of the patch, can this really be a regression?
Thanks
Paul
On 7 January 2017 at 13:47, Dominique d'Humières wrote:
> I have this patch in my working tree and it works a
Dear Janus,
> If (2a) is false and (2b) is true, the reference is to the procedure
> identified by the appropriate specific
> interface in the interface block. This reference shall not be to a
> dummy procedure that is not present,
> or to a disassociated procedure pointer.
>
I also reread this p
Hi Janus,
Thanks for taking on the cleaning up of the dtio for me. I am up to my
eyeballs in things other than gfortran.
This patch is OK for trunk since it fixes a regression.
Looking at it, though, I realised that dynamic dispatch would be
possible. If, as each derived type is being resolved,
Dear Janus,
We got there! OK for trunk.
This was a demonstration of the corollary of the "bon mot" from Barack
Obama at the end of the message :-)
Many thanks for finding the right path.
Paul
On 13 December 2016 at 10:23, Janus Weil wrote:
> 2016-12-13 10:58 GMT+01:00 Janus Weil :
>> 2016-12-
Dear Janus,
I woke up in the middle of the night realising that not only are you
right about the need for dynamic dispatch but that my dtio_20.f90 must
already work.
Thanks for putting me right!
Paul
On 13 December 2016 at 00:30, Janus Weil wrote:
> Hi Paul, hi all,
>
> 2016-12-12 21:04 GMT+01
Dear All,
The original testcase appears here as dtio_19.f90. I gather that some
vendors accept this, while fort does not. IMHO ifort is correct here
since there is no specific DTIO procedure present. However, it could
be that a more helpful error message to the effect that this is an
abstract type
Hi Janus,
The patch is good - OK for trunk.
Thanks
Paul
On 12 December 2016 at 16:52, Janus Weil wrote:
> Hi all,
>
> I hate to ping this patch once more, but somehow we need to come to a
> conclusion here.
>
> The issue boils down to the fact that there is a piece of code in the
> gfortran co
Hi Andre,
Thanks for doing this work with the instrumented compiler. It was a
great help with PR78350.
As for the patch - OK for trunk.
Paul
On 11 December 2016 at 14:01, Andre Vehreschild wrote:
> Hi Mikael, hi Jerry, hi Steve, hi Jane, hi Thomas, hi Paul, hi all,
>
> thanks for all the input
2016 at 01:54:34PM +0200, Janne Blomqvist wrote:
>> On Fri, Dec 9, 2016 at 1:47 PM, Paul Richard Thomas
>> wrote:
>>
>> I'm seeing the same thing, I guess. Or rather that the ts->type == 81
>> which is non-sensical. No idea where that comes from..
>>
&
n to only failing on Darwin, then filter the
> testcases not to run on that system.
>
> - Andre
>
> Am 7. Dezember 2016 22:44:15 MEZ, schrieb Paul Richard Thomas
> :
>>Dear Dominique,
>>
>>Thanks for the feedback. However, I don't know what to do about i
p = 0x7f, ignore_pass = 0,
assign = 0}, character = {length = 471, string = 0x410066},
constructor = 0x1d7}}
It is the expr_type == = that causes the ICE in gfc_code2string.
Cheers
Paul
On 8 December 2016 at 22:33, Steve Kargl
wrote:
> On Thu, Dec 08, 2016 at 07:58:37AM
On 5 December 2016 at 21:01, Paul Richard Thomas
wrote:
> Dear All,
>
> It took me an excessively long time to realise that processing the
> typespec for an explicitly typed module procedure was wiping out the
> interface symbol and so preventing the comparison of characteristic
Hi Steve,
"Accidence" == state of fixing non-deterministic ICEs? :-)
OK for trunk.
Thanks for dealing with this kind of dead wood.
Cheers
Paul
On 8 December 2016 at 06:10, Steve Kargl
wrote:
> On Wed, Dec 07, 2016 at 08:51:11PM -0800, Steve Kargl wrote:
>> On Wed, Dec 07, 2016 at 07:55:01PM
: cannot read LTO decls from
> /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o
>
> This may be darwin specific as the linker is more picky than the linux one.
>
> Dominique
>
>> Le 7 déc. 2016 à 16:47, Paul Richard Thomas
>> a écrit :
>>
>
Dear Dominique,
I will turn to the effect on PR77414 after committing the patch for PR44265.
The attached fixes the -flto problem. The chunk in
trans-decl.c(gfc_finish_var_decl) did the job. It is quite obvious now
and, in fact, I am a bit surprised that the patch worked at all
without the DECL_E
Hi Jerry,
OK for trunk - thanks.
Paul
On 6 December 2016 at 03:24, Jerry DeLisle wrote:
> The attached patch removes one error message and updates several test cases.
>
> I split alloc_comp_constraint_1.f90 into two cases with the addition of
> alloc_comp_constraint_7.f90. One gets different er
Dear All,
It took me an excessively long time to realise that processing the
typespec for an explicitly typed module procedure was wiping out the
interface symbol and so preventing the comparison of characteristics
between the interface and the separate module procedure. Transferring
the module in
Dear Andre,
This all looks OK to me. The only comment that I have that you might
deal with before committing is that some of the Boolean expressions,
eg:
+ int caf_dereg_mode
+ = ((caf_mode & GFC_STRUCTURE_CAF_MODE_IN_COARRAY) != 0
+ || c->attr.codimension)
+ ?
Kargl
wrote:
> On Sun, Nov 27, 2016 at 06:42:12PM +0100, Paul Richard Thomas wrote:
>>
>> This is a rather trivial problem with a similarly trivial fix. The
>> ChangeLog says it all.
>>
>> Before anybody asks, the testcase number jumps by two because I am
>> goin
Dear All,
This is a rather trivial problem with a similarly trivial fix. The
ChangeLog says it all.
Before anybody asks, the testcase number jumps by two because I am
going through the submodule PRs in reverse order.
Bootstraps and regtests on FC21/x86_64 - OK for trunk and 6-branch?
Paul
2016
Dear Janus,
This looks fine to me - OK for trunk.
Best regards and thanks
Paul
On 25 November 2016 at 13:40, Janus Weil wrote:
> Hi all,
>
> here is a patch that fixes a rejects-valid problem with an
> unlimited-polymorphic variable in a generic procedure. Removing the
> line with UNLIMITED_PO
Dear All,
Since both Andre and I have taken a good look at this rather small
patch, I decided to commit it as revision 242875.
My movements are such that I will have to hold off on 5- and
6-branches until the week after next.
Best regards
Paul
PS Andre, I wasn't trying to make you feel bad but
Dear All,
Andre put me to shame with a devastatingly simple replacement for a
horribly complicated and wrong patch that I was getting into.
The part of the patch in trans-expr.c fixes the PR and the part in
trans-stmt.c fixes a memory leak in function 'tt'. This latter fixes
half of the memory le
Hi Dominique.
snip
> I have a last glitch (which can be deferred if needed):
snip
Fixed by the new patch, which is attached. Bootstraps and regtests OK.
OK for trunk?
Paul
2016-11-10 Paul Thomas
PR fortran/44265
* gfortran.h : Add fn_result_spec bitfield to gfc_symb
Dear All,
The title of this PR says what this is all about, except that it
applies uniquely applicable to character function result string
lengths.
Ian Harvey wrote the first patch for this PR for which many thanks.
However, two issues came up that took some little while to understand;
(i) In com
Hi Steve,
Committed as r241995. Thanks.
Paul
On 8 November 2016 at 20:43, Steve Kargl
wrote:
> Yes. I saw Ian's analysis in c.l.f. It seems we both got
> caught out on this one. The patch looks fine.
>
> --
> steve
>
> On Tue, Nov 08, 2016 at 08:26:37PM +0100,
Hi Steve,
I moved too quickly and caused a regression. See the link in the
testcase. The attached fixes the problem and bootstraps/regtests.
OK for trunk?
Paul
On 5 November 2016 at 16:17, Steve Kargl
wrote:
> On Sat, Nov 05, 2016 at 10:05:30AM +0100, Paul Richard Thomas wr
Richard Thomas
wrote:
> Hi Andre,
>
> It was the comment for the function that you eliminated. I'll get rid
> of the comment. I was in a bit of a hurry and did indeed only look
> where you suggested. Sorry about that.
>
> Thanks
>
> Paul
>
> On 24 October 2016 at
Dear Andre,
The patch looks fine to me. OK for trunk.
Cheers
Paul
On 4 November 2016 at 01:57, Steve Kargl
wrote:
> On Thu, Nov 03, 2016 at 02:16:48PM +0100, Andre Vehreschild wrote:
>>
>> Bootstraps and regtests fine on x86_64-linux/F23. Ok for trunk?
>>
>> @Dominique: Would you give it a go
Hi Janus,
Welcome back!
The patch is OK for trunk.
Best regards
Paul
PS While you are with us, are you intending to deal with the 14 PRs
for which you are the assignee or will you unassign yourself?
On 5 November 2016 at 10:15, Janus Weil wrote:
> Hi all,
>
> here is a patch that I had submi
Dear All,
This patch introduces an error if the to and from arguments of
move_alloc contain the same object or its subobjects. Please see the
comment in the testcase for an explanation and the link to the clf
discussion.
Bootstraps and regtests on FC21/x86_64 - OK for trunk?
Paul
2016-11-05 Pa
Committed as 'obvious' in revision 241869.
This fixes the problem in comment #9. Andre seems to have fixed
comment #10 and so I am closing the PR.
Paul
2016-11-05 Paul Thomas
PR fortran/67564
* trans-expr.c (gfc_conv_class_to_class): Return _len component
of unlimited polymorphic
Committed as revision 241860.
Thanks for the review.
Paul
On 4 November 2016 at 19:21, Steve Kargl
wrote:
> On Fri, Nov 04, 2016 at 12:43:37PM +0100, Paul Richard Thomas wrote:
>>
>> The associate construct does not readily permit the identification of
>> the associate na
Hi Steve,
Thanks. At least it cannot do any harm :-)
I will get on with it.
Paul
On 4 November 2016 at 19:21, Steve Kargl
wrote:
> On Fri, Nov 04, 2016 at 12:43:37PM +0100, Paul Richard Thomas wrote:
>>
>> The associate construct does not readily permit the identification of
&
Dear All,
The associate construct does not readily permit the identification of
the associate name as an array during parsing. However, this can be
done whilst matching rvalues within the associate block. This patch
extends this identification in gfc_match_varspec, whilst excluding
character types
Dear All,
The comment in the patch more than adequately describes how this patch
works. The first testcase checks that correctly functioning code is
produced, when the spurious error is suppressed, and the second checks
that genuine errors are caught.
Bootstraps and regtests on FC21/x86_64 - OK f
> *** gcc/fortran/trans-types.c (revision 241467)
> --- gcc/fortran/trans-types.c (working copy)
> *** gfc_get_derived_type (gfc_symbol * deriv
>
> which would eliminate evaluating the same checks thric
Hi Andre,
This patch is fine, apart from
s/whose length is no consistently/whose length is not consistently/
in the comment.
The testcase in comment #1 of PR78053 is invalid and now give the
correct message:
type is (character(len=:))
1
Error: The type-spec at (1) shall specify
Dear All,
Please find attached the patch for allocatable components of recursive
type. The patch is pretty straightforward in that for the main part
they are treated exactly as their pointer equivalents. The exception
to this is the automatic deallocation of allocatable components. I
tried to use
Hi Andre,
It was the comment for the function that you eliminated. I'll get rid
of the comment. I was in a bit of a hurry and did indeed only look
where you suggested. Sorry about that.
Thanks
Paul
On 24 October 2016 at 11:07, Andre Vehreschild wrote:
> Hi Paul,
>
> concerning this:
>
>> >> In
Hi Andre,
Thanks for the review. I have partially responded to your comments - see below.
Committed as revision 241450.
Cheers
Paul
On 23 October 2016 at 14:45, Andre Vehreschild wrote:
> Hi Paul,
>
> here are my comments to your patch:
>
>> Index: gcc/fortran/class.c
>>
Dear Andre,
For the bulk of the patch, I have no comments. However, for the
testcase alloc_comp_class_5.f03, please eliminate the commented out
lines and the TODO, as discussed on #gfortran. Add them to the
testcase for for PR78053, as we agreed.
In realloc_on_assign_27.f08, you have the followin
Hi Dominique,
Thanks for the heads up!
I was going to review Andre's patch this morning, so I will clean my
tree, apply it, confirm that it is regression free and then will
generate a compatible version of my patch for PR69834. I strongly
suspect that the core of the patch is OK and that it is th
Hi Steve,
Thanks for persevering with this. The patch looks good to me. If it
has regtested OK, please feel free to commit.
Cheers
Paul
On 22 October 2016 at 02:22, Steve Kargl
wrote:
> All,
>
> The attached patch fixes PR fortran/78033. This was a REAL pain
> to fix because Fortran overloads
HO
>> the copy in line 49 could be sufficient.
>>
>> I look into it tomorrow more thoroughly. Please wait before submitting a new
>> version. May be I see something more :-)
>>
>> So far, thanks for working on this.
>>
>> Regards,
>> Andre
&g
Dear All,
I had the attached patch more or less working at the end of January.
However, there was a regression with submodule_6.f03, which I had
quite a struggle with and only resolved yesterday.
Until now, select type used the hash value to do the type selection
with the inevitable consequence t
Dear Andre,
Following our exchange yesterday, I have eliminated the modification
to trans_associate_var and have corrected the offending expressions in
resolve.c(fixup_array_ref).
Please find attached the corrected patch.
Cheers
Paul
2016-10-19 Paul Thomas
PR fortran/69566
* resolv
Hi Andre,
Thanks for a quick response:
> You can use
>
>|| (e->symtree && UNLIMITED_POLY (e->symtree->n.sym));
Ah yes, you are quite right.
> here. UNLIMITED_POLY does all the checks. I am still wondering whether this is
> necessary? The symtree is set for expr_type == { EXPR_VARIABLE, EXPR
Dear All,
This bug was caused by 'associate name' and 'associate entity'
expressions being incomplete when the 'selector' was an intrinsic
function result. I tried to fix this at source, in match_select _type
and gfc_get_variable_expr, but caused a vast number of breakages.
Undoubtedly, this would
Dear All,
Committed as 'obvious' on trunk as revision 241274.
I will commit to 5- and 6-branches at the end of the week.
Cheers
Paul
2016-10-17 Paul Thomas
PR fortran/61420
PR fortran/78013
* resolve.c (resolve_variable): Obtain the typespec for a
variable expression, when
Hi Andre,
It looks fine to me - OK for trunk.
Thanks for the patch
Paul
On 1 October 2016 at 13:30, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes some issue in caf/single.c that were reported as pure
> style issues, but uncovered at least one significant error when handling
> se
Dear Andre,
Looks good to me - OK for trunk.
Thanks
Paul
On 29 September 2016 at 14:03, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes an addressing issue for coarrays *in* derived types.
> Before the patch the caf runtime reference chain was generated from the start
> of the symb
inter version work in all circumstances with submodules.
Best regards
Paul
On 27 September 2016 at 10:27, Paul Richard Thomas
wrote:
> Dear All,
>
> The first attempts at fixing this bug were posted to the PR in
> February of this year. Since then, real life has intervened and I have
&
Dear All,
The first attempts at fixing this bug were posted to the PR in
February of this year. Since then, real life has intervened and I have
not been able to get back to it until now.
The first patch used the address of the vtable to perform the
switching in SELECT_TYPE. Unfortunately, it fail
FL_DERIVED.
On 26 September 2016 at 10:26, Paul Richard Thomas
wrote:
> Dear Rainer,
>
> Thanks to you and Dominique for the confirmation that the patch works. I
> will commit it sometime today.
>
> Regards
>
> Paul
>
>
> On 26 Sep 2016 10:23 a.m., &q
Dear Rainer,
Thanks for the report. I'll have a stab at finding the problem
tomorrow. In the interim, could you try applying:
Index: /svn/trunk/gcc/fortran/interface.c
===
*** /svn/trunk/gcc/fortran/interface.c(revision 240349)
-
601 - 700 of 1217 matches
Mail list logo
