mikael.mo...@sfr.fr wrote:
Hello Paul,
comments below
Le 08/02/2015 16:24, Paul Richard Thomas a écrit :
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h(revision 220482)
--- gcc/fortran/gfortran.h(working
Dear All,
Dominique has just flagged up a slight technical problem with the patch...
it's not for this PR :-( Please find the correct patch attached.
Paul
On 8 February 2015 at 12:42, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear All,
This came up at
https
Dear Mikael,
It looks good to me for trunk and the branches.
Thanks for the patch
Paul
On 6 February 2015 at 21:31, Mikael Morin mikael.mo...@sfr.fr wrote:
Hello,
we currently reject programs of the form
module m
integer :: s
end module m
subroutine s
use m, only: x = s, x = s
Dear All,
This is a slight development of the patch posted on the PR itself.
class.c(finalize_component) is not able to deal correctly with
non-allocatable, derived type array components that have allocatable
components. Rather than generating loops in finalize_component, the
condition is
Dear Jerry,
This is OK for trunk. Maybe it is best to leave it for a week or two
before committing to the branches?
Thanks for the patch.
Paul
On 7 February 2015 at 03:08, Jerry DeLisle jvdeli...@charter.net wrote:
With the attached patch I create a special version of fbuf_flush that is
only
Dear Tobias,
That is OK for trunk.
Thanks for the patch.
Paul
On 5 February 2015 at 22:04, Tobias Burnus bur...@net-b.de wrote:
A rather simple patch.
Build and reg-tested on x86-64-gnu-linux.
OK for the trunk?
Tobias
--
Outside of a dog, a book is a man's best friend. Inside of a
,
the assignment is performed here.
2015-02-04 Paul Thomas pa...@gcc.gnu.org
PR fortran/640757
* gfortran.dg/type_to_class_2.f90: New test
* gfortran.dg/type_to_class_3.f90: New test
On 3 February 2015 at 22:36, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear
Dear Dominique,
I have fixed all the problems except the last one. For that case, the
other brand gives
type_to_class_30.f90(19): error #7822: Variables containing ultimate
allocatable array components are forbidden from appearing directly in
input/output lists.
print *, TestReference([Test(99),
Dear Dominique,
On transferring from my laptop to my workstation, I find that it
segfaults in runtime - both are x86_64/FC21. If I can, I intend to
investigate tonight.
Thanks for the report.
Paul
On 2 February 2015 at 17:53, Dominique Dhumieres domi...@lps.ens.fr wrote:
Dear Paul,
I have
?
Best regards
Paul
On 28 January 2015 at 21:09, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear All,
This regression was caused by the patch for PR60357. The fix is
straightforward. Please note however, that I have not checked for
other fallout yet - I have merely addressed
ping!
On 27 January 2015 at 20:38, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear All,
This patch enables the passing of an allocatable class object, scalar
or array, to a derived type of the declared type, either in an
assignment or as an actual argument. Much of the effort
Dear All,
This regression was caused by the patch for PR60357. The fix is
straightforward. Please note however, that I have not checked for
other fallout yet - I have merely addressed the reported failure. I
will check around the reported testcase tomorrow night.
Dominique, thanks for the rapid
Dear All,
The highly embarrassing bug in mold = allocations to class entities
has been fixed in revisions 220140 and 220191 for trunk and 4.9
respectively. The PR has been set as RESOLVED.
Cheers
Paul
Dear All,
This patch enables the passing of an allocatable class object, scalar
or array, to a derived type of the declared type, either in an
assignment or as an actual argument. Much of the effort went into
sorting out the finalization call so that the 'left over' allocatable
components added
Hi Janus,
The testcase has a dependence on libubsan.so, which my LD_LIBRARY_PATH
does not seem to be able to resolve. It therefore fails in the
regression test. When I point to ~/lib64, I get the message:
/svn/trunk/gcc/testsuite/gfortran.dg/class_allocate_18.f90:8: runtime
error: signed integer
Dear All,
The fix for the failing testcases in comments #6 and #7 in this PR
have been fixed as 'obvious' in r220140.
Thanks to Mikael for reopening the PR as a placeholder.
This is such an embarrassing bug that I intend to commit to 4.9 as
well even if it is not a regression, unless there are
Dear Janus,
I know somewhat less than nothing about such matters. I suggest that
you contact the authors of the testcases that use libubsan that you
mention.
Sorry
Paul
On 26 January 2015 at 22:20, Janus Weil ja...@gcc.gnu.org wrote:
Hi Paul,
The testcase has a dependence on libubsan.so,
Dear Janus,
As it happens I loaded this patch up last night to see if I could plug
the last leak in my patch for PR63205, which is making heavy use of
the default finalizers. It seemed to do the job. As you said in the PR
it appears to be a typo and really is obvious. I can canfirm that it
Dear All,
Andre's patch for PR60357 did not fix this PR as we had hoped. The fix
needed is trivial, nay 'obvious'.
The problem was that a deep copy was not being performed; just an
assignement of the pointers to the data. In consequence the testcase
was being clobbered with a double free in the
Dear All,
The attached patch fixes the confusion between substrings of character
associate-names and scalars being misused as arrays.
It is sufficiently obvious and has been tested by Dominique that I
will commit it later today if there are no opinions to the contrary.
I will now turn my
, because people don't understand that 'length'
stores
the product of elem_size times string_len, because all they see is an
assignment of a length-7 char array.
What do we do about it?
Regards,
Andre
On Thu, 8 Jan 2015 20:56:43 +0100
Paul Richard Thomas paul.richard.tho
(deferred char arrays and chararrays in unlimited polymorphic entities)
interchangeable w/o computation.
What's your opinion?
Regards, Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel. +49 241.9291018 * ve...@gmx.de
Paul Richard Thomas paul.richard.tho...@gmail.com schrieb
, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear Andre,
I am open to either - what do the others think?
The reason why I am for differentiating between unlimited_polymorphic
objects and the deferred length character arrays is because of the
difference in the way in which arrays
sets it to
zero. Could be in gfc_conv_structure but that is only a guess.
Unfortunately am I on travel 'till Sunday and don't have my laptop with me.
Sorry for that.
Regards,
Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel. +49 241.9291018 * ve...@gmx.de
Paul Richard Thomas
Committed with the patch for PR61275 as revision 219801. Also fixes
PR55932 for which a testcase has been added.
Will follow with a commit to 4.9 during the week.
Cheers
Paul
On 16 January 2015 at 12:30, Andre Vehreschild ve...@gmx.de wrote:
Hi all,
please find attached a fix for pr60357.
mood, I have attached it to this message too :-)
Cheers
Paul
On 17 January 2015 at 11:55, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear All,
The attached patch fixes the confusion between substrings of character
associate-names and scalars being misused as arrays
Applied as 'obvious' in revision 219802.
2015-01-17 Paul Thomas pa...@gcc.gnu.org
PR fortran/64578
* trans-expr.c (gfc_trans_pointer_assignment): Make sure that
before reinitializing rse, to add the rse.pre to block before
creating 'ptrtemp'.
* trans-intrinsic.c
Dear Janus,
Since it is a regression, by all means update the branches. We
usually, propose delaying a bit but I am not convinced that this is
effective for this kind of bug fix - usually, further problems take a
long time to emerge. Thus, I would recommend that you get on with it.
Thanks
Paul
the string length would have been lost. The attached extended
version fixes this issue.
Sorry for the duplicate work.
Bootstraps and regtests ok on x86_64-linux-gnu.
Regards,
Andre
On Sun, 11 Jan 2015 16:11:10 +0100
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
Dear Andre
Dear Andre,
This is OK for trunk. I have not been keeping track of whether or not
you have commit rights yet. If not, I will get to it sometime this
week.
Thanks for the patch.
Paul
On 10 January 2015 at 15:59, Andre Vehreschild ve...@gmx.de wrote:
Hi all,
attached patch fixes the bug
Dear Janus,
As you say, the patch is pretty straightforward :-) OK for trunk.
Thanks for the patch
Paul
On 11 January 2015 at 11:21, Janus Weil ja...@gcc.gnu.org wrote:
Ping! (I think this patch is pretty straightforward ...)
Cheers,
Janus
2015-01-06 16:19 GMT+01:00 Janus Weil
Dear Janus,
Well done for sorting that out. OK for trunk.
Thanks for the patch.
Paul
On 11 January 2015 at 14:38, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
this patch fixes a wrong-code regression related to operators, by
making sure that we look for typebound operators first, before
Dear Andre,
Thanks for the patch. As I have said to you, off list, I think that
the _size field in the vtable should contain the kind information and
that the _len field should carry the length of the string in bytes. I
think that it is better to optimise array access this way than to
avoid the
Hi Tobias,
In the check.c error messages, you use 'A argument'. Should you not
use 'SOURCE argument', following CO BROADCAST (SOURCE, SOURCE IMAGE [,
STAT, ERRMSG]) ? I am looking at WG5/N1983 - is there some more recent
proposal?
When do you intend to implement a _gfortran_caf_co_broadcast
Dear Tobias,
Given Dominques news that this fixes a golden oldie that drove me to
madness and PR60593 - OK for trunk, 4.8 and 4.9
Many thanks for the patch
Paul
On 27 August 2014 22:59, Tobias Burnus bur...@net-b.de wrote:
The current gfc_check_dependency check always looked at the pointer
Dear Tobias,
Obviously there is no problem with this - OK for trunk
Cheers
Paul
On 27 August 2014 23:37, Tobias Burnus bur...@net-b.de wrote:
I claim that it is part 2 of 3 of the CAF dep series, but the patch has
nothing to do with it, except that it is in the way.
Technically, it just
Dear Tobias,
This looks fine to me - OK for trunk.
Thanks for this massive effort!
Paul
On 28 August 2014 08:13, Tobias Burnus bur...@net-b.de wrote:
This patch is based on 1/2 and 2/2 on the series. When the patch is
approved, OpenCoarrays needs to be adapted; however, as surplus arguments
Dear Steven,
I am constantly amazed that data statement bugs keep turning up:-)
Anyway, your fix is fine for trunk and, if you feel so inclined, 4.8
and 4.9.
Thanks
Paul
On 23 August 2014 16:52, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This bug is an error recovery issue. A data
Dear All,
There are known issues with unlimited polymorphic variables
representing characters : see
https://groups.google.com/forum/#!topic/comp.lang.fortran/aRz3HMpblTs
and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
One way or another, the variable itself needs to carry the string
Dear Richie and Tobias,
I OK'd this patch on 9th August but I now see that the posting bounced
because of mime content emanating from my phone mail reader :-(
I also thought that the patch is obvious.
Cheers
Paul
On 13 August 2014 23:22, Tobias Burnus bur...@net-b.de wrote:
Hi Richard,
Dear Tobias, dear all,
This patch and the documentation patch are OK for trunk.
Many thanks
Paul
On 6 August 2014 08:46, Tobias Burnus bur...@net-b.de wrote:
* PING * – of the patch with the obvious change mentioned by Alessandro
(i.e. using if(is_lock_type))?
Tobias
On 1 August 2014
Dear Tobias,
Whilst I am aware that we can now use the single line C++ comment,
would it perhaps be a better idea to stick with the C style comments
just for uniformity?
+ if (arg-ts.type == BT_CLASS)
+{
+ tmp = gfc_vtable_size_get (TREE_OPERAND (argse.expr, 0));
+ tmp =
Dear Tobias,
It looks OK to me - good for trunk
Thanks for the patch
Paul
On 14 July 2014 19:19, Tobias Burnus bur...@net-b.de wrote:
If the atomic_ref VALUE argument is of a different kind than the ATOM
argument, the result was wrong with -fcoarray=lib. That showed up with
Dear Tobias,
That's good for trunk.
Thanks for the patch.
Paul
On 12 July 2014 17:05, Tobias Burnus bur...@net-b.de wrote:
This patch is relative to the still unreviewed patch
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00864.html
With this patch, all of Fortran 2008's and TS18508's
Dear Tobias,
OK for trunk.
Thanks for the patch.
Paul
On 11 July 2014 23:30, Tobias Burnus bur...@net-b.de wrote:
This patch updates the atomic support for TS18508, namely:
– The atomic intrinsics now take a STAT= argument
– Add the new atomics atomic_{add,and,or,xor} and their fetch
Dear All,
Committed to trunk as revision 212486.
Cheers
Paul
On 12 July 2014 20:52, Tobias Burnus bur...@net-b.de wrote:
Dear Paul,
the patch attached to the PR looks good to me for GCC 4.8, 4.9 and 4.10. For
4.9.1 vs. 4.9.2, it's Jakub's call.
Tobias
Paul Richard Thomas wrote
Dear All,
This PR is caused by a rather unfortunate cast for the pointer to the
return value from matmul:
struct array1_real(kind=4) D.2357;
D.2357 = *(struct array1_real(kind=4) *) __result;
D.2357.data = 0B;
snip
_gfortran_matmul_r4 (*(struct array1_real(kind=4)
Dear Tobias,
The patch is so safe and, as you say, has no side effects that I will
commit to 4.9 first.
Cheers
Paul
On 7 July 2014 10:05, Tobias Burnus tobias.bur...@physik.fu-berlin.de wrote:
Paul Richard Thomas wrote:
This PR is caused by a rather unfortunate cast for the pointer
Dear Dominique,
On condition that your commit the right patch :-), OK for 4.9.1
Cheers
Paul
On 7 July 2014 13:48, Dominique Dhumieres domi...@lps.ens.fr wrote:
In https://gcc.gnu.org/ml/fortran/2014-06/msg00150.html
I wrote
I am now trying to do the back port to 4.9 and I got two failures:
Dear Dominique,
OK for trunk.
Thanks for the patch
Paul
On 5 July 2014 18:09, Dominique Dhumieres domi...@lps.ens.fr wrote:
On Mon, 05 May 2014, I have posted
https://gcc.gnu.org/ml/fortran/2014-05/msg00012.html.
On IRC Tobias Burnus remarked that the *.mod file in
To quote William Shakespeare:
FALSTAFF
‘Tis not due yet; I would be loath to pay him before
his day. What need I be so forward with him that
calls not on me? Well, ’tis no matter; honour pricks
me on. Yea, but how if honour prick me off when I
come on? how then? Can honour set to a leg? no: or
an
Dear Tobias,
This looks absolutely fine to me - good for trunk.
Thanks for the patch and for the overall co-array effort.
Paul
On 4 July 2014 08:02, Tobias Burnus bur...@net-b.de wrote:
Another somewhat early PING**2
On June 29, 2014, Tobias Burnus wrote:
This patch fixes some issues
Hi Jerry,
The patch looks to be OK for trunk.
Did you check it with the NIST by any chance?
Thanks a lot
Paul
On 26 June 2014 03:58, Jerry DeLisle jvdeli...@charter.net wrote:
Hi,
This bug has nothing to do with negative numbers as in the description.
However, the problem is due to
Dear Tobias,
I have taken a look through the following three patches:
* https://gcc.gnu.org/ml/fortran/2014-06/msg00178.html
* https://gcc.gnu.org/ml/fortran/2014-06/msg00183.html
* https://gcc.gnu.org/ml/fortran/2014-06/msg00187.html
I can find nothing to object to in any of them; on the
Dear FX,
Not only is it 'obvious' but it can do no harm in any circumstances
:-) OK to commit
Thanks
Paul
On 19 June 2014 13:14, FX fxcoud...@gmail.com wrote:
In expr.c:scalarize_intrinsic_call(), we don't deal correctly with intrinsics
that have an optional kind argument, while
Dear Tobias and Alessandro,
Well what can I say? The patch is something of a tour de force!
Sandro, questo è assolutamente meraviglioso. Molte grazie da tutti
noi.
I have done nothing to check the functionality of the patch. However,
I have checked the conformance with coding standards and
2014-06-14 Paul Thomas pa...@gcc.gnu.org
* trans-array.c (gfc_conv_array_parameter): Assign 'old_desc'
to 'new_desc' rather than some of the components.
Bootstraps and regtests OK
Committed at revision 211664.
Cheers
Paul
Dear Francois-Xavier,
The patch and the logic behind it, including the name dependence, is
fine. OK for trunk and, I suggest, 4.9 and 4.8 after a suitable
delay.
Thanks!
Paul
On 8 June 2014 18:40, FX fxcoud...@gmail.com wrote:
The attached one-line patch fixes PR45187
Dear All,
This was a slip up on my part. The fix is obvious - OK for trunk and 4.9?
Cheers
Paul
2014-06-09 Paul Thomas pa...@gcc.gnu.org
PR fortran/61406
* trans-stmt.c (trans_associate_var): Check that array
constructors are constant for direct reference.
2014-06-09 Paul
Dear Dominique,
Committed to trunk as revision 211374.
I decided that getting rid of the double temporary was delving too
deep into the workings of trans-array.c to be worthwhile at the
moment.
Cheers
Paul
On 9 June 2014 12:05, Dominique Dhumieres domi...@lps.ens.fr wrote:
Dear Paul,
This
Dear Dominique,
Without the patch applied, trunk shows 360 bytes definitely missing in
3 blocks for the original testcase and 9 out of 92 allocs did not have
corresponding frees. WIth the patch, I get:
==20527==
==20527== HEAP SUMMARY:
==20527== in use at exit: 0 bytes in 0 blocks
==20527==
Dear Tobias,
OK for trunk with one slight quibble:
I would rather see
+ /* Generate the function call. */
+ if (code-resolved_isym-id == GFC_ISYM_CO_MAX)
+fndecl = gfor_fndecl_co_max;
+ else if (code-resolved_isym-id == GFC_ISYM_CO_MIN)
+fndecl = gfor_fndecl_co_min;
+ else if
Dear Tobias,
This one is fine for trunk.
Thanks for the patch.
Paul
Dear Tobias,
On 27 April 2014 20:56, Tobias Burnus bur...@net-b.de wrote:
First, I would be really delighted if someone could review my coarray
patches for the trunk as it makes simpler to develop patches on top of it:
* http://gcc.gnu.org/ml/fortran/2014-04/msg00087.html
This is OK for
Dear Tobias,
As you say, this of a rather obvious nature and is OK for trunk.
Cheers
Paul
On 21 April 2014 22:52, Tobias Burnus bur...@net-b.de wrote:
Dear all,
for a change, a patch for the trunk and not for the fortran-caf branch. The
following is a rather obvious patch which fixes the
.
On 12 April 2014 10:30, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Apr 12, 2014 at 07:27:00AM +0200, Paul Richard Thomas wrote:
I know that you are probably snowed under with requests like this! I
was away on a business trip when Mikael's approval below came and had
intended to apply it to 4.9
Dear All,
This fix, of itself, is quite obvious. The offset was being set to
zero for array segments, rather than that required for unity valued
lvalues.
I think that the fix could be used to clean up:
trans-expr.c(gfc_trans_alloc_subarray_assign)
trans-expr.c(gfc_trans_pointer_assign)
Dear Tobias,
This is, of course, fine since it is 'obvious' (in my opinion at least).
Thanks for the patch
Paul
On 27 March 2014 21:05, Tobias Burnus bur...@net-b.de wrote:
An early * PING* for this wrong-code issue.
Tobias Burnus wrote:
This patch fixes part of the problems of the PR.
Dear Tobias,
The patch looks OK to me. If nothing else, it offers a
rationalisation of all the lines of code that unset the attribute!
I am somewhat puzzled by Note: I failed to create a test case,
wheras I find one at the end of the patch. Can you explain what you
mean?
Cheers
Paul
On 19
Dear All,
The fortran part looks fine to me.
Thanks for the patch,gents
Paul
Dear All,
The attached patch allows the original testcase to compile but
attempting to use it runs into segfaults at runtime. The initializer
for 'decay_t' has a bad FIELD_DECL for 'decay_gen_t' since it lacks
the DECL_SIZE(_UNIT) fields but the TYPE_SIZE(_UNIT) fields are OK.
The patch runs
Dear Uros,
Tobias's patch is designed to be future-proof!
Cheers
Paul
On 20 February 2014 14:26, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
A rather simple patch.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
2014-02-20 Tobias Burnus bur...@net-b.de
PR fortran/602864
...@net-b.de:
Dear Paul, dear all,
On February 24, 2013 Paul Richard Thomas wrote:
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
Dear Janus,
This is OK for trunk, 4.8 and 4.7.
Thanks for the patch.
Paul
On 16 February 2014 23:11, Janus Weil ja...@gcc.gnu.org wrote:
Hi all,
here is a small patch for a ICE-on-valid regression. Regtested on
x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
Cheers,
Janus
2014-02-16
Dear All,
Committed as revision 207645 - thanks for review and RM OK.
Cheers
Paul
On 9 February 2014 13:55, Richard Biener rguent...@suse.de wrote:
On February 8, 2014 6:48:08 PM GMT+01:00, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear All,
This is another corner
Dear All,
Committed as revision 207646. Thanks for the review and RM OK.
Cheers
Paul
On 9 February 2014 13:56, Richard Biener rguent...@suse.de wrote:
On February 8, 2014 5:08:52 PM GMT+01:00, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear All,
I am aware that we
Dear All,
I am aware that we are in stage 4 but this wrong-code-on-valid PR is
confined to a corner of a corner and so I am certain that it can be
safely applied - OK, Richie?
This patch follows the same route as has been used for pointer array
assignment to components of derived type arrays by
Dear All,
This is another corner of a corner case that is not a regression but
fixes a wrong-code-on-valid.
At present, an actual argument of an elemental procedure with the
VALUE attribute is not passed by value. The fix is obvious.
Bootstraps and regtests on FC17/x86_64 - OK for trunk, 4.8
Dear All,
I propose to add the attached to the testsuite. It is the testcase
from PR60066, which was fixed by the patch for PR59066.
OK for trunk, 4.8 and 4.7?
On 5 February 2014 12:38, pault at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066
Dear All,
This regression was flagged by Harald and the trigger, r158683, was
identified by HJ. Many thanks to both. It surprises me that the bug
has lain dormant for so long.
The fix is fortunately relatively simple. CHARACTER scalars are, in
fact arrays in one shape or form and so using them
Mikael,
Je t'en remercie!
That must be one of the fastest reviews on record!
Committed as revision 207389
4.7 and 4.8 to follow next weekend.
Paul
On 1 February 2014 19:28, Mikael Morin mikael.mo...@sfr.fr wrote:
Le 01/02/2014 18:57, Paul Richard Thomas a écrit :
Dear All
Dear Mikael,
We seem to be breaking records tonight :-)
OK by me for trunk, 4.7 and 4.8.
Thanks!
Paul
On 1 February 2014 19:49, Mikael Morin mikael.mo...@sfr.fr wrote:
Hello,
here is a fix for PR57033.
The problem was gfc_convert_to_structure_constructor calling itself
recursively and
Dear Janus,
snip
well, actually the selector in the test case is not an array. And
polymorphic arrays as such have been supported since 4.7.
duuh! Shows how time flies when you're having fun!
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and, after a
decent delay, 4.8?
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
901 - 1000 of 1169 matches
Mail list logo
