Hi Steve,
In the F2018 standard: C1550 (R1526) If MODULE appears in the prefix
of a module subprogram and a binding label is specified, it
shall be the same as the binding label specified in the corresponding
module procedure interface body.
While it does not say explicitly that a repeat binding
Hi Steve,
As I remarked on the PR thread, it is one of the less harmful bits of
code that I introduced :-)
OK to commit.
Thanks
Paul
On Sat, 12 Oct 2019 at 01:17, Steve Kargl
wrote:
>
> The patch is fairly self-explanatory. OK to commit?
>
> 2019-10-11 Steven G. Kargl
>
> PR fortr
Hi Christophe,
Thanks for flagging this up - I am back at base on Saturday and will
take it up then.
Regards
Paul
On Wed, 9 Oct 2019 at 11:13, Christophe Lyon wrote:
>
> Hi,
>
>
> On Sat, 5 Oct 2019 at 20:31, Paul Richard Thomas
> wrote:
>>
>> I must apo
I must apologise not posting this before committing. I left for a
vacation this morning and I thought that this problem and the one
posted by Gilles were best fixed before departing. The patch only
touches the new ISO_Fortran binding feature and so I thought that I
would be safe to do this.
It was
Fixed as obvious in revision: 276051.
The patch is largely due to Steve, for which thanks.
Paul
2019-09-23 Paul Thomas
PR fortran/91729
* match.c (gfc_match_select_rank): Initialise 'as' to NULL.
Check for a symtree in the selector expression before trying to
assign a value t
Fixing the original problem in the module took a few minutes. Making
the module do something useful took rather longer! The testcase in the
patch compiles with 6-branch but segfaults in runtime.
Bootstrapped and regtested on FC30/x86_64 - OK to commit and go
steadily back through the branches over
Hi Sandro,
This patch looks fine to me. I have a question about the comment:
"This code is obviously added because the finalizer is not trusted to
free all memory."
'obviously'? Not to me :-( Maybe you can expand on this?
As to the stat and errmsg: Leave them for the time being. However, an
attem
The attached bootstraps and regtests on FC30/x86_64 - OK for trunk?
It strikes me that this should be backported since the bug is rather
fundamental and ispresent all the way back to version 4.8. An obvious
question is how far back? To 8-branch?
Cheers
Paul
2019-09-15 Paul Thomas
PR for
Thanks - committed as r275696.
Paul
On Thu, 12 Sep 2019 at 15:09, Steve Kargl
wrote:
>
> On Thu, Sep 12, 2019 at 09:55:20AM +0100, Paul Richard Thomas wrote:
> >
> > OK to commit?
> >
>
> Yes.
>
> --
> Steve
--
"If you can't explain it simp
Committed as 'obvious' in revision 275681:
2019-09-12 Paul Thomas
PR fortran/91686
Backport from mainline
* trans-expr.c (gfc_trans_assignment_1): Copy and paste section
handling the rse.pre block from mainline.
2019-09-12 Paul Thomas
PR fortran/91686
* gfortran.dg
eturning 1 from gfc_dep_resolver covers this case.
OK to commit?
Cheers
Paul
realloc_string_callback)
On Thu, 12 Sep 2019 at 00:05, Steve Kargl
wrote:
>
> On Wed, Sep 11, 2019 at 11:27:56PM +0100, Paul Richard Thomas wrote:
> > Hi Steve,
> >
> > Being an allocatable component
, Paul Richard Thomas wrote:
> > ===
> > *** gcc/testsuite/gfortran.dg/dependency_55.f90 (nonexistent)
> > --- gcc/testsuite/gfortran.dg/dependency_55.f90 (working copy)
> > ***
> > *** 0
Hi All,
I nearly committed this patch as 'obvious' but noticed a fair number
of changes in 10-branch in dependency analysis. This is in fact a
10-regression. I'll wait for an OK.
Bootstrapped and regtested on FC30/x86_64 - OK to commit?
Paul
2019-09-11 Paul Thomas
PR fortran/91717
*
This was caused by my inquiry ref patch.
I will commit to both branches tomorrow night unless there is an objection.
Bootstraps and regtests on FC29/x86_64.
Paul
2019-09-02 Paul Thomas
PR fortran/91589
* primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
component ref
Hi Steve,
OK to commit.
Thanks
Paul
On Sat, 31 Aug 2019 at 21:16, Steve Kargl
wrote:
>
> The attached patch has been built and tested on i586-*-freebsd
> and x86_64-*-freebsd. OK to commit?
>
> The patch fixes an ICE during type conversion where an array
> constructor contains another array.
Hi Steve,
Thanks for the remarks and the OK. Committed as revision 275269.
Onward to PDTs!
Cheers
Paul
On Sat, 31 Aug 2019 at 18:46, Steve Kargl
wrote:
>
> On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote:
> >
> > Bootstraps and regtests on FC29/x86
Hi Steve,
> > > If an error occurs, should this set m = MATCH_ERROR and goto cleanup?
> > > OR, set m = MATCH_ERROR, free expr1 and expr2 and return m?
> > > IOW, if an error occurs, why should gfortran continue to match select
> > > rank?
This prevents or reduces the deluge of errors that come
When I started on this about three months ago, I thought that with
SELECT TYPE as a template this was going to be low hanging fruit. Not
so :-)
Among the issues on the way were: class selectors; unlimited
polymorphic selectors even more so; and error recovery. It's a good
starting point but I am n
Hi Harald,
This is OK for trunk.
Thanks!
Paul
On Mon, 26 Aug 2019 at 22:13, Harald Anlauf wrote:
>
> Dear all,
>
> the attached patch adds Fortran support for the following pragmas
> (loop annotations): IVDEP (ignore vector dependencies), VECTOR, and
> NOVECTOR. Furthermore, it downgrades uns
Hi Thomas,
Yes that's good to apply to 9 and 10 branches. I am certain that there
are other places where the new function will be very helpful.
Thanks for the patch.
Paul
On Tue, 13 Aug 2019 at 13:59, Thomas König wrote:
>
> Hello world,
>
> this patch fixes a 9/10 regression by placing the va
Hi Steve,
Who thought of that one in the standard? Uuugh!
The solution looks good to commit - again as far back as you feel
inclined to do.
Regards
Paul
On Tue, 6 Aug 2019 at 19:27, Steve Kargl
wrote:
>
> Ping.
>
> On Thu, Aug 01, 2019 at 02:11:39PM -0700, Steve Kargl wrote:
> > The attached
Hi Steve,
That certainly does the trick! OK to commit as far back as you have
the intestinal fortitude for.
Thanks
Paul
On Tue, 6 Aug 2019 at 19:24, Steve Kargl
wrote:
>
> The spaghetti code in PR fortran/91359 has a few gotos
> to jump to different places. In doing so, gfortran
> with genera
Hi Steve,
This is OK.
Thanks for working on it.
Paul
On Thu, 1 Aug 2019 at 22:13, Steve Kargl
wrote:
>
> Ping.
>
> --
> steve
>
> On Sun, Jul 28, 2019 at 04:41:02PM -0700, Steve Kargl wrote:
> > The attach patch fixes a problem with the conversion of a
> > BOZ literal constant to a REAL where
Hi Thomas,
That is very well done. Thanks for picking it up and running with it.
OK on both the fix and the dumping of the gsymbols.
You might consider back porting both this patch and my fix for the
original bug to 9-branch.
Regards
Paul
On Sun, 28 Jul 2019 at 22:50, Thomas Koenig wrote:
>
>
Hi Harald and Steve,
The patch looks fine to me - it's good be committed.
Thanks
Paul
On Mon, 15 Jul 2019 at 03:34, Steve Kargl
wrote:
>
> Harald, thanks for the patch. I'm that the best person
> for reading the trans-* file, but your patch and changes
> look good to me. If no one else speak
Thanks, Steve.
Fixed with revisions 273176, 7 & 8.
Paul
On Sat, 6 Jul 2019 at 18:05, Steve Kargl
wrote:
>
> On Sat, Jul 06, 2019 at 02:29:06PM +0100, Paul Richard Thomas wrote:
> > As anticipated, 8-branch required a different patch but the difference
> > was much sm
gave symbol backend decl for subref arrays.
2019-07-06 Paul Thomas
PR fortran/91077
* gfortran.dg/pointer_array_11.f90 : New test.
On Sat, 6 Jul 2019 at 11:48, Paul Richard Thomas
wrote:
>
> This problem was caused by the code for scalarized array references to
> subref a
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 p
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 do
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 x86_64-*-f
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 has
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 t
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 v
CC computer farm 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
> &g
nks Paul 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
> > > pr
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 (pointer_assignme
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 Thomas
>
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
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: gfortran.dg/iso_
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 could not
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 poin
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 optim
>
> > 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 Burnus in
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 com
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 attached
r than 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
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 fix
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
>
ecutes 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
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_9.f9
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 s
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
inding_7.c: 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 +0000, Paul Richard Thomas wrote:
&
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 (check_host_associa
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 man
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 di
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
trans-expr.c(set_dtype_for_unal
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 that
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, 25
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
legac
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 express
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 al
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 gfc_expr_att
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 temporary
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, whi
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
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 compo
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 elemen
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 = gfc_advance_c
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 t
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 si
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 documentation, a
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 is
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 f
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 lin
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
Saturday.
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 m
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.
>
> Sim
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 simplify_ref_cha
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
trans-e
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 di
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 hav
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 unambigu
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
301 - 400 of 1217 matches
Mail list logo
