Dear Janus,
As you say, this is close to being obvious - OK for trunk and for 4.7.
Thanks for the patch.
Cheers
Paul
On 16 January 2013 15:08, Janus Weil wrote:
> Hi all,
>
> here is a close-to-obvious patch for an ICE-on-invalid regression. It
> removes as assert, which is reasonable for val
Thanks, Janus.
Committed as revision 195492.
Cheers
Paul
On 27 January 2013 00:15, Janus Weil wrote:
> Hi Paul,
>
>> This patch builds on Janus's suggestion in the PR. The ChangeLog
>> explains it all.
>>
>> Bootstrapped and regtested on x86_64/FC17 - OK for trunk?
>
> looks good to me. Thank
Dear Mikael,
This looks good to me. The two week delay to back-porting is a good idea.
Thanks for the patch
Paul
On 10 January 2013 15:57, Mikael Morin wrote:
> Hello,
>
> for the case:
> [...]
>use select_precision, only: wp => dp
>interface
>subroutine ode_deriva
**ping**
On 23 January 2013 11:06, Tobias Burnus wrote:
> Paul Richard Thomas wrote:
>>
>> *** gfc_alloc_allocatable_for_assignment (gf
>> *** 8224,8229
>> --- 8250,8262
>> desc, tmp);
>>
Dear Tobias,
For a variety of reasons, I did not open my mailbox this morning but
got down to developing an almost identical fix and taking the PR!
Anyway, it would be best that you commit your fix, so it's OK for trunk.
Thanks
Paul
On 29 January 2013 23:36, Tobias Burnus wrote:
> For allocat
Dear Thomas,
I wrote this almost immediately after you posted the patch, got
disturbed and forgot about it - my apologies. Note Dominique's reply
after you corrected the PR number.
OK for trunk. The part in decl.c is exactly what I was thinking to do.
Thanks for the patch
Paul
Committed revision 195741.
Thanks for the review.
Paul
On 28 January 2013 22:18, Thomas Koenig wrote:
> Hi Paul,
>
>
>> This patch is sufficiently straightforward that the ChangeLog entry
>> describes it completely. The fix for both bugs lay in the
>> nullification of the allocatable component
Mikael,
The patch itself is good for trunk - it's rather clever, in fact :-)
What's happened to the testcase? There are still lots of commented
out lines that I presume are fixed.
Cheers
Paul
On 7 February 2013 23:28, Mikael Morin wrote:
> Hello,
>
> this is the last remaining patch to fix a
Dear All,
Committed as obvious revision 195915. The patch is a generalisation
of Tobias' fix.
2013-02-09 Paul Thomas
PR fortran/55362
* check.c (array_check): It is an error if a procedure is
passed.
2013-02-09 Paul Thomas
PR fortran/55362
* gfortran.dg/intrinsic_siz
It looks OK to me - is Jakub OK with it?
Cheers
Paul
On 8 February 2013 21:48, Thomas Koenig wrote:
> Hello world,
>
> the attached patch fixes the PR by (re-)adding a search path
> for the path used by intrinsic modules.
>
> Regression-tested. OK for trunk?
>
> Thomas
>
> 2013-02-08
Dear Tobias,
I think that this is sufficiently "obvious" that you could have taken
silence to be approval :-)
Of course it's OK for trunk.
Cheers
Paul
On Fri, Oct 14, 2011 at 11:15 PM, Tobias Burnus wrote:
> *ping*
>
> http://gcc.gnu.org/ml/fortran/2011-10/msg00073.html
>
> On 12.10.2011 15:5
Dear Janus,
This is OK for trunk. Thanks fo rthe patch.
Cheers
Paul
On Sun, Oct 16, 2011 at 2:58 PM, Janus Weil wrote:
> Hi all,
>
> here is a patch which fixes the regression in comment #2 of the PR in
> the subject line. What it does is setting the 'ts.is_c_interop' flag
> correctly for con
Dear Janus,
Of course you can commit to 4.6. Be quick, though; 4.6.2 was due for
release now-ish -
"GCC 4.6 branch remains open under normal release branch rules,
accepting regression and documentation fixes. GCC 4.6.2 is
tentatively planned for late September or early October."
Thanks
Paul
O
Dear Steve,
Reaping implies that there is something about it that you want to keep
:-) Surely, weeding or herbicide spraying is better than reaping?
On Wed, Oct 26, 2011 at 7:53 PM, Steve Kargl
wrote:
> On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl wrote:
>> The attach patch reaps some
Steve,
> Surely, you have Halloween across the Pond, ie., the Grim Reaper. :-)
And what, pray, does the Grim Reaper hold???
The patch is OK.
Thanks
Paul
>
>>
>> On Wed, Oct 26, 2011 at 7:53 PM, Steve Kargl
>> wrote:
>> > On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl wrote:
>> >> The
Dear Mikael,
I intend to work my way through your patches, starting this evening.
I'll give you feedback as I go along and will OK the whole package,
rather than bits. Is that alright with you?
Cheers
Paul
On Fri, Oct 28, 2011 at 1:29 AM, Mikael Morin wrote:
>
--
The knack of flying is le
Dear Mikael,
> PS: I hereby confess my failure to not split the patch too much. :-(
I hereby confess my failure to find anything to which I could gripe,
let alone object!
The patch can only be described as a tour de force. Not only is there
a lot of it - 6160 lines with context on - but it is
Dear Janus,
On Mon, Nov 7, 2011 at 12:14 AM, Janus Weil wrote:
> The patch actually consists of two parts:
> 1) The resolve.c part prevents the conversion to a PPC call via the
> _vptr (for functions and subroutines).
This is obviously OK
> 2) The class.c parts prevents adding the non-overrida
Dear Tobias,
Please stop sending us the patch! I received it right from the first
mailing
Cheers
Paul
On Sun, Nov 6, 2011 at 5:51 PM, Tobias Burnus wrote:
> Last try: Also gzip the release notes - let's see whether it mailserver
> accepts that email.
>
> Tobias
>
>> PS: I really hate that
Hi Janus,
As part of Tobias's fix for PR50640, he introduced:
+ if ((sym->attr.flavor == FL_PARAMETER
+ && (sym->attr.dimension || sym->ts.type == BT_DERIVED))
+ || sym->attr.vtab)
TREE_READONLY (decl) = 1;
Is this not sufficient to fix this PR too?
Otherwise, your patch is, of
Dear Janus,
I am asking the question :-) Are the two equivalent? To my mind, it
is a matter of taste, if they are.
Cheers
Paul
On Tue, Nov 8, 2011 at 9:02 PM, Janus Weil wrote:
> Hi Paul,
>
>> As part of Tobias's fix for PR50640, he introduced:
>>
>> + if ((sym->attr.flavor == FL_PARAMETER
Dear All,
Please find attached a patch and testcase for the above PR. The
comment before generate_component_assignments explains the need for
the patch, which itself is fairly self explanatory.
Bootstrapped and regtested on Fc9/x86_64 - OK for trunk?
Best regards
Paul and Alessandro.
2012-08-
Dear Mikael,
> I think there are a couple of bugs not triggered by the single component
> types in the test. See below.
Yes, you are right. We should have tested multiple components... my fault!
> This could be moved to the only next caller (`previous' doesn't need to
> be updated if `this_code
fortran.dg/defined_assignment_3.f90: New test.
On 14/08/2012, Paul Richard Thomas wrote:
> Mikael,
>
> On 14 August 2012 10:42, Mikael Morin wrote:
>> On 14/08/2012 07:03, Paul Richard Thomas wrote:
>>>> However, if we do it before, we also overwrite components to be
>>>&
Dear Tobias,
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
I am not convinced that the gcc_asserts are need in encode_derived but
I guess they do no harm.
OK for trunk.
Thanks for the patch.
Paul
Dear Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk?
OK for trunk - thanks for the patch.
Cheers
Paul
Dear Tobias,
> The following test case doesn't work; it should print "Overloaded" - and
> does so with crayftn. But with your patch, it doesn't.
For some reason, I guess, the attribute defined_assign_comp is not
getting passed along to type 'b'.
> + build_assignment (gfc_exec_op op, gfc_expr *ex
Dear Mikael,
Thanks for the usually thorough review.
snip
> And here comes the next round of comments.
snip
>> + e->rank = c && c->as ? c->as->rank : 0;
> This is bogus if e->rank was != 0 previously (think of the case
> array(:)%scalar_comp).
mistaken maybe but not bogus!
>
Dear Tobias,
Good catch on the non-polymorphic 'TO'!
>> Updated version (cf. below). Build and regtested on x86-64-linux.
>> OK for the trunk?
Indeed - OK for trunk.
>>
>> I asked at J3 and John Reid kindly pointed me to the pending
>> interpretation request F08/0040 at
>> http://j3-fortran.or
Dear Tobias,
>> OK for the trunk?
Yes indeed - thanks for the patch.
Cheers
Paul
Dear Tobias,
> OK for the trunk?
Yes, particularly with the development relative to the draft patch in the PR.
OK for trunk.
Thanks
Paul
Hi Tobias,
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
Yes, of course it's OK for trunk. It verges on obvious!
Thanks
Paul
Dear Uros,
It looks good an clear to me!
Thanks for the patch and, in particular, for adding the cleanup line.
Paul
On 27 July 2012 13:53, Uros Bizjak wrote:
> Hello!
>
> Without -mno-explicit-relocs, alpha generates:
>
> ldq $27,myBindC($29)!literal!6
> jsr $26,($2
Dear Mikael,
This looks to be "obvious" and is certainly OK for trunk.
Thanks for the patch.
Paul
On 3 August 2012 16:18, Mikael Morin wrote:
> Hello,
>
> here is the fix for the regression I have introduced with my assumed
> rank bounds patch.
>
> Will test and commit as obvious.
> Mikael
>
>
18, 2012 at 11:16 PM, Tobias Burnus wrote:
> Dear Paul,
>
> thanks for the patch.
>
> Paul Richard Thomas wrote:
>>
>> + /* Transfer the selector typespec to the associate name. */
>> +
>> + copy_ts_from_selector_to_associate (gfc_expr *expr1, gfc_expr *expr2
Dear Tobias,
Thanks for completing the review. I should be able to commit tonight.
> Thanks for the patch. I think it is OK.
>
> Regarding:
>
>> ! if (ref&& ref->type != REF_ARRAY&& seen_array)
>> ! {
>> ! gfc_error ("CLASS selector at %L is an array with CLASS "
>> !
Dear Tobias,
The patch is OK for 4.7 and trunk - thanks.
The commit of the PR41600 is delayed until tomorrow or Sunday because
of PR53191. I have regtested a fix for it and, since it is 'obvious'
I will commit it with the main patch. In fact, it extends the
constraint C614 (see resolve_ref) to
Dear Tobias,
This is OK for trunk.
Thanks for the patch.
Paul
On 3 May 2012 20:41, Tobias Burnus wrote:
> A PRIVATE module variable, which is used in the specification expression of
> a function result variable cannot be TREE_PUBLIC()=0, unless the function
> itself is PRIVATE and also not acc
Hi Tobias,
Nice call! Apart from s/wronly/wrongly/ in the testcase, this is
certainly OK for trunk and, I would suggest, as far back as you have
the intestinal fortitude to go. I suspect, without checking, that the
patch might not do the right thing on 4.5.
Thanks for the patch for what you carr
Dear Tobias,
OK for trunk - just a wee typo to correct:
s/+ parameter available to the caller; gfortran save it in the
.mod files. */
/+ parameter available to the caller; gfortran saves it in the
.mod files. *//
Thanks for the patch.
Paul
On 13 May 2012 15:50, Tobias Burnus wrote:
> T
Dear Tobias,
OK for trunk. As you say, the testcase does no harm and so should be retained.
Thanks for the patch.
Cheers
Paul
On 21 May 2012 19:51, Tobias Burnus wrote:
> First: I have another rather simple patch, which still needs to be reviewed:
> http://gcc.gnu.org/ml/fortran/2012-05/msg0
Dear Tobias,
That's OK for trunk.
Thanks
Paul
On 30 May 2012 11:09, Tobias Burnus wrote:
> This patch rejects actual arguments to MOVE_ALLOC which are coindexed or
> have a corank.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
--
The knack of flying is learning ho
Hi Alessandro,
I am glad to see that Janus is giving you a helping hand, in addition
to Tobias. I am so tied up with every aspect of life that gfortran is
not figuring much at all.
When you clean up the patch, you might consider making this into a
separate function:
+ if (free_proc)
+
Dear Tobias,
This one is indeed obvious! OK for trunk.
Cheers
Paul
On 13 June 2012 09:50, Tobias Burnus wrote:
> Given the very slow patch review, I intent to commit this patch in a couple
> of days as obvious.* Nevertheless, I wouldn't mind a patch review.
>
> The constraint check is actuall
Dear Tobias,
I had earmarked this one to fix myself! It's good for trunk.
Thanks
Paul
On 13 June 2012 09:54, Tobias Burnus wrote:
> gfortran had an ICE with intent(out) class arrays - and with (polymorphic)
> scalar coarrays.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> To
Dear Jakub,
This is, of course, OK for trunk. In fact, I would say that it verges
on obvious.
Thanks for taking care of it.
Paul
On Fri, Sep 23, 2011 at 4:44 PM, Jakub Jelinek wrote:
> Hi!
>
> I've noticed with the
> 2009-05-29 Eric Botcazou
>
> * tree-ssa-loop-ivopts.c (strip_offse
Dear All,
As the testcase shows, pointer array functions can return strides that
are different to their initial values before the function call. This
fix makes use of the descriptor strides since they are returned
durectly.
Bootstrapped and regtested of x86_64/FC9 - OK for trunk?
Cheers
Paul
Dear Steve,
Thanks - I just noticed that the { dg-do run } is missing a space. It
seemed to run correctly during regtesting but I will set it right
anyway.
Cheers
Paul
On Fri, Oct 7, 2011 at 1:29 AM, Steve Kargl
wrote:
> On Thu, Oct 06, 2011 at 10:22:12PM +0200, Paul Richard Thomas wr
Tobias,
These patches are OK for trunk and fortran-dev.
Many thanks
Paul
On Sat, Mar 10, 2012 at 4:53 PM, Tobias Burnus wrote:
> The attached patch renames (in libgfortran/) the array descriptor's "data"
> field to "base_addr" and "lbound" to "lower_bound".
>
> The reason is that Technical Spe
Dear Tobias,
Apart from s/Contribute/Contributed/ this is OK for trunk. In fact, I
would say that it is "obvious".
Thanks for the patch.
Paul
On Sat, Mar 10, 2012 at 4:53 PM, Tobias Burnus wrote:
> Tobias Burnus wrote:
>>
>> If the interface in a PROCEDURE() statement is Bind(C), also the pro
Dear Tobias,
> At some point, the extent calculation should be updated. Dumps like the
> following hurt, even if -O1 handles* them:
> (((D.1871->dim[0].lower_bound + D.1871->dim[0].extent) + -1) -
> D.1871->dim[0].lower_bound) + 1.
> [* maybe -fstrict-overflow and/or -fno-protect-parens is requir
Dear All,
Please find attached a fix for PR41600 plus some. It is reasonably
straightforward but the following should be noted:
(i) gfc_get_vptr_from_expr exploits that seeming fact that tracing
back any class expression through TREE_OPERAND 0 eventually gets one
back to the class expression. I
Committed as trivial/obvious in revision 185924. Thanks to Brian Ames
for spotting the error!
2012-03-28 Paul Thomas
Tobias Burnus
PR fortran/52652
* match.c (gfc_match_allocate, gfc_match_deallocate): Change
"not.. or" to "neither.. nor".
* parse.c (
Dear Tobias,
This is OK for trunk - thanks for the patch.
Cheers
Paul
On Tue, Apr 3, 2012 at 11:18 PM, Tobias Burnus wrote:
> Dear all,
>
> the attached patch only sets TREE_PUBLIC for module variables and module
> procedures which have neither the PRIVATE attribute nor a C-binding label.
> Se
Dear Thomas,
> after some time with a defective computer, I am back online.
It seems to be catching both my linux laptop and my desktop are as
dead as door-nails.
>
> Here is a fix for PR 52893 (which I just submitted, I wanted to
> set a new record between bug posting and patch submissin :
Dear Tobias,
I'll take a look this afternoon.
Cheers
Paul
On Mon, Nov 14, 2011 at 10:45 AM, Tobias Burnus wrote:
> I would like to *ping*.
>
> Additionally, I attached an updated patch as the tree-walking patch is now
> in. The updated patch is also available at
> https://userpage.physik.fu-be
Dear Tobias,
Sorry that I took an extra day over this approval; I kept getting disturbed.
[Remark: The delected section in resolve_symbol with gfc_find_symbol(..&ds)
was originally added in r133488 for PR fortran/33295]
Hah! I plead guilty. I think that it must have been a necessary
workaround
Dear Tobias,
>
> The patch has been bootstrapped and regtested on x86-64-linux.
> OK for the trunk?
Absolutely OK! I though that you might even commit it as "obvious"
since you, Janus and I discussed it :-)
Cheers
Paul
Dear Tobias,
> Build and regtested on x86-64-linux (trunk and trunk + Paul's patch).
> OK?
Many thanks for the patch - it's OK for trunk.
Cheers
Paul
Dear Tobias,
On Fri, Dec 2, 2011 at 10:07 PM, Tobias Burnus wrote:
> This patches fixes my previous MOVE_ALLOC patch. The standard states for TO:
> "It shall be polymorphic if FROM is polymorphic."
>
> I somehow read this bijectively, but the it is actually allowed to have a
> nonpolymorphic FROM
Dear Tobias,
This is OK for both 4.6 and 4.7.
Many thanks, sir!
Paul
On Tue, Nov 29, 2011 at 7:32 PM, Tobias Burnus wrote:
> Dear all,
>
> gfortran 4.6 and 4.7 have a too tight check whether a variable can be
> modified if the actual argument is INTENT(IN). This patch relaxes/fixes the
> check
Dear Tobias,
Are you checking to see if the patches really are reviewed :-)
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (Revision 181967)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -188,7 +188,8 @@ gfc_build_class_symbol (g
Dear Tobias,
>> Build and regtested on x86-64-linux.
>> OK for the trunk? How far should this be backported - all the way down to
>> 4.4?
This is OK for trunk and... well, I don't know. 4.4 is likely a bit
too far. I guess that the linux distros are already at 4.5? I will
leave it to you.
Ch
coming in.
>
>
> Paul Richard Thomas wrote:
>>
>> Boostrapped and regtested on x86_64/FC9 - OK for trunk?
Committed as revision 182210 with comments and corrections taken on board.
Cheers
Paul
Dear All,
This patch combines the trivial correction of an error in
trans-decl.c, spotted by Jakub (thanks!), with a trivial fix for the
scalarization of elemental typebound procedures. Neither needs
explanation!
Boostrapped and regtested on x86_64/FC9 - OK for trunk?
Cheers
Paul
2011-12-14
Dear Tobias,
>
> OK for the trunk?
OK - thanks!
Paul
>
> Tobias
>
> On 12/13/2011 06:30 PM, Tobias Burnus wrote:
>>
>> Two small fixes:
>>
>> a) There was an ICE when simplifying "THIS_IMAGE(caf)" (for
>> -fcoarray=single); solution: Simply use internally lcobound(), which is
>> identically (fo
Dear Tobias,
>
> OK for the trunk?
>
OK.
>>
>> PS: There are still issues with polymophic coarrays; in particular,
>> argument passing [cf. coarray/poly_run_1.f90] and SELECT TYPE still fail in
>> various ways.
>
It is remarkable just how many ways [OOP] in any shape or form can
fail! Adding c
Dear Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
OK
Thanks for the remarkably rapid turnround!
Paul
Dear All,
I would put Mike Long up with the people that climb the likes of K2!
A remarkable achievement that is nearly but not quite completely
useless. I hope that teh view made up fo it
On the other hand, he helped us out :-)
Cheers
Paul
On Wed, Dec 21, 2011 at 5:14 PM, Tobias Burnus w
Dear All,
This patch represents a rather complete fix for this PR. In fact, I
suspect that it also fixes other PRs but I have been out of internet
range for a week and have not been able to check.
The processing of typebound operators has been made more straight
forward here by the addition of a
to one and all.
Paul
On Sat, Dec 31, 2011 at 12:14 AM, Tobias Burnus wrote:
> Dear Paul,
>
> Paul Richard Thomas wrote:
>>
>> Bootstrapped and regtested on i686/Ubuntu 11.1 - OK for trunk?
>>
>> 2011-12-30 Paul Thomas
>>
>> * trans-array.c (
Committed as r182796. Thanks for the review Tobias. (BTW - I
normally use -cp for my .diffs. I don't know what happened this time
:-) )
PR46262 is completely fixed. The "lorentz" example of Ralph Kube
needs the commented out allocate restoring at lorentz.f03:34.
Similalrly, Arjen's 'particles'
Dear All,
This is a straightforward patch that adds a last ditch attempt to find
a specific typebound procedure when all that has been found for a
derived type base object is 'deferred'. typebound_operator_7.f03 has
been extended to test derived type as well as class base objects.
Bootstrapped a
Dear Uros,
Thanks for that. It is not a problem that I encountered on either the
32 bit or 64 bit machines that I use but, as you say, an underflow is
the most likely explanation. I guess that without any loss, as far as
the test is concerned, a test that obj%c(i,j) is greater than 1e-5,
say, co
Dear Thomas,
Happy New Year!
> Wouldn't it be better to make a new test case? If there turns out
> to be a regression later, changing test cases makes it harder to
> find.
>
> You could just commit the test case 'as is' as typebound_operator_8.f03
> and leave the old one.
>
> Regards
>
>
Dear Tobias,
Please excuse the delay on coming back to you with this. Since the
power cut the other evening, I have been exceptionally busy.
> Build and regtested on x86-64-linux.
> OK for the trunk?
I have to confess that I do not like /* A better error message may be
possible, but not require
Dear All,
Having stated in the PR that I did not have time to fix it, after a
few hours in the workshop doing woodwork I alighted on the obvious and
simple solution :-)
A question for the standard aficianados: Are there other base object
expressions that are legal? Clearly this fix is extendable.
Dear All,
Committed as r183032.
Thanks
Paul
On Sun, Jan 8, 2012 at 10:32 PM, Tobias Burnus wrote:
> Dear Paul,
>
> Paul Richard Thomas:
>
>> A question for the standard aficianados: Are there other base object
>> expressions that are legal?
>
>
> I don'
Dear All,
Sorry for breaking the thread on this one.
The patch below is OK for trunk, minus the fragment in
'get_declared_from_expr' from one of my patches :-)
Cheers
Paul
---
Rather simple patch.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
Dear All,
When the only modification was to set the attribute alloc_comp for
class containers, I was going to commit this patch as obvious.
However, it caused a regression in class-19.f03 by increasing the
count of BUILTIN_FREE from 11 to 23! Whilst the extra calls did no
harm, this offended my s
Committed as revision 183162.
Thanks Tobias - I'll look at yours first thing tomorrow.
Paul
On Fri, Jan 13, 2012 at 4:50 PM, Tobias Burnus wrote:
> On 01/13/2012 04:29 PM, Paul Richard Thomas wrote:
>>
>> Bootstrapped and regtested on i686/Ubuntu10.04 - OK for trunk?
>
Dear Tobias,
> This patch fixes two issues related to intrinsic operators:
>
> a) No error for nonexisting operators:
>USE m, operator(*)
>
>
> b) An bogus error if one tried to use-associate the same operator multiple
> times:
> USE m, operator(+), operator(+)
>
> Those are old issues. New i
Dear Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk?
That's OK for trunk - thanks!
Paul
Dear All,
As previously advertised, the attached patch fixes the problem with
using an index array in the final assignment in subroutine qsort in
class_array_3.f03. The failure occurred because the temporary array
was assigned zero size, since the declared type is abstract. More
generally, even
Dear Tobias,
The following example that you provided:
> Do you mean something like the following:
>
> !
> type t
> integer :: i = 5
> end type t
> type, extends(t) :: t2
> integer :: j = 6
> end type t2
>
> class(t), allocatable :: a(:), b(:), c(:)
> allocate
Dear Tobias,
> Thus, I decided to backout the patch Rev. 181199 (cf. PR, comment 1) - and
> implement a simple TREE_READONLY in trans-decl.c.
I think that was a very sensible decision :-)
>
> Build and regtested on x86-64-linux.
> OK for the 4.7 trunk?
>
OK, thanks for the patch.
Paul
Dear Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk? (And [together with (a)] for the 4.6 branch?)
OK - thanks!
Paul
Dear All,
The attached is self-explanatory and fixes the last wrinkles with
PR51634. In addition, the patch incorporates the requirements of class
expressions being used throughout, as reflected in the second
testcase.
Bootstrapped and regtested on FC9/x86_64 - OK for trunk.
Cheers
Paul
2012-0
Dear Tobias and Janne,
I had preparedand was about to submit the identical patch :-)
On Tue, Jan 17, 2012 at 12:45 PM, Janne Blomqvist
wrote:
> On Tue, Jan 17, 2012 at 13:24, Tobias Burnus wrote:
>> This patch nullifies (scalar) allocatables after malloc, if (and only if)
>> they contain alloca
Dear All,
> thanks for the review - and for the f95-lang.c patch. I have updated the
> patch to use calloc, build & regtested it, and committed it as Rev. 183247.
Good - I will go back to array allocation and use calloc there as well.
Cheers
Paul
Dear Tobias,
Committed as r183287. Thanks for the review.
Paul
>> 2012-01-17 Paul Thomas
>>
>> PR fortran/51634
>> * trans-expr.c (gfc_conv_procedure_call): Deallocate allocatable
>> components of temporary class arguments.
>>
>> 2012-01-17 Paul Thomas
>>
>> PR for
Dear Tobias,
This patch is OK for trunk.
I have made a lot of progress on PR51870; class scalars work correctly
but I need to extend the fix to class arrays. It requires a complete
rewrite of the parts of gfc_trans_allocate that are associated with
class allocation and initialization. The resul
Dear All,
The attached is quite straightforward - for non-variable class STATUS
expressions, the class object is extracted, together with the element
size for the dynamic type. These are then used for the allocation and
the copy of the source data into the allocated object.
Note that I have begg
Dear Tobias,
>
> I believe that you mean source-expr (i.e. SOURCE= and MOLD=) and not STATUS.
It was late when I wrote the mail :-)
> I somehow liked your draft patch more:
It caused regressions, though!
>
> * The big program which I reduced to the test case in PR 51870 fails with
> the curr
Dear Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk and for the 4.6 branch?
>
OK for trunk
Thanks for the patch!
Paul
Dear Tobias,
On Wed, Jan 25, 2012 at 5:38 PM, Tobias Burnus wrote:
> Dear all,
>
> seemingly it can sometimes happen that "fclass" gets created but the
> fclass->f2k_derived is not set. This patch now sets it explicitly, if unset.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
OK f
Dear All,
After discussion off line with Tobias and a bit of tweaking, the patch
was committed as revision 183613.
2012-01-27 Paul Thomas
Tobias Burnus
PR fortran/48705
PR fortran/51870
PR fortran/51943
PR fortran/51946
* trans-array.c (gfc
Dear Tobias,
This is 'obvious', barring the issue that I mentioned about multiple
evaluation of expressions that are not variabbles. That said, I think
that this could and should be committed now.
OK for trunk.
Cheers
Paul
On Fri, Jan 27, 2012 at 7:57 AM, Tobias Burnus wrote:
> That's a Fo
OK for trunk.
Thanks for the patch
Paul
On Thu, Jan 26, 2012 at 9:28 PM, Tobias Burnus wrote:
> This patch fixes expressions involving polymorphic arrays and, thus,
> MOVE_ALLOC.
>
> I have also two minor fixes (cf. trans-decl.c).
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
>
This is 'obvious' - OK for trunk.
Thanks
Paul
On Fri, Jan 27, 2012 at 12:52 AM, Tobias Burnus wrote:
> Dominique found out that there is no diagnostic for polymorphic arrays. This
> patch adds it.
>
> From the F2008 standard:
>
> "C1289 All dummy arguments of an elemental procedure shall be sc
901 - 1000 of 1285 matches
Mail list logo
