This problem was caused by the code for scalarized array references to
subref arrays and deferred length variables not obtaining the correct
array descriptor and so getting the array span wrong. As it happens,
the lines, following the deleted part, correctly identify when the
info descriptor is a
Hi Steve,
I'm surprised that you didn't commit as obvious :-) OK for trunk.
Thanks
Paul
On Tue, 18 Jun 2019 at 20:30, Steve Kargl
wrote:
>
> The attach patch has been regression tested on x86_64-*-freebsd.
> If the pointer is NULL, the function simply returns. It seems
> that gfortran then
Hi Steve,
That's good to go - thanks
Paul
On Wed, 12 Jun 2019 at 23:44, Steve Kargl
wrote:
>
> The attach patch has been sitting in my tree for a year.
> It has been tested and updated as others have changed
> the gfortran code. The patch has been compiled and
> regression tested on
Hi Steve,
As the original author of the confusing code, I want to thank you for
de-confusing it!
OK
Paul
On Wed, 12 Jun 2019 at 20:01, Steve Kargl
wrote:
>
> This PR flags a section of confusing but correct code.
> The attach patch rewrites the code to hopefully provide
> some clarity. It
Hi Steve,
OK - thanks
Paul
On Wed, 12 Jun 2019 at 19:42, Steve Kargl
wrote:
>
> The attach patch has lived in my tree for 4 months.
> It's time to submit it. Passed regression testing
> for a long time.
>
> An INTENT(in) entity that has CLASS(*) dummy argument
> should not use SELECT TYPE to
OK, Steve
Thanks
Paul
On Wed, 12 Jun 2019 at 02:04, Steve Kargl
wrote:
>
> The attached patch fixes an ICE when freeing an array-spec
> that involves an assumed-shaped coarray (see testcase). The
> patch regression tests cleanly. I don't use coarrays, so
> cannot say whether the testcase is
m though.
>
> Christophe
>
>
> >
> > Many thanks for flagging it up.
> >
> > Paul
> >
> > On Mon, 10 Jun 2019 at 10:07, Christophe Lyon
> > wrote:
> > >
> > > On Sat, 8 Jun 2019 at 18:25, Andrew Benson
> > > wrote:
aul for the quick fix!
> >
> > On Saturday, June 8, 2019 4:56:46 PM PDT Paul Richard Thomas wrote:
> > > Committed as obvious in revision 272084.
> > >
> > > The problem was that the lhs symbol itself was not being checked as a
> > >
Committed as obvious in revision 272084.
The problem was that the lhs symbol itself was not being checked as a
proc_pointer - just the expression component.
I will get on with backporting tomorrow.
Cheers
Paul
2019-06-08 Paul Thomas
PR fortran/90786
* trans-expr.c
Hi Thomas,
It looks good to me. OK for trunk.
Thanks
Paul
On Sun, 2 Jun 2019 at 14:34, Thomas Koenig wrote:
>
> Hello world,
>
> this patch adds two tweaks to the argument repacking.
>
> First, when the size of an argument is known to be one, as in a(n1:n1),
> we can directly pass a pointer -
This turns out to be obvious. The component of the dummy argument
cannot be replaced by the hidden descriptor (actually the class
object) and so an ICE occurs. The fix is to add a guard against the
expression being a COMPONENT_REF.
I will commit to all three branches tomorrow unless there are any
Committed to 9-branch as revision 271089.
Paul
On Fri, 10 May 2019 at 09:00, Paul Richard Thomas
wrote:
>
> Committed to trunk as revision 271057.
>
> Will do likewise with 9-branch asap.
>
> Cheers
>
> Paul
>
> On Wed, 8 May 2019 at 19:40, Paul Richard T
Committed to trunk as revision 271057.
Will do likewise with 9-branch asap.
Cheers
Paul
On Wed, 8 May 2019 at 19:40, Paul Richard Thomas
wrote:
>
> Unless there are any objections to this patch, I plan to commit to
> trunk and 9-branch tomorrow night, with the change to the testcase
on with
fixing PDTs.
Cheers
Paul
On Mon, 6 May 2019 at 19:59, Paul Richard Thomas
wrote:
>
> It helps to attach the patch!
>
> On Mon, 6 May 2019 at 19:57, Paul Richard Thomas
> wrote:
> >
> > Unfortunately, this patch was still in the making at the release of
>
Hi Dominique,
Many thanks - I had already found this after replenishing my tree and
regtesting. I don't quite know how it escaped but the fix is obvious.
Amicalement
Paul
On Tue, 7 May 2019 at 09:39, Dominique d'Humières wrote:
>
> Hi Paul,
>
> With your patch, I see
>
> FAIL:
It helps to attach the patch!
On Mon, 6 May 2019 at 19:57, Paul Richard Thomas
wrote:
>
> Unfortunately, this patch was still in the making at the release of
> 9.1. It is more or less self explanatory with the ChangeLogs.
>
> It should be noted that gfc_conv_expr_present co
Unfortunately, this patch was still in the making at the release of
9.1. It is more or less self explanatory with the ChangeLogs.
It should be noted that gfc_conv_expr_present could not be used in the
fix for PR90093 because the passed descriptor is a CFI type. Instead,
the test is for a null
Hi Thomas,
Could you provide the patch, please, or was it already posted?
Cheers
Paul
On Sun, 28 Apr 2019 at 10:46, Thomas Koenig wrote:
>
> Hello world,
>
> going back a patch which was not included in gcc-9 because it was too
> late in the development cycle, here is a patch which, when
print *, x
> >
> > before
> >
> > if (any (abs (x - [1.,20.,3.,40.,5.,60.]) > 1.e-6)) stop 2
> >
> > the test succeeds!-(
> >
> > Also you don’t want pr89844 to be solved, don’t you?
> >
> > TIA
> >
> > Dominique
> >
> &g
Thanks, Steve.
Committed as revision 270489.
Paul
On Fri, 19 Apr 2019 at 18:28, Steve Kargl
wrote:
>
> On Fri, Apr 19, 2019 at 06:19:00PM +0100, Paul Richard Thomas wrote:
> > The part of this patch in resolve.c had essentially already been
> > sorted out by Tobias Bu
It looks good to me, modulo Dominique's query. OK for trunk (note from
Richi - still aiming for zero P1 bugs so you're good to go).
Thanks
Paul
On Fri, 19 Apr 2019 at 22:44, Steve Kargl
wrote:
>
> The attached patch fixes PR fortran/91066. The original
> code was feeding a nonsense string of
The part of this patch in resolve.c had essentially already been
sorted out by Tobias Burnus in comment #2 of the PR. I suspect that he
must have been put off the trail by the segfault that occurred when
this was implemented. In the end, the reason for the segfault is quite
straight forward and
093
> all other test cases I have now execute correctly.
>
> Cheers
> Reinhold
>
> > -Ursprüngliche Nachricht-
> > Von: Paul Richard Thomas
> > Gesendet: Sonntag, 14. April 2019 20:16
> > An: Thomas Koenig
> > Cc: Gilles Gouaillardet ; Ba
Hi Thomas,
Thanks a lot. Committed as revision 270353.
I was determined not to repeat the PDT experience, which is still
nagging at me. That has to be the next major gfc project, I guess.
Regards
Paul
On Sun, 14 Apr 2019 at 18:08, Thomas Koenig wrote:
>
> Hi Paul,
>
>
> > Please find
the element length.
On Fri, 12 Apr 2019 at 10:08, Paul Richard Thomas
wrote:
>
> Gilles & Reinhold,
>
> Following the discussion, I have decided to remove the copy-in for
> intent(in). Dominique and I have located the problem with -m32 for
> PR90022 and I am working on PR
Hi Thomas,
Thanks for your determination in dealing with this. It has been on my
TODO list for a long time but, like you at the outset, I had no idea
how to deal with it.
OK on the fortran side.
Paul
On Sat, 13 Apr 2019 at 19:48, Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch
gt;
> > Of more interest is the situation where the dummy argument in Fortran is
> > declared, e.g.,
> >
> > TYPE(*), ASYNCHRONOUS, INTENT(IN) :: BUF(..)
> >
> > The standard's semantics *forbids* performing copy-in/out in this case,
> > IIRC.
> > Otherwise
> >
s without failure for both -m32 and
> -m64.
>
> Dominique
>
> > Le 10 avr. 2019 à 00:42, Paul Richard Thomas
> > a écrit :
> >
> > Many thanks, sir! I will look into it.
> >
> > Paul
>
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Many thanks, sir! I will look into it.
Paul
On Tue, 9 Apr 2019 at 17:43, Dominique d'Humières wrote:
>
> Hi Paul,
>
> With your patch the test gfortran.dg/ISO_Fortran_binding_9.f90 fails in the
> 32 bit mode, due to the errors
>
>
The most part of this patch is concerned with implementing calls from
C of of fortran bind c procedures with assumed shape or assumed rank
dummies to completely fix PR89843. The conversion of the descriptors
from CFI to gfc occur on entry to and reversed on exit from the
procedure.
This patch is
Hi Dominique,
I discovered the same thing myself this morning. The patch was
developed on 8-branch because my working trunk had a hefty patch in an
intermediate state of development. I cleared it off,ready to do the
commit, and discovered the change on regtesting. I am trying to think
of a way in
: Additional source.
PR fortran/89842
* gfortran.dg/ISO_Fortran_binding_8.f90: New test.
* gfortran.dg/ISO_Fortran_binding_8.c: Additional source.
On Wed, 27 Mar 2019 at 18:55, Steve Kargl
wrote:
>
> On Wed, Mar 27, 2019 at 06:50:41PM +, Paul Richard Thomas wrote:
> > T
This patch is pretty self-explanatory. I have checked that a sensible
errors are given if 'exfunc' in the testcase is referenced if it is a
variable.
Bootstrapped and regtested on FC29/x86_64 - OK for trunk?
Paul
2019-03-30 Paul Thomas
PR fortran/87127
* resolve.c
This corrects a screw-up on my part. The attribute field of the CFI
descriptor must be set by the formal argument in the interface and not
the actual argument.
Most of the work was in correcting
Bootstrapped and regtested on FC29/x86_64 - OK for trunk?
Cheers
Paul
2019-03-27 Paul Thomas
Hi Reinhold,
Many thanks - the bug number is out by one on the last. Jakub Jelnik
got one in before it :-)
I'll take a look this afternoon.
Cheers
Paul
On Wed, 27 Mar 2019 at 10:25, Bader, Reinhold wrote:
>
> Dear Paul,
>
> Here are further bug reports, mostly on the various functions for
This one started with a simple enough testscase and then evolved as I
found out how little actually worked. All the changes in the patch
involve gathering up the string length by hook or by crook.
It will be noted that associate (y => x%d(:)(2:4)) still does not work
correctly. The associate name
Hi Thomas,
This is OK for trunk and, after a wee delay for the other active branches.
Thanks
Paul
On Fri, 22 Mar 2019 at 22:56, Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch fixes a 7/8/9 regression. The problem was twofold:
> If a subroutine was called more than once from a
The attached patch implements fixes for a couple of wrinkles with assumed rank:
(i) PR89363 flagged the fact that the rank was not be set for assumed
rank entities, associated with unallocated or unassociated arrays. The
fix is straightforward, the work being done by
Hi Thomas,
This is good for trunk.
Thanks
Paul
On Sun, 3 Mar 2019 at 09:46, Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch fixes a 7/8/9 regression by rejecting an invalid
> expression in coarray allocation that led to an ICE. It also adds a few
> more checks.
>
> One point
Hi Jakub,
Your timing is astonishing. This was next on my list of TODOs - not
for this particular PR but to deal with the rodata bloat eg. 84487. I
presume that this patch will make the latter go away?
Yes, this is good for trunk and, if it fixes 84487, 8-branch as well.
Thanks
Paul
On Mon,
Hi Thomas,
> Of course, there could also be a more profound way of fixing this
> bug :-)
I wish that it were the case. I am unable to decide whether the design
choices made for an F95 compiler have cause the add-ons to be
intrinsically complicated or whether or whether F2018, extensions and
This one was sufficiently 'obvious' that not only has it been
committed to 9-branch but to 7- and 8-branches as well.
Although the choking gimplifier was a regression, the testcase never
worked on any branch because resolve.c:deferred_op_assign should
always have returned false for pointer
Hi Thomas,
That's just the job. OK for trunk.
Thanks for the quick fix.
Paul
On Mon, 18 Feb 2019 at 22:03, Thomas Koenig wrote:
>
> Hello world,
>
> this patch fixes the 9 regression in C interop with contiguous
> arguments recently reported by Reinhold Bader.
>
> ChangeLog and patch say it
OK. Thanks for the patch.
Paul
On Wed, 6 Feb 2019 at 20:27, Thomas Koenig wrote:
>
> Hello world,
>
> this patch fixes a 7/8/9 regression where we tried to accept invalid
> code, which led to an ICE later on.
>
> The patch is rather straightforward. The reason why I could not
> use
Committed as 'obvious' in revision 268721 after bootstrapping and regtesting.
Even if not entirely obvious to the world at large, the patch is, in
the words of Hitch Hikers Guide to the Galaxy, "mostly harmless".
To explain the 'obviousness': Array and structure constructors make
use of
Hi Harald,
After nearly 12 years, I have been found out!
OK for trunk. Since it has been such a long time, I suggest that you
limit your backporting efforts to 8-branch and, at the most, 7-branch.
Will you attempt to tackle the other issues in the PR?
Thanks
Paul
On Sun, 3 Feb 2019 at 21:04,
OK - thanks for the patch.
Paul
On Sat, 2 Feb 2019 at 14:41, Thomas Koenig wrote:
>
> Hi,
>
> the attached patch fixes a 7/8/9 regression where a conversion warning
> was emitted for DIM. The problem was that the no-warn flag had not been
> passed down to the arithmetic conversion routines,
Unfortunately, it doesn't. I have taken it though since it should
pretty low hanging fruit.
Cheers
Paul
On Fri, 1 Feb 2019 at 19:31, Steve Kargl
wrote:
>
> On Fri, Feb 01, 2019 at 06:15:21PM +, Paul Richard Thomas wrote:
> > I will commit this patch as 'obvious' tomorrow.
&g
Hi Steve,
> taking taking
>
OK OK
> > Index: gcc/fortran/trans-expr.c
> > ===
> > *** gcc/fortran/trans-expr.c (revision 268231)
> > --- gcc/fortran/trans-expr.c (working copy)
> > *** gfc_conv_procedure_call (gfc_se
I will commit this patch as 'obvious' tomorrow.
Cheers
Paul
2019-02-01 Paul Thomas
PR fortran/88393
* trans-expr.c (gfc_conv_procedure_call): For derived entities,
passed in parentheses to class formals, invert the order of
copying allocatable components to taking taking the
This patch is rather simpler than it looks.
The segfault was occurring because r264724 changed the array reference
for cases like these to use pointer arithmetic to obtain the element.
Unfortunately, in the case, the span field of the descriptor was not
being set during the allocation of the
Sorry about the premature 'send'.
This one is more or less obvious and is described in the ChangeLog.
The key point is that full or section array references to intrinsic
components were returning a false true from expr.c (is_subref_array).
Returning false if a component is intrinsic and following
This one is more or less obvious and is described in the ChangeLog.
The key point is that full or section array references to intrinsic
components were returning a false true from expr.c (is_subref_array).
Returning false if a component is intrinsic and following anything
other than an array
Hi Steve,
That's OK. Thanks
Paul
On Fri, 25 Jan 2019 at 01:50, Steve Kargl
wrote:
>
> All,
>
> My original patch for this PR simply fixed an ICE, which
> then allowed the code to compile. In reality, an alternate
> return is not ISO C interoperable, so an error message is
> a more appropriate
Hi Steve,
Fixed in revision 268231.
This was a copy/paste/modify with the type built in. Have corrected both.
> > tree
> > + gfc_conv_descriptor_elem_len (tree desc)
> > + {
> > + tree tmp;
> > + tree dtype;
> > +
> > + dtype = gfc_conv_descriptor_dtype (desc);
> > + tmp =
The attached patch allows MPICH 3.2 to build correctly and to test successfully.
Two problems were addressed:
(i) The original implementation of ISO_Fortran_binding did not take
account of the possibility that assumed rank/assumed type arrays could
be passed as dummy arguments. This necessitated
Hi everybody,
I have done the minimum to make the testsuite failures to go
away(thanks, Jakub) and to fix the first (offline) reported bug.
Committed as r267946.
As to the location of ISO_Fortran_binding_2.h, I am open to proposed
fixes. Thomas kindly engineered that part of the original patch
Done as revision 267884.
Thanks again.
Paul
On Sat, 12 Jan 2019 at 18:29, Paul Richard Thomas
wrote:
>
> Hi Steve,
>
> Many thanks for the heads up. I had seen similar problems with the the
> second testcase and I thought that I had fixed them. I will delete
> them from th
Jan 12, 2019 at 09:10:27AM -0800, Steve Kargl wrote:
> > On Sat, Jan 12, 2019 at 03:28:02PM +, Paul Richard Thomas wrote:
> > > Hi Thomas,
> > >
> > > Committed as revision 267881. I removed the duplicate include file and
> > > added some documentatio
Hi Thomas,
Committed as revision 267881. I removed the duplicate include file and
added some documentation, as suggested.
Many thanks for all the help
Paul
On Tue, 8 Jan 2019 at 23:19, Thomas Koenig wrote:
>
> Hi Paul,
>
> > This is an updated version of the earlier patch. The main addition
Hi Steve,
This is OK for trunk.
Thanks
Paul
On Sat, 12 Jan 2019 at 04:34, Steve Kargl
wrote:
>
> The attached patch has been tested on x86_64-*-freebsd. There
> were no regression. The patch is less then obvious, but simple.
> OK to commit?
>
> 2019-01-11 Steven G. Kargl
>
> PR
Hi Steve,
Yes, that's good for trunk.
Thanks
Paul
On Fri, 11 Jan 2019 at 01:16, Steve Kargl
wrote:
>
> An entry-name obtains the elemental attribute from its containing
> procedure. F2018:C1546 prohibits an procedure from having a BIND(C)
> attribute. BIND(C) can appear on the entry-stmt
Hi Thomas,
Aaaah! Light bulb moment - I was looking in the $PREFIX/include directory.
For whatever reason, mine does not appear in lib64 but in lib. OK,
that will have to do for now because the patch is blocking my tree for
a number of other things. I'll fix Bernhard's nit and commit on
Hi Thomas,
> Is there any particular reason why you do not want to use
>
> ! { dg-additional-options "-I $srcdir/../../libgfortran" }
>
> in the test cases, and have it only once in the source trees?
I will make it so. Thanks for the reminder.
>
> However, I have no real strong opinion on this
I will apply this as 'obvious' this evening, unless there are
objections. The patch is entirely self-explanatory.
Paul
2018-12-23 Paul Thomas
PR fortran/77703
* resolve.c (get_temp_from_expr): Use the string length of
constant character expressions.
2018-12-23 Paul Thomas
Hi Thomas,
That's OK for 7- through 9-branches.
Thanks for the fix.
Paul
On Sun, 16 Dec 2018 at 22:01, Thomas Koenig wrote:
>
> Hello world,
>
> the PR pointed out an old regression because the front-end optimization
> pass was substituting 2**n with ishift(1,n), where n was an array.
>
>
Applied as 'obvious' after regtesting on FC28/x86_64.
The second part of the patch (in simplify_ref_chain) is due to Jakub,
for which many thanks. The first is consequent on the need to deal
with more than one inquiry part ref (see the testcase) and yet be able
to return true from
The attached is an implementation of ISO_Fortran_binding. Please note
that the ChangeLogs contain no mention of the changes that appear in
the configure files on building in maintainer mode.
The patch only couples to assumed rank and assumed shape formal
arguments of bind_c procedures, via
Hi All,
Forget my remark about mp_prop_design.f90. ifort -parallel means just
that and has nothing to do with vectorization.
Sorry for the noise.
Paul
On Sat, 17 Nov 2018 at 13:29, Paul Richard Thomas
wrote:
>
> Hi All,
>
> I took a few moments away from what I really must be doin
Hi Thomas,
OK for trunk.
Thanks for working on it.
Paul
On Sat, 17 Nov 2018 at 15:10, Thomas Koenig wrote:
>
> Hi,
>
> > the attached patch fixes both ICEs in the PR by adding some tests.
> > It was necessary to shuffle around a bit of code, plus to make sure that
> > double error reporting
Hi All,
I took a few moments away from what I really must be doing to try out
an earlier version of the patch. There are quite a few CRs in the
patch and the third chunk in gcc.c was rejected, although I cannot see
why. I made a change to scanner.c to prevent the segfault that results
from not
Hi Thomas,
I tried failing cases of that kind; or assignment to len/kind part refs and
returned correct errors. Must check where I was going wrong.
Paul from a chilly Garching-bei-Muenchen
On Sun, 28 Oct 2018, 13:38 Thomas Koenig Hi Paul,
>
>
> >> inq would be easier to understand and
Hi Thomas,
Thanks for finding the assignment a%len = 2 that escapes the check for
lvalues. I am back home tomorrow night and will investigate why this
one evades the trap. I think that an error test is needed in
expr.c(gfc_check_assign).
Cheers
Paul
On Sun, 28 Oct 2018 at 13:38, Thomas Koenig
Hi Bernhard,
Thanks for going through the patch:
snip
> missing space before open parenthesis
Corrected.
snip
> inq would be easier to understand and unambiguous imho.
Why? inquiry_type seems fine to me.
snip
> Is the switch really worth it? I'd have used a plain chain
Hi Thomas,
The patch is ready to go. Please correct the following tiny nits:
s/Check that en expression/Check that an expression/
s/Set this if resolution has already happened and it could be
harmful/Set this if resolution has already happened. It could be
harmful/
An even tinier, probably
I was triggered to do this by one of the comments in response to Anton
Shterenlikht's standards survey. The comment was sufficiently
inconsiderate that my first thought was not to respond. However,
curiosity got the better of me... so said the dead cat!
There is a lot of this patch but it is
Committed as revision 265353.
> Not quite fixed. The lhs character length doesn't get set and so it
> fails at runtime. I will commit the patch as 'obvious'.
>
> Paul
>
> 2018-10-19 Paul Thomas
>
> PR fortran/71880
> * trans-expr.c (gfc_trans_pointer_assignment): Set the string
>
space issues.
2018-10-18 Paul Thomas
PR fortran/85603
* gfortran.dg/deferred_character_23.f90 : Check reallocation is
occurring as it should and a regression caused by version 1 of
this patch.
On Sat, 20 Oct 2018 at 13:32, Paul Richard Thomas
wrote:
>
> Hi Dominique,
>
Hi Dominique,
Thanks for picking that up. For some reason that I do now see, the
regression is caused by the component references. The frontend
temporary is picking up the deferred tag from somewhere, even though
it is not set. Anyway, all is well if the patch is restricted to
character right
Your patch at: https://gcc.gnu.org/ml/fortran/2018-10/msg00079.html is
OK for trunk.
Thanks
Paul
string lengths.
Clean up some white space issues.
2018-10-18 Paul Thomas
PR fortran/85603
* gfortran.dg/deferred_character_23.f90 : Check reallocation is
occurring as it should..
On Sat, 22 Sep 2018 at 11:23, Paul Richard Thomas
wrote:
>
> Yet another 'obvious' deferred cha
Patch for the PR70149 regression committed as revision 265263.
Likewise the patch for PR58618 has been committed as revision 265264.
Cheers
Paul
On Wed, 17 Oct 2018 at 22:17, Tobias Burnus wrote:
>
> Hi Paul,
>
> Paul Richard Thomas wrote:
> > This problem concerned assoc
.
Paul
On Wed, 17 Oct 2018 at 22:17, Tobias Burnus wrote:
>
> Hi Paul,
>
> Paul Richard Thomas wrote:
> > This problem concerned associate targets being substrings. It turns
> > out that they are returned as pointer types (with a different cast for
> > unity based
Hi Tobias,
Thanks for taking care of that so quickly. Juergen is proving to be a
loyal friend to gfortran by coming back to us so quickly on
regressions and reducing testcases. He deserves a good service.
Cheers
Paul
On Wed, 17 Oct 2018 at 20:59, Tobias Burnus wrote:
>
> Due to using the
This problem concerned associate targets being substrings. It turns
out that they are returned as pointer types (with a different cast for
unity based substrings ***sigh***) and so can be assigned directly to
the associate name. The patch quite simply removed the condition that
such targets be
This is a semi-obvious patch that fixes no fewer than five PRs: 56386,
58906, 77385, 80260 & 82077. The last two are marked as 7/8/9
regressions and so, although I haven't tested it yet, I suppose that
the others must be too. Thanks to Dominique for picking up the other
four PRs that are fixed by
Hi Tobias,
Following our exchange off-list, I rather agree with you that a
testcase is pointless. Besides which, I do not see this regressing :-)
OK for trunk and, if you are feeling strong, 8-branch.
Thanks and welcome back.
Paul
On Mon, 15 Oct 2018 at 20:46, Tobias Burnus wrote:
>
> as the
Hi Tobias,
Your patch is OK for trunk and, I would suggest 8-branch.
As a matter of curiosity, why did you not use the condition:
if (!(expr3_desc && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (expr3_desc))) ?
Your solution is fine, though.
Cheers
Paul
On Fri, 12 Oct 2018 at 12:29, Tobias Burnus
Committed as revision 265171.
Thanks to you, Dominique and, of course, Tobias.
Paul
On Mon, 15 Oct 2018 at 10:15, Thomas Koenig wrote:
>
> Hi Paul,
>
> > Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
>
> Looks good. Thanks!
>
> Regards
>
> Thomas
--
"If you can't
Tobias started this patch and I finished it in answering a question
that he had about a problem with the gimplifier. Along the way, I
tried the associate version of the select type test case and found
that it failed in a different way. The chunk in resolve_assoc_var
fixes that.
Bootstrapped and
Hi Tobias,
This is OK.
Thanks for the patch and the extra careful regtesting :-)
Paul
On Fri, 12 Oct 2018 at 00:17, Tobias Burnus wrote:
>
> Next patch, next try …
>
> The problem is the following: We have a use-associated symbol (a
> function) – which is once referenced (by use association).
nsion or how other Fortran compilers behave.
>
> GNU Fortran probably should be compatible with other Fortran
> compilers, even if the behavior is not pedantically conformant with
> the standard.
>
> Thanks, David
>
> On Wed, Oct 10, 2018 at 7:12 PM Paul Richard Thomas
> w
This seems to have caused errors in the testsuite. I guess that the
problem is that the testcases are invalid :-(
>From David Edelsohn:
Error: Substring reference of nonscalar not permitted at (1)
arrayio_11.f90
arrayio_12.f90
associate_23.f90
data_char_1.f90
deferred_character_2.f90
Hi Dominique,
Thanks for the testing. Although the tests for PR80931 and PR83196,
comment #4, compiled OK, when I attempted to use the modules both
segfaulted for the same reason ('span' not being set on the array
descriptor) and these required a slightly different version of the
same tweak.
The
I have fixed this as 'obvious' on 8-branch(r264925) and trunk(r264915).
Paul
2018-10-08 Paul Thomas
Backport from trunk
PR fortran/86372
* trans-stmt.c (trans_associate_var): Character associate names
with variable string length do not have to be deferred length
for the
This turned out to be rather more than the allocation... The ChangeLog
and the patch tell the story well enough.
Bootstraps and regtests on FC28/x86_64 - OK for trunk and later for 8-branch?
Cheers
Paul
2018-10-07 Paul Thomas
PR fortran/87151
* trans-array.c (gfc_get_array_span):
After testing by Dominique and Juergen. Committed as revision 264725.
Thanks to Dominique and juergen for doing all the hard work!
Cheers
Paul
2018-09-30 Paul Thomas
PR fortran/87359
* trans-array.c (gfc_is_reallocatable_lhs): Correct the problem
introduced by r264358, which
ran.dg/deferred_character_26.f90 : New test.
* gfortran.dg/deferred_character_27.f90 : New test to verify
that PR82617 remains fixed.
On Sun, 30 Sep 2018 at 09:02, Paul Richard Thomas
wrote:
>
> Hi Dominique,
>
> It's the patch for pr70752 that causes the trouble, which I
Hi Dominique,
It's the patch for pr70752 that causes the trouble, which I had
guessed from the point in trans.c where the ICE occurs. I am onto it.
Thanks again
Paul
On Wed, 26 Sep 2018 at 16:52, Dominique d'Humières wrote:
>
> > Is se->string_length guaranteed to be of type
Hi Dominique,
Thanks for the heads up - I will check it out and fix it next week
before doing any commits.
Cheers
Paul
On 26 September 2018 at 16:52, Dominique d'Humières wrote:
>> Is se->string_length guaranteed to be of type gfc_array_index_type_here?
>> If so, why? And if not, maybe a
301 - 400 of 1166 matches
Mail list logo
