Dear All,
This is a straightforward patch that is completely described in the
ChangeLog entry. I am surprised that this could be a 4.8 regression
since, as far as I am aware, SELECT_TYPE was not capable of handling
array selectors before... Nonetheless, it flagged it up for me :-)
Bootstrapped
Dear Janus, dear all,
Happy New Year!
The patch is OK for trunk.
Thanks a lot.
Paul
On 3 January 2014 10:29, Janus Weil ja...@gcc.gnu.org wrote:
In addition this patch fixes PR 59662.
Also: Ping!
Cheers,
Janus
2013/12/31 Janus Weil ja...@gcc.gnu.org:
Hi all,
... and the
Hi Janus,
This review bounced of gnu-central because it had mime content - back
to plain text!
I am somewhat startled that this was so easy to fix (ie. the patch
looks easy but I'll bet that find the fix was not!).
OK for trunk. I think that MOD_VERSION does need bumping but I would
bow to
Dear All,
This turned out to be a valid uninitialized variable warning.
However, it was unlikely ever to cause problems at run-time.
Nonetheless, here is the fix. I am disinclined to load the testsuite
with a fix that is so specific and localized that it simply will not
break. However, if
Dear All,
This one is trivial. NULL(...) is simply out of context in a transfer
statement.
Bootstrapped and regtested on FC17/x86_64. OK for trunk and 4.8?
Cheers
Paul
2013-11-30 Paul Thomas pa...@gcc.gnu.org
PR fortran/34547
* resolve.c (resolve_transfer): EXPR_NULL is always in
Dear All,
This is a partial fix for this problem in that it generates a
temporary to provide a correct assignment but then goes on to do an
unnecessary reallocation of the lhs. That is to say, the temporary
could be taken over by the array descriptor. At the moment, I could
not see a good way
Hi Steve,
It certainly looks good to me and if it works on the intended targets,
it cannot be bad! OK for trunk.
Thanks for the patch
Paul
On 15 November 2013 18:33, Steve Ellcey sell...@mips.com wrote:
A while back I checked in a Fortran configure patch that allowed me to build
Fortran
Hi Steve,
It looks good to me - OK for trunk.
Thanks for the patch.
Paul
On 5 November 2013 18:07, Steve Kargl s...@troutmask.apl.washington.edu wrote:
The inlined patch fixes a problem where an array constructor
is used as the shape argument in RESHAPE. The patch is
straightforward and
at 04:56:36PM +0100, Paul Richard Thomas wrote:
This one is trivial. The ICE was caused by an assert that turns out
to be spurious and has been removed.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.8?
OK.
--
Steve
--
The knack of flying is learning how to throw
Dear All,
When I first posted it in Bugzilla, I thought that this patch is too
kludgey by far. However, it has grown on me and I now think that it
is the right thing to do. The patch is self-explanatory.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.7/4.8
with an appropriate
Thanks - committed to trunk as r204358. 4.7 and 4.8 are to follow in a few days.
Paul
On 4 November 2013 21:01, Tobias Burnus bur...@net-b.de wrote:
Paul Richard Thomas wrote:
When I first posted it in Bugzilla, I thought that this patch is too
kludgey by far. However, it has grown on me
Dear All,
This one is trivial. The ICE was caused by an assert that turns out
to be spurious and has been removed.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.8?
Cheers
Paul
2013-11-01 Paul Thomas pa...@gcc.gnu.org
PR fortran/57445
* trans-expr.c
Dear Tobias,
Your patch is OK for trunk.
Thanks for the patch
Are you sure that PR58857 is valid? If so, I stick my legs up in the
air and give up :-)
Cheers
Paul
On 24 October 2013 00:09, Tobias Burnus bur...@net-b.de wrote:
A rather simple patch, which tries to implement Fortran 2008's
Dear Tobias,
The .diff does not seem to reflect what is in the file - I am at a
loss to explain why.
Committed as revision 204177.
Thanks for the review.
Paul
On 29 October 2013 07:32, Tobias Burnus bur...@net-b.de wrote:
Am 28.10.2013 23:26, schrieb Paul Richard Thomas:
This patch
Dear All,
This patch addresses issues arising from PR57893. It is entirely obvious.
Bootstraps and regtests on FC17/x86_64 - OK for trunk?
Cheers
Paul
PS I wash my hands of all attempts to use BT_HOLLERITH types!
2013-10-29 Paul Thomas pa...@gcc.gnu.org
PR fortran 57893
*
Dear Tobias,
This is OK for trunk.
Thanks for the patch.
Paul
On 21 October 2013 19:32, Tobias Burnus bur...@net-b.de wrote:
The issue came up while reviewing the patch for PR58793.
Build and regtested on x86-64-gnu-linux
OK for the trunk?
Tobias
--
The knack of flying is learning
Dear Tobias,
Looks good to me. Thanks for the patch.
I think that should be done as follow-up patch.In particular, it is not
obvious how it should be handled.
OK - I'll commit tonight, as is.
The program below ICEs in gfc_typenode_for_spec;with both Intel's and Cray's
Committed as r203915. I have a fix for the hollerith nonsense that
yields the same behaviour as other brands. I'll submit tonight.
Cheers
Paul
On 21 October 2013 11:20, Tobias Burnus bur...@net-b.de wrote:
Paul Richard Thomas wrote:
This patch is fairly obvious and follows a suggestion from
Dear All,
This patch is fairly obvious and follows a suggestion from Tobias to
use gfc_element_size. He even wrote the testcase!
Bootstrapped and regested on FC17/x86_64 - OK for trunk?
Cheers
Paul
PS In writing this, I have just noted that I need to trap ts-type ==
BT_HOLLERITH. It would
Dear Tobias,
Your patch is fine for trunk.
Thanks
Paul
On 16 October 2013 00:38, Tobias Burnus bur...@net-b.de wrote:
As the test case (see also PR) showed, gfortran was rejecting:
subroutine list_move_alloc(self,item)
class(list_node),intent(inout) :: self
Hi Tobias,
Have you checked that:
subroutine sub(a)
class(*),pointer :: a
a = null()
end subroutine
does not give an error? I think that it is why the check was introduced.
Cheers
Paul
On 13 October 2013 09:51, Tobias Burnus bur...@net-b.de wrote:
*PING*:
Then, the patch is OK for trunk :-)
Thanks for putting this right - it's obviously my cock-up!
Cheers
Paul
On 15 October 2013 22:20, Tobias Burnus bur...@net-b.de wrote:
Hi Paul,
Paul Richard Thomas wrote:
Have you checked that:
subroutine sub(a)
class(*),pointer
Dear Janus,
This is OK for trunk and, in my opinion, for back-porting in its entirity.
Thanks for the patch
Cheers
Paul
On 21 September 2013 16:31, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
the straightforward patch in the attachment does two things:
1) It prevents a segfault, which is
Dear Tobias,
I think that Janus's OK of the 27th was already enough :-)
The tweaks that you have made since make it look much cleaner. So,
once more - OK for trunk.
Thanks for the patch
Paul
On 27 July 2013 21:51, Tobias Burnus bur...@net-b.de wrote:
Tobias Burnus wrote:
Giving up on the
Dear All,
The attached patch represents progress to date. It fixes the original
problem in this PR and allows John Reid's version of
iso_varying_string/vocabulary_word_count.f90 to compile and run
correctly. It even bootstraps and regtests!
However, it doe not fix:
PR51976 comment #6 and
Dear All,
Committed as obvious revision 195915. The patch is a generalisation
of Tobias' fix.
2013-02-09 Paul Thomas pa...@gcc.gnu.org
PR fortran/55362
* check.c (array_check): It is an error if a procedure is
passed.
2013-02-09 Paul Thomas pa...@gcc.gnu.org
PR
It looks OK to me - is Jakub OK with it?
Cheers
Paul
On 8 February 2013 21:48, Thomas Koenig tkoe...@netcologne.de 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
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 mikael.mo...@sfr.fr wrote:
Hello,
this is the last
Committed revision 195741.
Thanks for the review.
Paul
On 28 January 2013 22:18, Thomas Koenig tkoe...@netcologne.de 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
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
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 bur...@net-b.de
**ping**
On 23 January 2013 11:06, Tobias Burnus bur...@net-b.de wrote:
Paul Richard Thomas wrote:
*** gfc_alloc_allocatable_for_assignment (gf
*** 8224,8229
--- 8250,8262
desc, tmp);
tmp = gfc_conv_descriptor_dtype (desc
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 mikael.mo...@sfr.fr wrote:
Hello,
for the case:
[...]
use select_precision, only: wp = dp
interface
Thanks, Janus.
Committed as revision 195492.
Cheers
Paul
On 27 January 2013 00:15, Janus Weil ja...@gcc.gnu.org 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.
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 ja...@gcc.gnu.org wrote:
Hi all,
here is a close-to-obvious patch for an ICE-on-invalid regression. It
removes as assert, which is
Dear,
I missed the null interface case in the fix for PR54286. The fix is
'obvious' and 'safe'.
Thanks to Dominique for identifying the problem and the fix.
Cheers
Paul
Author: pault
Date: Tue Jan 15 05:29:01 2013
New Revision: 195185
URL:
Dear Janus (and Dominique),
Thanks for the review. I found that the symmetrization is necessary
experimentally :-) I did not think anything of it, since I have
encountered such asymmetries elsewhere in interface.c. When I have a
quiet moment, I'll try to understand why this is necessary for
Dear Richard,
Yes, please do.
Thanks for doing this.
Paul
On 13 January 2013 09:35, Richard Sandiford rdsandif...@googlemail.com wrote:
Here's the result of running the copyright script on libgfortran/.
The script also updates libgfortran/generated, but I checked that
that part of the patch
Dear All,
It is something of an exaggeration to say that this PR is a regession,
although it is true that gcc-4.7 gives error messages for the testcase
in the correct places. In fact, these messages disappear if IMPLICIT
INTEGER (a) at the start of the testcase.
The fix ensures that the
Fix discussed and okayed by Jakub in PR. Patch committed as 'obvious'
in revision 195124.
Cheers
Paul
2013-01-08 Paul Thomas pa...@gcc.gnu.org
PR fortran/55868
* class.c (get_unique_type_string): Change $tar to STAR and
replace sprintf by strcpy where there is no formatting.
To be clear - I was awaiting a formal submission but indicating that I
would OK it when it was made. I completely missed the posting of 16th
December.
OK by me for trunk, followed by 4.6 and 4.7.
Cheers
Paul
On 11 January 2013 21:51, Mikael Morin mikael.mo...@sfr.fr wrote:
Le 11/01/2013
Dear Tobias,
It looks good to me. OK for trunk
Thanks for the patch - we'll have regressions down below 20 by
tonight. I am rather certain that I have the correct fix for PR55618.
Let's see if we can get to single figures, once more, by the end of
the month!
Paul
On 7 January 2013 10:13,
Dear All,
These PRs all have a similar or identical cause. GFC_CLASS_TYPE_P was
not being set and/or pointer references were not being cast correctly.
The fundamental fix is in trans_types.c(gfc_get_derived_type), where
the flag is now explicitly set for field_type, thereby ensuring that
no
about registering the commit, so I'll
close the PRs in the morning.
Thanks for the review
Paul
On 6 January 2013 15:25, Tobias Burnus bur...@net-b.de wrote:
Paul Richard Thomas wrote:
Boostratpped and regtested on FC17/x86_64 - OK for trunk?
OK - with the below nits fixed. Thanks
Dear Tobias,
This, as you say, is obvious. OKfor trunk.
Thanks for the patch.
Paul
On 6 January 2013 16:32, Tobias Burnus bur...@net-b.de wrote:
A rather obvious fix, though one can think about the error wording.
Bootstrapped and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
Dear Tobias,
I think that the patch would be much less opaque if repeated operation
to produce code were turned into functions, as I did for the defined
assignment patch; eg resolve.c(build_assignment, add_code_to_chain)?
What you have done is OK but it is HEAVY, as is much of the content of
, I think the test case
should also include the vector-section example.) Thanks for working on that
regression.
Paul Richard Thomas wrote:
First of all, thanks for the review! I still owe you my comments on
FINAL; I got lost in trying to fix these various regressions :-) I
promise
side. (Although, I think the test case
should also include the vector-section example.) Thanks for working on that
regression.
Paul Richard Thomas wrote:
First of all, thanks for the review! I still owe you my comments on
FINAL; I got lost in trying to fix these various regressions :-) I
Dear Tobias,
This one is 'obvious' - OK for trunk.
Thanks
Paul
On 31 December 2012 13:16, Tobias Burnus bur...@net-b.de wrote:
This simple patch fixes a wrong indent and adds a _final component to the
virtual tables generated for intrinsic types.
This patch not only prepares the trunk for
Dear Tobias,
This one is also OK for trunk. It does cross my mind, however, that
we should offer STRIDE as a gcc extension, in anticipation of F201x.
Cheers
Paul
On 31 December 2012 13:17, Tobias Burnus bur...@net-b.de wrote:
The attached patch adds a new - internal only - intrinsic, STRIDE,
Dear Tobias,
s/Argument is neither a pointer/allocatble/Argument is neither a
pointer/allocatable/
Why have you all the asserts for se.pre and se.post? Did you have
trouble with this or is there some hidden nasty that I am unaware of?
Should you not either return rapidly for an intrinsic type or
Dear Mikael and Steve,
From a quick read of your correspondence in the PR, you seem to have
covered all the angles between you.
OK for trunk.
As for the branches; yes, but how far back to go? I guess that
4.6 and 4.7 should be patched, if possible, since they are in current
use in
Dear Tobias,
Hah! You are right about null(x). It is an odd constraint, though,
since all that is used is the type/kind information.
OK for trunk
Thanks for the patch.
Paul
On 3 January 2013 17:38, Tobias Burnus bur...@net-b.de wrote:
The attached patch fixes two ICE.
Regarding the
Dear Tobias,
Yes, following your previous patch that I OK'd this is clearly OK for trunk.
Thanks
Paul
On 4 January 2013 00:23, Tobias Burnus bur...@net-b.de wrote:
NULL with MOLD should be rejected as (default) initialization expression.
From F2008:
R506 null-init is function-reference
Dear All,
As noted by Janus in comment #2 of the PR, I think the function
'copy_ts_from_selector_to_associate' comes too early (namely during
parsing). It tries to resolve the target expr, which should rather
wait until resolution stage!?!
It turned out that the function of the call to
Dear Tobias,
First of all, thanks for the review! I still owe you my comments on
FINAL; I got lost in trying to fix these various regressions :-) I
promise that I'll come back to you first thing tomorrow.
It looks mostly okay; however, you do not handle vector sections correctly,
which
Dear Tobias,
That's fine - OK for trunk.
Thanks for the patch!
Paul
On 27 December 2012 23:16, Tobias Burnus bur...@net-b.de wrote:
*ping*
http://gcc.gnu.org/ml/fortran/2012-12/msg00167.html
Tobias Burnus:
Fix one of the remaining issues of PR 55763: MOVE_ALLOC with CLASS(*)
either for
Dear Tobias,
I did this one myself on the plane to the UK last night! We came to
the same patch, so yes it's OK for trunk.
Thanks
Paul
On 21 December 2012 22:41, Tobias Burnus bur...@net-b.de wrote:
Another two fixes for CLASS(*). (We really should audit all calls to
gfc_find_derived_vtab
Dear Tobias,
Could you note that class(*) is complete up to the restriction to
fixed length character values only?
Thanks
Paul
On 20 December 2012 10:55, Tobias Burnus bur...@net-b.de wrote:
The following patch updates the Fortran part of the GCC 4.8 release notes at
Dear Tobias,
OK for trunk, apart from:
s/the string length if of type gfc_charlen_type_node/the string length
is of type gfc_charlen_type_node/
Thanks for the patch
Paul
On 20 December 2012 00:29, Tobias Burnus bur...@net-b.de wrote:
TRANSFER(..., string) created on x86-64 an integer(8)
Dear All,
Committed as revision 194622 and corrigendum 194626 (removes one test
from unlimited_polymorphic_2.f03).
Thanks to one and all for the help.
Paul
On 19 December 2012 07:17, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Thanks Tobias and Dominique,
I'll make
Dear Jakub,
The fortran part looks fine to me. The sooner that you commit the
better - I will update the unlimited polymorphic patch accordingly.
Thanks
Paul
On 18 December 2012 15:11, Jakub Jelinek ja...@redhat.com wrote:
Hi!
- PR c/39464 P2 -Wpointer-sign fix
Thanks Tobias and Dominique,
I'll make the corrections that you have requested. I believe that the
2*(GFC_MAX_SYMBOL_LEN+1) has a historic origin - I had not thought
about it until last night, when you pointed it out.
As for the segfault - that line should go. The automatic nulling of
the
Dear Tobias,
This does what it is advertised to do - OK for trunk
Thanks for the patch.
Paul
PS Thomas has beaten it to me on the other two patches; they look OK
for trunk to me too.
On 9 December 2012 20:04, Tobias Burnus bur...@net-b.de wrote:
Janus Weil wrote:
The expr to al-expr change
Dear Tobias,
Up front, thanks for this initial feedback. Dominique informed me on
#gfortran that the patch works as advertised.
...snip...
Running your test cases through crayftn, I found:
if (SAME_TYPE_AS (obj1, u1) .neqv. .FALSE.) call abort
^
ftn-1698
OK for trunk.
I think that Janus approved the other patch that we talked about last
night, did he not?
Spent evening fixing unlimited polymorphic bugs - all of them
associated with character targets!
Cheers
Paul
On 3 December 2012 16:54, Tobias Burnus bur...@net-b.de wrote:
Dear all,
this
Dear All,
It is only now that I see that my mail to Mikael and the release
managers, to say that I would commit, bounced because of excess MIME
content. I apologise for that. I can only say in mitigation that
fortran is not release critical and regressions are unlikely because
of the conditions
Dear Janus,
Thanks for the patch - it's OK for trunk and 4.7.
Cheers
Paul
On 19 November 2012 21:39, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
here is another contribution in trying to reduce the still too large
number of regressions in the Fortran front end (which used to be
basically
Dear Tobias,
Looks obvious if you ask me ...
..and to me too. OK for trunk.
Thanks
Paul
Hi Tobi,
It looks straightforward to me but I am not convinced that a fortran
maintainer should be giving the green light on this :-)
Cheers
Paul
On 28 October 2012 16:28, Tobias Schlüter
tobias.schlue...@physik.uni-muenchen.de wrote:
Ping. This issue stands in the way of a very simple
Dear Tobias,
I had already reviewed this patch in its previous accidental manifestation :-)
OK for trunk
Thanks for the patch
Paul
On 19 October 2012 10:22, Tobias Burnus bur...@net-b.de wrote:
gfortran was ignoring the TARGET_SYSTEM_ROOT and thus searched in
/usr/include for files
Hi Tobias,
The patch to fortran/cpp.c looks like a very worthy bit of
housekeeping but doesn't seem to me to have much to do with PR54844
:-)
The rest is fine and is OK for trunk.
Thanks for the fix.
Paul
On 17 October 2012 12:02, Tobias Burnus bur...@net-b.de wrote:
In GCC 4.8, module
Hi Tobias,
The patch to fortran/cpp.c looks like a very worthy bit of
housekeeping but doesn't seem to me to have much to do with PR54844
:-)
The rest is fine and is OK for trunk.
Thanks for the fix.
Paul
On 17 October 2012 12:02, Tobias Burnus bur...@net-b.de wrote:
In GCC 4.8, module
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!
The c ==
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 *expr1,
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
test.
* gfortran.dg/defined_assignment_2.f90: New test.
* gfortran.dg/defined_assignment_3.f90: New test.
On 14/08/2012, Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
Mikael,
On 14 August 2012 10:42, Mikael Morin mikael.mo...@sfr.fr wrote:
On 14/08/2012 07:03, Paul
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.
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'
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 mikael.mo...@sfr.fr wrote:
Hello,
here is the fix for the regression I have introduced with my assumed
rank bounds patch.
Will test and commit as obvious.
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 ubiz...@gmail.com wrote:
Hello!
Without -mno-explicit-relocs, alpha generates:
ldq $27,myBindC($29)!literal!6
Dear Tobias,
OK for the trunk?
Yes indeed - thanks for the patch.
Cheers
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 Tobias,
This one is indeed obvious! OK for trunk.
Cheers
Paul
On 13 June 2012 09:50, Tobias Burnus bur...@net-b.de 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
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 bur...@net-b.de 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
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,
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 bur...@net-b.de wrote:
First: I have another rather simple patch, which still needs to be reviewed:
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
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
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 bur...@net-b.de 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
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 bur...@net-b.de 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)
+ {
I think it is not obvious
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 bur...@net-b.de 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
Committed as trivial/obvious in revision 185924. Thanks to Brian Ames
for spotting the error!
2012-03-28 Paul Thomas pa...@gcc.gnu.org
Tobias Burnus bur...@gcc.gnu.org
PR fortran/52652
* match.c (gfc_match_allocate, gfc_match_deallocate): Change
not.. or to
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,
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 bur...@net-b.de wrote:
Tobias Burnus wrote:
If the interface in a PROCEDURE() statement is Bind(C),
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 required in
1001 - 1100 of 1186 matches
Mail list logo
