Hi Tobias,
The patch looks fine to me. OK for 10- and 11-branches. I am not convinced
that a delay is needed for the backport.
Thanks
Paul
On Thu, 11 Mar 2021 at 18:19, Tobias Burnus wrote:
> This fixes an ICE with OpenMP 'omp decare simd' but is a generic bug.
>
> Namely TREE_TYPE(fndecl) h
:
> Hi Paul, hi all fortran@/gcc-patch@ reader,
>
> it looks as if you replied with your patch submission to the wrong email
> address – and your re-submission ended up at
> https://gcc.gnu.org/PR99602#c17
>
> On 16.03.21 18:08, Tobias Burnus wrote:
> > On 16.03.21 17:42,
Hi Everybody,
Although this is 'obvious' I thought that I should post it because I
believe that it was triggered by the fix for PR99602 but I just do not have
the bandwidth at the moment to test that. The ChangeLog together with the
patch is more than sufficient explanation.
Regtests OK on FC33/x
Applied to all three branches, after regtesting on each, as blindingly
obvious. The testcase is the reduced version in comment #6 of the PR.
Paul
Fortran: Fix problem with allocate initialization [PR99545].
2021-03-15 Paul Thomas
gcc/fortran/ChangeLog
PR fortran/99545
* trans-stmt.c (gfc_tr
Hi Harald,
I am not sure of the etiquette for this - it looks OK to me :-)
Cheers
Paul
On Fri, 12 Mar 2021 at 21:20, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the addition of runtime checks for the SIZE intrinsic created a regression
> that showed up for certain CLASS arguments to pro
This problem was caused by the compiler attempting to use 0 as an lvalue
and to assign 0 to it. Understandably, this upset the gimplifer quite a bit
:-) The fix is to use the ss_info string length for deferred length
character components, where the hidden string length component has been
used. The
Hi Tobias,
→ Can you add also a testcase that which triggers the error message you
> see in the unpatched class_assign_4.f90?
> > I was unable to find a way to use a typebound operator with a polymorphic
> > result
> I am confused – the attach testcase does seem to work fine with current
> GCC.
Hi All,
This is a straightforward fix that had the side-effect of uncovering an
invalid testcase, class_assign_4.f90. I had worked up a new test, based on
the one in the PR, and found that another brand determined that it is
invalid according to F2018, C15100.
I was unable to find a way to use a
Hi Harald,
It looks 'obvious' to me too and is certainly OK for master.
Thanks
Paul
On Thu, 18 Feb 2021 at 21:30, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the PR reports an issue detected with an ASAN instrumented compiler,
> which can also be verified with valgrind. It appears that
Hi Tobias,
I think that constitutes an 'obvious' patch. OK for mainline.
Thanks
Paul
On Mon, 8 Feb 2021 at 18:53, Tobias Burnus wrote:
> Found when looking at Julian's 3/4 OpenACC patch, which has not
> yet been committed (and needs still to be revised a bit.)
>
> The fix (a) avoids an ICE w
Hi Tobias,
The fix and the message are just fine for me. I am trying to imagine how
few people will ever encounter this!
OK for 10- and 11-branches
Thanks
Paul
On Tue, 16 Feb 2021 at 11:28, Tobias Burnus wrote:
> GCC started to accept as legacy extension array-valued
> non-characters, which
re invalid because of:
>
> C1105 (R1105) expr shall not be a designator of a procedure pointer
> or a function reference that returns a procedure pointer.
>
> However:
>
> On 02.02.21 16:05, Paul Richard Thomas via Fortran wrote:
>
> > In foo.f90, if
Hi Tobias,
The patch is good for 10- and 11-branches.
Thanks
Paul
On Thu, 11 Feb 2021 at 18:59, Tobias Burnus wrote:
> In the Fortran standard, I think it is best explained
> in the description of the RANK intrinsic:
>
> "Example. If X is an assumed-rank dummy argument and
> its associated e
Thanks to Steve for an 'obvious' patch for this one. It is fixed on all
three branches.
Paul
Paul
On Tue, 2 Feb 2021 at 13:59, Tobias Burnus wrote:
> Hi Paul,
>
> On 02.02.21 13:20, Paul Richard Thomas via Gcc-patches wrote:
> > This is more or less 'obvious' and does not require any further
> explanation.
>
> Well, I am not sure whether calling resolv
This is more or less 'obvious' and does not require any further explanation.
Regtests with FC33/x86_64 - OK for master (and )?
Paul
Fortran: Fix calls to associate name typebound subroutines [PR98897].
2021-02-02 Paul Thomas
gcc/fortran
PR fortran/98897
* match.c (gfc_match_call): Inclu
9 Jan 2021 at 14:56, Tobias Burnus wrote:
> Hi Paul,
>
> On 29.01.21 15:20, Paul Richard Thomas via Fortran wrote:
> > Regtests on FC33/x86_64
> > OK for master (and maybe for 10-branch?)
>
> The patch by itself looks good to me, but
>
> gfortran-trunk assumed_rank_
without breaking something else. That said, this version of the problem
might be easier than most. I will take a look.
Cheers
Paul
On Fri, 29 Jan 2021 at 14:56, Tobias Burnus wrote:
> Hi Paul,
>
> On 29.01.21 15:20, Paul Richard Thomas via Fortran wrote:
> > Regtests on FC33/x8
Fixing the different variants of this PR was somewhat like drawing teeth.
Fixing the scalar problem with derived type and class formal arguments was
straightforward. However, the need to strip NOPS for scalar unlimited
polymorphic arguments was less than obvious. Even less obvious was the
problem w
This patch fixes PRs 93924/5. It is another 'obvious' patch, whose
consequences are very limited.
I am trying to slip in as many small ready-to-go patches as I can before we
go too far into stage 4. It would be nice to have the patch for PR98573
(posted 23rd Jan) OK'd before the end of the week.
I have applied another obvious patch to fix this PR. It was tempting to
remove both gcc-asserts but I have erred on the side of caution this time.
Commit r11-6924-g003f0414291d595d2126e6d2e24b281f38f3448f
Again, it is sufficiently safe and obvious that I am tempted to put it on
my list of backpor
Hi All,
Fixed as 'blindingly obvious' on 9-, 10- and 11-branches, using Steve's
patch.
Even if it doesn't fix anything, the patch is totally safe :-)
Paul
Fortran: Fix deferred character lengths in array constructors [PR98517].
2021-01-25 Steve Kargl
gcc/fortran
PR fortran/98517
* resolve.
This is a relatively obvious patch. The chunk in trans-array.c is not part
of the fix for the PR but does suppress some of the bad dtype's that arise
from allocation of class objects. The part in trans-stmt.c provides vptrs
for all class allocations if the expression3 is available.
Regtests on FC3
Fixed as 'obviously correct' as
r11-6863-gbf8ee9e4eed6ba1a6d77b4cf168df480e1f954da
The _data component was preventing the detection of the procedure pointer
component and the conversion of the function. Once diagnosed, the fix is
obvious.
Regtested on FC33/x86_64 - OK in a few weeks for 9- and 10
Hi Harald,
It looks OK to me. I can see why you are asking about the implementation
but cannot offer a better solution.
OK for master.
Thanks
Paul
On Tue, 12 Jan 2021 at 22:03, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> when playing around with the issues exposed by PR93340, particula
Hi Harald,
That's OK for master.
Thanks
Paul
On Wed, 13 Jan 2021 at 21:25, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the former Fortran testcase charlen_03.f90, which some time ago used to
> ICE, could still display issues during error recovery. As Dominique
> pointed out, this requi
Hi All,
This patch was triggered by a thread on clf. Some years ago Tobias and I
discussed the remaining conditions where finalization should be triggered
and is not. Intrinsic assignment was one of the glaring omissions for which
implementation looked like a heavy lift job. As it happens, it wasn
Hi Harald,
It looks good to me - OK for master and backporting.
Thanks
Paul
On Fri, 1 Jan 2021 at 16:14, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> happy New Year!
>
> The testcase committed with the fix for PR93337 uncovered a latent issue
> with an invalid read that was discovered wi
Hi Thomas,
Thanks - applied to master in
r11-6365-geeb145317b42d5203056851435457d9189a7303d .
I wonder if this one deserves backporting?
Cheers
Paul
On Tue, 29 Dec 2020 at 09:06, Thomas Koenig wrote:
>
> Hi Paul,
>
> > Regtests on FC33/x86_64 - OK for master?
>
> OK. Thanks for the patch!
Hi Thomas,
Thanks for taking a look at the patch. Applied to master as
r11-6364-gfeae0af82753e06fbff6103da5fbb3b28e1ddbd7 .
The branches will follow in a week or so.
Regards
Paul
On Mon, 28 Dec 2020 at 17:10, Thomas Koenig wrote:
> Hi Paul,
>
> >>
> > Retested on FC33/x86_64 - OK for master
Hi All,
Another one bites the dust! The patch is commented such that it is
self-explanatory.
Regtests on FC33/x86_64 - OK for master?
Paul
Fortran: Correct missing structure constructor comps. [PR97612].
2020-12-27 Paul Thomas
gcc/fortran
PR fortran/97612
* primary.c (build_actual_construc
Hi All,
I am in the midst of an end-of-year tidy up and found this:
On Wed, 1 Apr 2020 at 18:07, Fritz Reese wrote:
> Unfortunately the mailing list stripped off this attachment so we do
> not have a chance to review. As attachments appear to be working
> lately, please resubmit this patch.
>
>
Hi Thomas,
Thanks for the OK. Pushed as to master as commit
r11-6346-gc4a678981572c12d158709ace0d3f23dd04cf217
Cheers
Paul
On Sat, 26 Dec 2020 at 19:01, Thomas Koenig wrote:
> Hi Paul,
>
> > Ping!
>
> OK.
>
> Thanks a lot!
>
> Best regards
>
> Thomas
>
--
"If you can't explain it
Ping!
On Sat, 12 Dec 2020 at 10:38, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Fortran: Fix some select rank issues [PR97694 and 97723].
>
> Hi All,
>
> Unlike select type, select rank selectors retain the allocatable
> attribute. This is corrected
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Paul
2020-12-12 Paul Thomas
gcc/fortran
PR fortran/98022
* data.c (gfc_assign_data_value): Handle inquiry references in
the data statement object list.
gc
Fortran: Fix some select rank issues [PR97694 and 97723].
Hi All,
Unlike select type, select rank selectors retain the allocatable attribute.
This is corrected by the chunk in check.c. Note the trailing whitespace
corrections. Resolution of select rank construct must be done in the same
way as se
Hi Thomas,
Yes, it did grow into a bit of a monster patch. I kept noticing rather
flakey bits of existing code, especially where matching of dtype element
lengths to the actual payload was concerned.
Waiting for the others to comment gives me a chance to write a more
comprehensive testcase for th
Hi Everyone,
I am afraid that this is a rather long sad story, mainly due to my efforts
with gfortran being interrupted by daytime work. I posted the first version
of the patch nearly a year ago but this was derailed by Tobias's question
at: https://gcc.gnu.org/legacy-ml/fortran/2019-11/msg00098.h
Hi Richi,
That's OK for master and as far back as you have the fortitude to go.
Thanks for the fix.
I agree that we should always pick up a canonical variant. When I finally
get "a minute or two" to fix the rather fundamental problems with PDTs, I
will make sure that this goes away. I am also cu
Hi Tobias,
That looks to be the best that can be done with a sensible amount of
effort. OK by me.
Regards
Paul
On Mon, 2 Nov 2020 at 19:09, Tobias Burnus wrote:
> This adds the Fortran equivalent to __attribute__((deprecated)),
> except that "deprecated(message)" is not supported and that on
Ping!
On Thu, 29 Oct 2020 at 15:59, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Everyone,
>
> I am afraid that this is a rather long sad story, mainly due to my efforts
> with gfortran being interrupted by daytime work. I posted the first version
> of th
Hi Everyone,
I am afraid that this is a rather long sad story, mainly due to my efforts
with gfortran being interrupted by daytime work. I posted the first version
of the patch nearly a year ago but this was derailed by Tobias's question
at: https://gcc.gnu.org/legacy-ml/fortran/2019-11/msg00098.h
Hi Richard,
This looks good to me. OK for master. Do you have any plans to backport to
10-branch, say?
Thanks
Paul
On Tue, 27 Oct 2020 at 09:28, Richard Biener via Fortran <
fort...@gcc.gnu.org> wrote:
> On Fri, Oct 16, 2020 at 10:47 AM Richard Biener wrote:
> >
> > This refactors the array
Hi Harald,
OK for master and 10-branch if you want.
Thanks
Paul
On Mon, 26 Oct 2020 at 21:00, Harald Anlauf wrote:
> As found/reported by Thomas, the redefinition of dummy arguments with the
> VALUE attribute was erroneously rejected for pure procedures. A related
> purity check did not tak
Hi Thomas,
OK for master.
Thanks for working on this one!
Paul
On Fri, 16 Oct 2020 at 20:33, Thomas Koenig via Fortran
wrote:
> Hello world,
>
> here's a patch which corrects some wrong declarations (and fixes
> the segfault for FINDLOC on Darwin ARM).
>
> Regression-tested. OK for trunk?
>
Hi Mark,
OK for master. If you want to backport, that's fine by me but please give
it a few weeks.
Thanks for fixing this.
Paul
On Tue, 13 Oct 2020 at 08:17, Mark Eggleston
wrote:
> **ping**
>
> previously omitted commit message added
>
> On 29/09/2020 14:03, Mark Eggleston wrote:
> > For re
Hi Tobias,
This looks good to me - OK for master.
Thanks for the patch
Paul
On Wed, 30 Sep 2020 at 09:59, Tobias Burnus wrote:
> The non-contiguous had both check false positive and false
> negative results. Some more refinements
> are surely possible, but hopefully there are no longer
> fal
Hi All,
The original testcase turned out to be relatively easy to fix - the chunks
in trans-expr.c and trans-stmt.c do this. However, I tested character
actual arguments to 'write_array' in the testcase and found that the _len
component of the unlimited polymorphic dummy was not being used for the
This patch detects a scalar function result that has allocatable components
and is being used inside a scalarization loop. Before this patch, the
components would be deallocated and nullified within the scalarization loop
and so would cause a segfault on the second cycle of the loop.
The stored re
Hi All,
Here is another of Steve Kargl's patches.
Before the patch is applied, the following code is generated:
atmp.0.span = 4;
atmp.0.data = 0B;
atmp.0.offset = 0;
(*(integer(kind=4)[0] * restrict) atmp.0.data)[0] = 1;
(*(integer(kind=4)[0] * restrict) atmp.0.data)[1] = 2;
Hi All,
The fix for PR9601 is rather trivial and is the last chunk of the patch.
Finding the fix for PR96100 took a silly amount of time but it now looks
rather obvious. Trying to evaluate the string length by calling
gfc_conv_expr_descriptor, when this function is already failing to find it
is ki
Hi All,
trans-expr.c(fcncall_realloc_result) unconditionally compared the shapes of
the function result and the lhs. This is clearly wrong when the lhs is not
allocated since the bounds could be used uninitialized as found by the
reporter. The patch does the obvious thing by checking the allocatio
but
the error is different... if you see what I mean :-)
Paul
On Wed, 5 Aug 2020 at 16:40, Steve Kargl
wrote:
> On Wed, Aug 05, 2020 at 03:59:38PM +0100, Paul Richard Thomas wrote:
> > The attached patch builds on a draft posted by Steve Kargl. I have left
> the
> > gcc_asser
I must say that I was thinking rather more of the INTENT(IN) case to make
sure that it is accepted.
Paul
On Wed, 5 Aug 2020 at 17:41, Thomas Koenig wrote:
> Hi Paul,
>
> > This is OK by me.
>
> Committed (or should I say "pushed"?), thanks!
>
> > Is it worth testing the INTENT variants?
>
> I
Hi Thomas,
This is OK by me.
Is it worth testing the INTENT variants?
Cheers
Paul
On Tue, 4 Aug 2020 at 20:03, Thomas Koenig via Fortran
wrote:
> Hello world,
>
> the attached patch issues an error for something that I am sure most
> people did at least once (I know I did), something like
>
The attached patch builds on a draft posted by Steve Kargl. I have left the
gcc_assert in place just in case my imagination was too limited to generate
an ICE.
Regtests OK on FC31/x86_64 - OK for trunk?
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/r
The attached patch regtests on FC31/x86_64 - OK for trunk?
Cheers
Paul
Commit message:
This patch fixes PR96325. See the explanatory comment in the testcase.
2020-08-01 Paul Thomas
gcc/fortran
PR target/96325
* primary.c (gfc_match_varspec): In the case that a component
reference is added
Hi Thomas,
I discovered the bit about the ChangeLogs last night but thanks for the
warning:-)
The commit message reads:
This patch fixes PR96320. See the explanatory comment in the testcase.
2020-08-01 Paul Thomas
gcc/fortran
PR target/96320
* interface.c (gfc_check_dummy_characteristics):
Hi All,
This is my first foray into gfortran for quite a little while so I am going
cautiously on this 'obvious' patch. The comment in the patch and the
ChangLog are clear enough that no further explanation is needed.
Regtests on FC31.x86_64 - OK for trunk?
I am a bit reluctant to get into backp
Hi Thomas,
I am fine with this being in frontend-passes.c - it was just a question
:-) resolve.c has become too large anyway.
The testcase looks familiar! Don't forget to commit and push the additional
source too.
OK for 10-- and all the affected branches.
Cheers
Paul
On Sat, 18 Jul 2020 at
Hi Thomas,
The patch looks fine to me but I have two questions:
(i) Why is this not done in resolve.c?
(ii) Is Martin's reduced reproducer not the basis for a testcase?
Regards
Paul
On Sat, 18 Jul 2020 at 11:58, Thomas Koenig via Fortran
wrote:
> Ping?
>
> > the attached patch fixes a 9/10/
Hi Thomas and Dominique,
The patch looks fine to me. If Dominique has nothing to report then it is
OK for trunk.
Thanks
Paul
On Thu, 2 Jul 2020 at 11:15, wrote:
> Le 2020-06-30 23:39, Thomas Koenig a écrit :
> > OK,
> >
> > so here is an updated version, which includes the updated test cases
Hi Harald,
That looks good to me for all three branches.
Cheers
Paul
On Fri, 29 May 2020 at 23:00, Harald Anlauf wrote:
> The initial attempt to fix this PR unfortunately produced a regression
> in the testsuite that was overlooked. The real fix is to apply this
> check in the appropriate
Hi Thomas,
You didn't attach the testcase but never mind, I am sure that it is OK :-)
OK for trunk and, if you feel like it, for 9-branch.
Thanks
Paul
On Tue, 21 Apr 2020 at 22:56, Thomas Koenig via Fortran
wrote:
> Hello world,
>
> this one took a bit of detective work. When array pointer
Hi Tobias,
I would say that if any patch were obvious, that one is :-) OK.
Thanks
Paul
On Mon, 30 Mar 2020 at 09:16, Tobias Burnus wrote:
> Early *ping*.
>
> Tobias
>
> On 3/27/20 11:06 AM, Tobias Burnus wrote:
>
> > Hi all,
> >
> > here, the reject_statement cleanup and the freeing of the
>
Hi Tobias,
Thanks for the patch. I had flagged it up as one that I should be dealing with.
OK indeed!
Cheers
Paul
On Fri, 27 Mar 2020 at 08:05, Tobias Burnus wrote:
>
> Using "associate (y => procedure_name)" and
> "associate (y => derived_type_name)" failed with an ICE
> when converting to a
This turned out to be relatively trivial, following a fair amount of
head scratching:-(
Regtests on FC31/x64_86 - OK for both branches?
Paul
2020-03-26 Paul Thomas
PR fortran/94246
* expr.c (scalarize_intrinsic_call): Remove the error checking.
Make a copy of the expression to be
Subject:Re: [Fortran, OpenACC] Reject vars of different scope in $acc
> declare (PR94120)
> Date: Tue, 10 Mar 2020 18:02:41 +
> From: Paul Richard Thomas
> To: Tobias Burnus
>
>
>
> Hi Tobias,
>
> This looks to be straightforward enough to me :-) OK fo
This is yet another case, where a deferred character length variable
loses the character length backend_decl. As previously, converting the
expression and using the string_length recovers it successfully.
Regtested on FC31/x86_64 - OK for trunk, followed by 8- and 9-branches
after a week or two?
***ping***
On Sun, 1 Mar 2020 at 16:00, Paul Richard Thomas
wrote:
>
> This is a straightforward patch, especially for the bug in the PR! The
> additional fix ensures that expr%LEN always returns a scalar. Please
> note the comment in resolve.c about bounds checking.
>
> Regt
Andrew,
I agree with Steve. That said, I took a look at your patch and it's
just fine. OK to commit.
Cheers
Paul
On Mon, 2 Mar 2020 at 02:10, Steve Kargl
wrote:
>
> On Sun, Mar 01, 2020 at 11:43:23PM +0100, Thomas Koenig wrote:
> > Am 01.03.20 um 23:42 schrieb Steve Kargl:
> > > PS: in general
Committed to head as r10-6952-g7067f8c814088c1d02e40adf79a80f5ec53dbdde
Thanks, Thomas
Paul
On Sun, 1 Mar 2020 at 13:44, Thomas Koenig wrote:
>
> Hi Paul,
>
> > Regtested on FC31/x86_64 - OK for trunk?
>
>
> OK. Thanks for the patch!
>
> Regards
>
> Thomas
--
"If you can't explain i
Committed to head as r10-6954-g957a1b14e99596610abb0777ca86a1c80dde24e0.
Thanks, Thomas
Paul
On Sun, 1 Mar 2020 at 13:43, Thomas Koenig wrote:
>
> Hi Paul,
>
> > Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ?
>
> OK, and thanks for the patch.
>
> I think it makes sense to get this
This is a straightforward patch, especially for the bug in the PR! The
additional fix ensures that expr%LEN always returns a scalar. Please
note the comment in resolve.c about bounds checking.
Regtests on trunk - OK for 9- and 10-branches?
Paul
2020-03-01 Paul Thomas
PR fortran/93581
I am a tiny bit skeptical that this is a regression but I will check.
However, it has clearly been there from the early days of OOP without
being picked up.
The fix is to ensure that the temporary has the correct type of array spec.
Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ?
Ch
This is a another case of the gotcha's that come from trying to use
ts.u.cl->backend_decl directly, where deferred length and even, in
this case fixed length characters are concerned. The fix is to make
use of the string length obtained from evaluation of the expression.
Regtested on FC31/x86_64 -
Committed as revision r10-6924-g7485ace81de9ec9dd5c87edf67e359d31ce35a20
On Fri, 28 Feb 2020 at 12:15, Paul Richard Thomas
wrote:
>
> I will commit this tonight as 'obvious' unless there are any
> complaints. This descriptor renormalisation is already present in
> gfc
I will commit this tonight as 'obvious' unless there are any
complaints. This descriptor renormalisation is already present in
gfc_conv_derived_to_class.
Paul
2020-02-28 Paul Thomas
PR fortran/92785
* trans-expr.c (gfc_conv_intrinsic_to_class): Renormalise non-
variable expression
Committed as r10-6801-g61c8d9e4e5f540501eaa98aae1d6c74bde7d4299
Thanks
Paul
On Sun, 23 Feb 2020 at 14:25, Thomas Koenig wrote:
>
> Hi Paul,
>
> > Regtested on FC31/x86_64 - OK for head?
>
> Looks good.
>
> Best of luck committing!
>
> Regards
>
> Thomas
--
"If you can't explain it s
This patch is relatively trivial and represents my first foray into
gitland. Thus far, it has been... well, "interesting" compared with
svn.
Class components of derived types are initialized by calls to
trans-array.c(gfc_trans_deferred_array) from
trans-decl.c(gfc_trans_deferred_vars). The compone
Hi Tobias,
Yes, OK for trunk.
I would have been perfectly happy for you to commit as 'obvious'.
Cheers
Paul
On Mon, 3 Feb 2020 at 08:44, Tobias Burnus wrote:
>
> Another slightly early ping.
>
> Tobias
>
> On 1/31/20 3:24 PM, Tobias Burnus wrote:
> > *ping* after 4 days.
> >
> > On 1/27/20 2:
Hi All,
Thank you for taking care of that, Jakub. I have been overwhelmed by
daytime work since my last posting and, in addition, have yet to set
up a git workflow. This situation is likely to continue for at least
another 3-4 months. I will release all the PRs assigned to me, except
those associa
This patch is straight forward and well explained by the ChangeLogs.
The ICE comes about because the simplification of the inquiry_part_ref
expressions produced bad expressions.
Thanks to Steve for spotting the error in the INQUIRY_RE and
INQUIRY_IM parts that was so blindingly obvious that I coul
Hi Thomas,
This is OK for trunk.
Thanks for the patch
Paul
On Sun, 24 Nov 2019 at 17:10, Thomas Koenig wrote:
>
> Hello world,
>
> this patch fixes a 10 regression in dependency checking. The
> approach is simple - if gfc_dep_resolver is handed references
> with _data, remove that.
>
> Regress
the result is:
5
ptr is no longer associated with assoc
Cheers
Paul
On Mon, 18 Nov 2019 at 10:24, Tobias Burnus wrote:
>
> On 11/17/19 7:34 PM, Paul Richard Thomas wrote:
> […]
> Sorry for not yet reviewing the code, but the following caught my eye:
> > (gfc_a
This is a somewhat delayed patch to fix issues with the original
patch, as flagged up by Rainer in comment #12, Rainer in comment #14
and Eric in comment #15. The fix for these problems was posted in
April in comment #17. It was thoroughly tested but remained
uncommitted because my attention was el
As I remarked in PR, this fix probably comes 1,379 days too late. I am
not at all sure that I understand why I couldn't see the problem
because it is rather trivial.
I am open to not adding the second gcc_assert - it does seem like overkill.
Regtested on FC30/x86_64 - OK for trunk and ?
Paul
I too had some considerable difficulty on this point. I wasn't at all
sure that the C world view was relevant here since the API includes
CFI_address and, in principle, one could reference directly the
elements pointed to by base_addr. However, I bow to the wisdom of your
correspondents on the j3 l
Hi Tobias,
Thanks for taking care of this so rapidly :-)
OK for trunk and for 9-branch.
Cheers
Paul
On Tue, 12 Nov 2019 at 14:42, Tobias Burnus wrote:
>
> Regarding the uncontroversial part: CFI_address. This has been reported
> by Vipul Parekh a few hours ago and the problem is: The lower bo
The attached patch is verging on the obvious. Thanks to Tobias for
spotting Vipul's messages on the J3 list.
Regtests on FC30/x86_64 - OK for trunk and 9-branch?
Paul
2019-11-03 Paul Thomas
PR fortran/92123
*decl.c (gfc_verify_c_interop_param): Remove error asserting
that pointer
Hi Tobias,
OK for trunk and for 9-branch. As with the patch for PR92277, you will
have to get release manager approval for 9.2.
Thanks for working on this.
Cheers
Paul
On Wed, 30 Oct 2019 at 23:29, Tobias Burnus wrote:
>
> Playing with the PR92284 test case revealed two issues related to
> gf
Hi Tobias,
OK for trunk and for 9-branch. For the latter, you will have to get
release manager approval of course.
Thanks for picking up my doo-doos.
Cheers
Paul
On Wed, 30 Oct 2019 at 15:40, Tobias Burnus wrote:
>
> The attached test case (w/o optional and with "this") gave an ICE as
> "*thi
Hi Tobias,
Thanks for taking care of this. OK for trunk and 9-branch.
Cheers
Paul
On Wed, 23 Oct 2019 at 14:07, Tobias Burnus wrote:
>
> With the trunk, there are three issues:
>
> (a) With bind(C), the callee side handles deallocation with intent(out).
>
> This should produce the code:
>
Hi Steve,
Thanks for the heads up. I'll get on to it right away.
Regards
Paul
On Sat, 26 Oct 2019 at 20:04, Steve Kargl
wrote:
>
> On Sat, Oct 26, 2019 at 07:39:55PM +0100, Paul Richard Thomas wrote:
> > As far as I can tell, this is a 6-regression as well - ***sigh***
>
As far as I can tell, this is a 6-regression as well - ***sigh***
The patch is fundamentally very simple. Symbols that were marked with
the fn_result_spec flag that really were module parameters were having
the wrong name mangling applied to them. The rest of the patch is a
tidy up.
Regtested on
Please find attached a patch to keep 9-branch up to speed with trunk
as far as the ISO_Fortran_binding feature is concerned.
It bootstraps and regtests on 9-branch and incorporates the correction
for PR92027, which caused problems for trunk on certain platforms.
OK to commit?
Paul
2019-10-21 P
fixes the fall out. – Thanks!
>
> On 10/9/19 12:26 PM, Paul Richard Thomas wrote:
> > Hi Christophe,
> >
> > Thanks for flagging this up - I am back at base on Saturday and will
> > take it up then.
> >
> > Regards
> >
> > Paul
> >
> &g
I will deal with this and various other issues associated with
ISO_Fortran_binding tomorrow.
Thanks for your help
Paul
On Thu, 17 Oct 2019 at 18:30, Tobias Burnus wrote:
>
> Hi,
>
> + fprintf (stderr, "CFI_setpointer: Result is NULL.\n");
> …
> > + return CFI_INVALID_DESCRIPTOR;
> > +! { d
r89943_2.f90: Ditto.
> * gfortran.dg/pr89943_3.f90: Ditto.
> * gfortran.dg/pr89943_4.f90: Ditto.
>
>
>
> On Sat, Oct 12, 2019 at 02:57:25PM +0100, Paul Richard Thomas wrote:
> > Hi Steve,
> >
> > In the F2018 standard: C1550 (R1526) If MODULE appears i
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
201 - 300 of 1216 matches
Mail list logo