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,
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
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,
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
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,
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
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,
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 "
>> !
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 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,
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
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 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
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 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
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,
This is certainly OK for 4.8.
I have a couple of remarks:
(i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
since! At the moment it does not cause any problems because of the
extremely limited use of the dtype 'type'. Whilst the array
descriptor revamp will elimin
OK for trunk with RM agreement. Obviously, 4.5 & 4.6 are OK too.
Thanks
Paul
On Fri, Mar 2, 2012 at 10:35 AM, Tobias Burnus wrote:
> There is a 4.5 to 4.7 regression for those (vendor) intrinsic procedures,
> which can exists as both subroutine and as function. Example:
>
> INTRINSIC :: eti
Regression fix okayed by Tobias Burnus on #gfortran and committed as
revision 184651.
Cheers
Paul
2012-02-29 Paul Thomas
PR fortran/52386
* trans-expr.c (fcncall_realloc_result): Dereference the
descriptor if needed.
2012-02-29 Paul Thomas
PR fortran/52386
* gfortran
Dear Tobias,
I saw Nasser's posting and the subsequent correspondence on clf.
That's a pretty fast response!
I think that this is OK for trunk, since it is only a change of
standard for this error.
Cheers
Paul
On Sat, Feb 18, 2012 at 12:58 PM, Tobias Burnus wrote:
> Build and regtested on x86
Mikael,
This is OK for trunk with one proviso; could you move
is_class_container_ref to gfc_is_class_container_ref in class.c?
Thanks for the patch
Paul
On Sun, Feb 12, 2012 at 10:11 PM, Mikael Morin wrote:
> Hello,
>
> this is the next PR50981 fix:
> when passing polymorphic scalar actual arg
Dear Tobias,
On Mon, Feb 6, 2012 at 11:27 PM, Tobias Burnus wrote:
> When passing a CLASS to a TYPE, the "_data" component wasn't added for
> scalar variables. (Polymorphic arrays are/were handled correctly.)
>
> This patch adds the _data, fixing this wrong-code issue.
>
> Build and regtested on
Dear All,
The attached is obvious fix to this regression and I will commit
tomorrow evening if there is no objection.
Cheers
Paul
2012-02-06 Paul Thomas
* resolve.c (resolve_fl_derived0): Typebound functions support
assumed character length results.
2012-02-06 Paul Thomas
Committed as revision 183915 after green light from Tobias on #gfortran.
2012-02-05 Paul Thomas
* trans-array.c (gfc_array_allocate): Zero memory for all class
array allocations.
* trans-stmt.c (gfc_trans_allocate): Ditto for class scalars.
PR fortran/52102
Dear Tobias,
Following our exchanges with Dominique, I think that the attached
patch will have to do for now.
Bootstrapped and regtested on FC9/x86_64 - OK for trunk?
Cheers
Paul
2012-02-02 Paul Thomas
PR fortran/52012
* trans-expr.c (fcncall_realloc_result): If variable sh
Dear Mikael,
This...
> I have chosen to make it a separate function instead of fixing
> gfc_add_component_ref, so that it can be reused later (maybe...) even if we
> don't want to add a "_data", or "_vptr" or ... component.
...is exactly what I had a mind to do, once clear of regression
fixing.
Dear Tobias,
> integer, allocatable :: a(:), b(:)
> allocate(b(3))
> b = [1,2,3]
>
> allocate (a(7:9))
> a = reshape( b, shape=[size(b)])
> print *, lbound(a), ubound(a) ! Expected: 7 9
> end
I tried briefly to generate such a case... I'll fix it.
Cheers
Paul
Dear Tobias,
OK for trunk on both.
Thanks
Paul
On Mon, Jan 30, 2012 at 9:54 PM, Tobias Burnus wrote:
> First, I am looking for someone to review my patch at
> http://gcc.gnu.org/ml/fortran/2012-01/msg00241.html
>
> This patch contains two patches:
>
> a) Marking the polymorphic _copy function
Hi Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk?
That looks like a neat way to solve the problem. OK for trunk.
Thanks for the patch.
Paul
2012-01-31 Paul Thomas
PR fortran/52012
* trans-expr.c (fcncall_realloc_result): Correct calculation of
result offset.
2012-01-31 Paul Thomas
PR fortran/52012
* gfortran.dg/realloc_on_assign_10.f90: New test.
Committed as revision 183757.
>From 7.4
Dear Tobias,
As I said just a moment ago - I was hoping somebody else would get
involved. I looked at this earlier today and it is OK for trunk.
Thanks for the patch.
Cheers
Paul
On Sat, Jan 28, 2012 at 3:09 PM, Dominique Dhumieres wrote:
> Dear Tobias,
>
> I have this patch in my working tr
Dear Tobias,
> Well, that way my revenge for not getting a review for my
> default-initializer patch since over a week ... ;-)
To be perfectly frank, I was hoping that somebody else would get their
ass in gear :-)
I'll do it.
Paul
Dear Tobias,
I cry foul at this point :-) I have gone gallivanting off to try to
fix really horrid regressions like 52012, whilst you are have fun
doing interesting things.
Pah! Good call - OK for trunk
Thanks for the patch.
I notice that you are making good use of recent additions to
tra
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
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?
>
>
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
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,
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 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,
>
> 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 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,
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 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 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 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,
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,
> Build and regtested on x86-64-linux.
> OK for the trunk? (And [together with (a)] for the 4.6 branch?)
OK - thanks!
Paul
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,
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 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,
> Build and regtested on x86-64-linux.
> OK for the trunk?
That's OK for trunk - thanks!
Paul
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
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 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
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,
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,
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 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 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 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 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
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'
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 (
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
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 Tobias,
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
OK
Thanks for the remarkably rapid turnround!
Paul
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,
>
> 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 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
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 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
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,
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,
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,
> 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,
>
> 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,
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,
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 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
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 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
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 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 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
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 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
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 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 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 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
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 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 Tobias,
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
OK for trunk. The machinery is well used for other purposes and I do
not see any problem with your implementation.
We are making increasing use of scan-tree-dump-times in the tests. I
wonder if this is well advised? I ha
Dear Jakub,
Yes! OK for trunk and, if you will, for 4.6.
Thanks
Paul
On Mon, Jul 4, 2011 at 7:22 PM, Jakub Jelinek wrote:
> Hi!
>
> If -L doesn't have an argument, find_spec_file ICEs on it, as
> the argument is NULL. As suggested by Joseph, this disregards in
> this loop all options which d
OK for trunk and 4.6.
Thanks for the patch
Paul
On Tue, Jun 28, 2011 at 5:40 PM, Janus Weil wrote:
> Hi all,
>
> here is a patch for a problem which was originally reported as an
> ICE-on-invalid regression (assigning to a type-bound function).
>
> In the course of fixing it, I noticed that it
Dear Richi,
The point of entry for assignments is in trans-expr.c
06038 tree
06039 gfc_trans_assignment (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
06040 bool dealloc)
06041 {
a bunch of special cases
06088
06089 /* Fallback to the scalarizer to generate
Dear Tobias,
I have checked out the code for any obvious style or other minor
errors and all looks well. However, I had a look at 8.5.6 "LOCK and
UNLOCK statements" in the standard and can only confess to feeling
very stupid tonight because I could not make head nor tail of the
example. Thus, I
> However, I forgot the [*] (or [3,*] or ...). Fortunately, you
> have spotted the sematically relevant typo!
>
;-)
Paul
Dear Tobias,
This looks fine to me. It does the things that you described and is
well hidden behind the co-array associated conditions. Thus it is OK
for trunk.
Maybe I am being stupid but what is the call, in the testcase, to
subroutine test for?
Cheers
Paul
Dear All,
>
> I have posted a simpler alternative on the PR that uses your
> suggestion that forward and backward dependences need to to be
> recorded to get this right.
>
> I believe that it's OK but have only now had the opportunity to put it
> on to regtest.
>
Following some comments from Thoma
1101 - 1200 of 1217 matches
Mail list logo
