This was fixed as 'obvious' with an off-list OK, posted on the PR, from
Harald. Applied to 13-branch and trunk then closed as fixed.
Cheers
Paul
Fortran: Alloc comp of non-finalizable type not finalized [PR111674]
2023-10-04 Paul Thomas
gcc/fortran
PR fortran/37336
PR fortran/111674
* trans
> Thanks for the fast review.
> >
> > Regards,
> > Andre
> >
> > On Fri, 29 Sep 2023 13:38:57 +0100
> > Paul Richard Thomas wrote:
> >
> > > Hi Andre,
> > >
> > > Yes indeed - it's fine for trun
. This also is no problem.
>
> Regtests ok on x86_64_linux_gnu/f37. Ok for trunk?
>
> Regards,
> Andre
>
> On Thu, 28 Sep 2023 19:21:12 +0100
> Paul Richard Thomas wrote:
>
> > Hi Andre,
> >
> > The patch looks fine to me. Since you mention it in the
Hi Andre,
The patch looks fine to me. Since you mention it in the comment, is it
worth declaring the derived type 'foo' in a module and giving it a
final routine?
Thanks for the patch.
Paul
On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran
wrote:
>
> Hi all,
>
> attached patch fixes
Hi All,
This is a straightforward patch that is adequately explained by the ChangeLog.
Regtests fine - OK for trunk?
Cheers
Paul
Fortran: Pad mismatched charlens in component initializers [PR68155]
2023-09-20 Paul Thomas
gcc/fortran
PR fortran/68155
* decl.cc (fix_initializer_charlen): Ne
Hi Mikael,
The comment is very welcome! Looks good to me. OK for mainline.
Thanks for the patch.
Paul
On Fri, 15 Sept 2023 at 08:19, Mikael Morin via Fortran
wrote:
>
> Hello,
>
> Harald reminded me recently that there was a working patch attached to the PR.
> I added a documentation comment w
Hi Harald,
The statement,
in array_bound_check_elemental is redundant since the call is
determined by a more restrictive condition.
+ if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS))
+return;
Apart from that, it looks good to me. OK for mainline.
Thanks for the patch.
Paul
On Thu, 14 Sep
After two months on trunk, this has been backported:
Fortran: Fix some problems blocking associate meta-bug [PR87477]
2023-08-27 Paul Thomas
gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expr
Committed as 'obvious'. 13-branch to follow.
commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
Author: Paul Thomas
Date: Sat Aug 26 14:37:49 2023 +0100
Fortran: Supply a missing dereference [PR92586]
2023-08-26 Paul Thomas
gcc/fortran
PR fortran/92586
Hi Harald,
It all looks good to me and does indeed make the code clearer. OK for trunk.
Thanks for the patch.
I was shocked to find that there are 217 older bugs than 49588. Does
anybody test older bugs to check if any of them have been fixed?
Paul
On Mon, 21 Aug 2023 at 20:48, Harald Anlauf v
I took a look at my calendar and decided to backport right away.
r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7
BTW It is a regression :-)
Paul
On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas
wrote:
>
> Committed to trunk as 'obvious
Committed to trunk as 'obvious' in
r14-3098-gb8ec3c952324f866f191883473922e250be81341
13-branch to follow in a few days.
Paul
Hi Mikhail,
That's more than OK by me.
Thanks for attacking this PR.
I have a couple more of Steve's orphans waiting to be packaged up -
91960 and 104649. I'll submit them this evening.100607 is closed-fixed
and 103796 seems to be fixed.
Regards
Paul
On Tue, 11 Jul 2023 at 13:08, Mikael Morin
The attached patch incorporates two of Steve's "Orphaned Patches" -
https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html
They have in common that they both involve faults in use of default
type and that I was the ultimate cause of the bugs.
The patch regtests with the attached testcases.
Hi Harald,
This is indeed obvious :-)
Thanks for the patch.
Paul
On Fri, 7 Jul 2023 at 19:32, Harald Anlauf via Fortran
wrote:
>
> Dear all,
>
> I intend to commit the attached obvious patch within 24h unless
> someone objects. gfc_compare_expr() did not handle the case of
> complex constants
Hi All,
I have gone through the PDT problem reports and made sure that they
block PR82173.
To my utter astonishment (i) There might be only one duplicate; and
(ii) Only 82649, 84119, 90218, 95541, 99079, 102901 & 105380 (out of
50 PRs) depend on the representation.
Regards
Paul
Hi Alexander,
I suggest that you take a look at PR82649 before going too far down
the road of fixing PDT bugs. This PR underlines just how wrong the PDT
representation is - mea culpa!
The mechanics for constructing PDTs are in
decl.cc(gfc_get_pdt_instance). They need to be turned inside out to
cr
e
> size of a character string you are using an intermediate
> gfc_array_index_type, whereas I have learned to use
> gfc_charlen_type_node now, which seems like the natural
> type here.
>
> OK for trunk, and thanks for your patience!
>
> Harald
>
>
> On 6/27/23
sions.
(gfc_trans_subcomponent_assign): Expand assignment to class
components to include intrinsic and character expressions.
gcc/testsuite/
PR fortran/49213
* gfortran.dg/pr49213.f90 : New test
On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote:
>
> Hi Paul!
>
> On 6/24/23 15:18, Paul Richard Thomas via Gcc-pat
Hi All,
I was looking through Neil Carlson's collection of gfortran bugs and
was shocked to find this rather fundamental PR. At 12 years old, it is
certainly a "golden oldie"!
The patch is rather straightforward and seems to do the job of
admitting derived, intrinsic and character expressions to
Hi Both,
> while I only had a minor question regarding gfc_is_ptr_fcn(),
> can you still try to enlighten me why that second part
> was necessary? (I believed it to be redundant and may have
> overlooked the obvious.)
Blast! I forgot about checking that. Lurking in the back of my mind
and going
Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Thanks for the help and the review Harald. Thanks to Steve too for
picking up Neil Carlson's bugs.
Cheers
Paul
On Tue, 20 Jun 2023 at 22:57, Harald Anlauf wrote:
>
> Hi Paul,
>
> On 6/20/23 12:54, Paul Richa
Committed as r14-2021-gcaf0892eea67349d9a1e44590c3440768136fe2b
Thanks for the pointers, Tobias and Mikael, I used them both.
Paul
On Tue, 20 Jun 2023 at 21:47, Mikael Morin wrote:
>
> Le 20/06/2023 à 18:30, Tobias Burnus a écrit :
> > On 20.06.23 18:19, Paul Richard Thomas via F
Dear All,
This patch is verging on obvious. The PR was originally, incorrectly
blocking PR87477 and the testcase has remained in my 'associate'
directory. I thought that it is time to get shot of it!
Is there a better way to detect a type(c_ptr) formal argument?
Subject to advice on the question
Hi Tobias,
This looks good to me. I'm interested to see it in use :-)
OK for trunk
Paul
On Tue, 20 Jun 2023 at 11:50, Tobias Burnus wrote:
>
> When just matching a symbol, one can use 'gfc_match_symbol (&sym, host_assoc)'
> and has the option to match with and without host association.
>
> How
Hi Harald,
Fixing the original testcase in this PR turned out to be slightly more
involved than I expected. However, it resulted in an open door to fix
some other PRs and the attached much larger patch.
This time, I did remember to include the testcases in the .diff :-)
I believe that, between t
Hi All,
The attached patch is amply described by the comments and the
changelog. It also includes the fix for the memory leak in decl.cc, as
promised some days ago.
OK for trunk?
Regards
Paul
PS This leaves 89645 and 99065 as the only real blockers to PR87477.
These will take a little while to
Morin wrote:
> > Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
> >> Hi Harald,
> >>
> >> In answer to your question:
> >> void
> >> gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
> >> {
> >>free_expr0 (dest);
&g
of the expression
and this was somehow connected with successfully simplifying the
parentheses. Copying and replacing on no errors deals with the
problem.
Thanks
Paul
On Wed, 7 Jun 2023 at 19:38, Harald Anlauf wrote:
>
> Hi Paul!
>
> On 6/7/23 18:10, Paul Richard Thomas via Gcc-p
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the .diff + ChangeLog suffice
to explain them. 'rankguessed' was made redundant b
Hi Thomas,
I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.
I am dithering about changing the F2003/08 part of finalization since
the default is 2018 compliance. That s
Hi Harald,
It looks good to me. Thanks to you and Steve for the fix. I suggest
that it is such and obvious one that it deserved back-porting.
Cheers
Paul
On Fri, 2 Jun 2023 at 19:06, Harald Anlauf via Fortran
wrote:
>
> Dear all,
>
> I've committed that attached simple patch on behalf of Steve
Hi All,
I propose to backport
r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
soon. Before that, I propose to remove the F2003/2008 finalization of
structure and array constructors in 13- and 14-branches. I can see why
it was removed from the standard in a correction to F2008
aul Richard Thomas via Fortran a écrit :
> > Hi All,
> >
> > This started out as the search for a fix to pr109948 and evolved to roll
> in
> > 5 other prs.
> >
> > Basically parse_associate was far too clunky and, in anycase, existing
> > functions in resolve
Hi All,
This started out as the search for a fix to pr109948 and evolved to roll in
5 other prs.
Basically parse_associate was far too clunky and, in anycase, existing
functions in resolve.cc were well capable of doing the determination of the
target expression rank. While I was checking the comm
Duuh! There's even a choice :-)
Paul
On Tue, 9 May 2023 at 19:29, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > This problem caused the gimplifier failure because the reference chain
&g
Hi All,
This problem caused the gimplifier failure because the reference chain
ending in an inquiry_len still retained a full array reference. This had
already been corrected for deferred character lengths but the fix extends
this to all characters without a length expression and integer expressio
Hi All,
Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
this testcase checked that finalizable derived types could not be specified
in a submodule. I have replaced the original test with a test of the patch.
Thanks also to Malcolm Cohen for guidance on this.
OK for tr
Hi All,
As usual, I received a string of emails on retargeting for PRs for which I
was either responsible or was on the cc list. This time I decided to take a
look at them all, in order to reward the tireless efforts of Richi, Jakub
and Martin with some attention at least.
I have fixed the PRs in
assigning the value
returned by gfc_conv_expr_descriptor. Also, guard the backend
decl before testing with VAR_P.
gcc/testsuite/
PR fortran/109451
* gfortran.dg/associate_61.f90 : New test
On Thu, 13 Apr 2023 at 07:18, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
&
Hi Harald,
That's interesting - the string length '.q' is not set for either of the
associate blocks. I'm onto it.
Thanks
Paul
On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote:
> Hi Paul,
>
> On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
> &g
Hi All,
I think that the changelog says it all. OK for mainline?
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-07 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl before
Hi Harald,
The patch looks good to me - OK for mainline.
Thanks
Paul
On Tue, 11 Apr 2023 at 21:12, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the testcase in the PR by Gerhard exhibited a mis-treatment of
> the function decl of the entry master if the function result
> had a pointer at
PS Quite right about the allocation in PR93813 - consider it to be included.
Cheers and thanks
Paul
On Fri, 7 Apr 2023 at 22:35, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> Well done on noticing the memory leak :-) I have a fix for it that I
l->backend_decl && VAR_P (cl->backend_decl))
gfc_add_modify (pblock, cl->backend_decl, se.expr);
Cheers
Paul
On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote:
> Hi Paul,
>
> On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote:
> > duuuh! Please find t
duuuh! Please find them attached.
Thanks
Paul
On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote:
> Hi Paul,
>
> I don't see the new testcases. Is this an issue on my side,
> or did you forget to attach them?
>
> Thanks,
> Harald
>
> On 4/7/23 09:07, Paul Rich
Dear All,
Please find attached a slightly updated version of the patch with a
consolidated testcase. The three additional testcases are nothing to do
with associate and test fixes of character related bugs.
OK for mainline?
Cheers
Paul
Fortran: Fix some of the bugs in associate [PR87477]
2023-
: ditto
* gfortran.dg/dtio_35.f90 : ditto
* gfortran.dg/goacc/array-with-dt-2.f90 : ditto
* gfortran.dg/gomp/affinity-clause-1.f90 : ditto
* gfortran.dg/pr103258.f90 : ditto
* gfortran.dg/pr59107.f90 : ditto
* gfortran.dg/pr93835.f08 : ditto
On Wed, 29 Mar 2023 at 09:53, Paul Richard Thomas
Hi Harald,
Quite right - good spot. There was an 'else' that turned out to be
unnecessary.
Thanks
Paul
On Wed, 5 Apr 2023 at 19:50, Harald Anlauf wrote:
> Hi Paul,
>
> On 4/5/23 08:53, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > This i
Hi All,
This is a first in my recent experience - a very old bug that produces too
many finalizations! It results from a bit of a fix up, where class objects
are allocated using the derived typespec, rather than a source or mold
expression. This occurs upstream in resolve.cc, where the default
ini
Hi Harald,
OK for mainline. It is sufficiently small that, if there is any fallout in
the next weeks, it can easily be reverted without great impact.
Thanks for the patch.
Paul
On Mon, 3 Apr 2023 at 20:46, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the attached patch fixes an ICE-on-in
ote:
> Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran:
> > Hi All,
> >
> > I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging
> > fruit are already fixed but I have yet to check that they a really fixed
> > and to close them:
> &
Hi All,
I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging
fruit are already fixed but I have yet to check that they a really fixed
and to close them:
pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & pr93338
The attached patch picks up those PRs involving de
Hi Harald,
If you will excuse the British cultural reference, that's a Norwegian Blue
alright! Good spot.
OK for mainline.
Thanks
Paul
On Sat, 25 Mar 2023 at 19:13, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> I've committed the attached patch from the PR that removes
> a dead code snip
Hi Harald,
This is good for trunk and for backporting.
Thanks for the rapid fix.
Paul
On Mon, 20 Mar 2023 at 20:57, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the attached trivial patch catches a MODULE PROCEDURE outside of a
> module interface before we run into an internal error.
>
>
Hi Thomas,
Yes, that's fine for trunk. I wonder if it is worth being explicit that
linear congruential pseudo-random number generators can and do fail at -O3?
Thanks for the doc patches!
Paul
On Sun, 19 Mar 2023 at 08:32, Thomas Koenig via Fortran
wrote:
> Here's also an update on the docs t
Hi All,
I committed this to 8-branch on 2019-04-24 but not to 9-branch. I have no
record of why I did this.
The patch now requires an additional line,
&& sym->ns->proc_name->attr.proc != PROC_MODULE
to prevent the error message in pr88376.f90 from changing to the less
helpful
Error: Speci
Hi Thomas,
Thanks for that! I think that your one-liner says it all :-)
There are three PRs left open that PR37336 depends on:
PR65347: Is partially fixed. The F2003/8 feature of finalization of a
structure constructor within an array constructor doesn't work. I wonder if
a compile option -finali
Hi Harald,
This is fine for mainline and for backporting if you feel so inclined.
Thanks for the patch.
Paul
On Mon, 16 Jan 2023 at 21:12, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> it appears that the fix for pr107874 uncovered a latent bug
> for the case of arrays of type character a
Hi Thomas,
Following your off-line explanation that the seemingly empty looking
assembly line forces an effective reload from memory, all is now clear.
OK for mainline and for backporting as you see fit.
Thanks for the patch.
Paul
On Sat, 7 Jan 2023 at 15:46, Thomas Koenig via Fortran
wrote:
Hi Harald,
Thanks for doing that. My attention is elsewhere gfortran-wise.
Good for mainline.
Paul
On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> I am submitting the attached simple - and obvious - patch on
> behalf of Paul. It prevents a resource exhaustion d
ks - and it is good to see that you are back!
>
> Harald
>
> Am 04.12.22 um 12:48 schrieb Paul Richard Thomas via Gcc-patches:
> > Hi Harald,
> >
> > That's good to commit.
> >
> > Thanks for the patch.
> >
> > Paul
> >
> >
&
Hi Harald,
That's good to commit.
Thanks for the patch.
Paul
On Sat, 3 Dec 2022 at 20:40, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> here's a small documentation fix for the intrinsic FLOOR.
> Besides that, I adjusted the description of the optional
> KIND argument to Fortran intrinsi
Hi Harald,
It looks good to me. OK to commit.
Thanks
Paul
On Sat, 3 Dec 2022 at 18:27, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the attached obvious patch fixes a NULL pointer dereference
> that occurs with an invalid CLASS argument to DEALLOCATE.
>
> Regtested on x86_64-pc-linux-gnu
Hi Harald,
It looks good to me.
Thanks to you and Steve for the patch.
Paul
On Mon, 28 Nov 2022 at 20:05, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> as reported, the Fortran standard requires all actual argument
> expressions to be evaluated (e.g. F2018:15.5.3).
>
> There were two case
Hi Harald,
It looks good to me - OK for mainline.
Thanks
Paul
On Fri, 8 Apr 2022 at 21:45, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran:
> > Dear all,
> >
> > the logic for checking the allocate-coshape-spec in an ALLOCATE
> > statem
Hi Tobias,
Thanks for the patch and the particularly comprehensive testcase.
OK for mainline as far as I am concerned.
Paul
On Tue, 8 Mar 2022 at 20:06, Tobias Burnus wrote:
> Fix SIZEOF handling.
>
> I have to admit that I do understand what the current code does,
> but do not understand wh
Hi Harald,
I have run your modified version of finalize_38.f90, and now I see
> that you can get a bloody head just from scratching too much...
>
> crayftn 12.0.2:
>
> 1, 3, 1
>
It appears that Cray interpret a derived type constructor as being a
function call and so "6 If a specification ex
Hi Harald,
Thanks for giving the patch a whirl.
> the parent components as an array. I strongly suspect that, from reading
> > 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,
> this
> > is another issue to come back to in the future.
>
> Could you specify which version of I
Hi Harald,
Indeed, this is obvious, as you say. OK for the affected branches.
Regards
Paul
On Tue, 1 Feb 2022 at 22:38, Harald Anlauf via Fortran
wrote:
> Dear Fortranners,
>
> a check in gfc_calculate_transfer_sizes had a bug in the logic:
> it did not trigger for MOLD having a storage size
Hi Harald and Mikael,
This looks fine to me. OK for all the listed branches.
Thanks for the patch
Paul
On Wed, 2 Feb 2022 at 20:20, Harald Anlauf via Fortran
wrote:
> Hi Mikael,
>
> Am 29.01.22 um 15:24 schrieb Mikael Morin:
> > Hello,
> >
> > the attached patch is a fix for PR104228.
> > Ev
This patch has been an excessively long time in coming. Please accept my
apologies for that.
All but two of the PR37336 dependencies are fixed, The two exceptions are
PRs 59694 and 65347. The former involves lack of finalization of an
unreferenced entity declared in a block, which I am sure is tri
Hi All,
Strictly speaking, the attached patch is branching out into a more
generalised attack on PR37336(Finalization) - [F03] Finish derived-type
finalization but most of it fixes PR64290.
I started work on this patch almost a year ago but had to drop it due
daytime work pressure and only picked
I doubt that this is a regression on 9-11 branches since the testcase
compiles correctly on each of my copies of these branches. IMHO it is
rather more likely to have been caused by
64f9623765da3306b0ab6a47997dc5d62c2ea261, which introduced this new form of
gfc_conv_gfc_desc_to_cfi_desc.
The patch
Hi Sandra,
That's a good shout to query suppress_errors. The patch is OK by me.
Thanks
Paul
On Wed, 5 Jan 2022 at 03:21, Sandra Loosemore
wrote:
> This patch fixes an ICE that appeared after I checked in my patch for
> PR101337 back in November, which made the resolve phase try harder to
> c
6 schrieb Paul Richard Thomas via Fortran:
> > Hi Harald,
> >
> > This looks good to me. OK for mainline and, dare I suggest, 11-branch?
> >
> > From a quick run through resolve.c, there are many places where the
> extra
> > checks that you introduced in th
Hi Harald,
This looks good to me. OK for mainline and, dare I suggest, 11-branch?
>From a quick run through resolve.c, there are many places where the extra
checks that you introduced in the patch have been implemented. This makes
me wonder whether a function or macro might not make the relevant
Hi Sandra,
Looks good to me.
Thanks
Paul
On Fri, 5 Nov 2021 at 21:13, Sandra Loosemore
wrote:
> I was recently pinged about PR35276. It's an old issue, but a couple of
> the concerns raised there haven't been fixed yet, so I've checked in
> this patch to fill in the gaps.
>
> -Sandra
>
--
Hi Tobias,
My disappearance is partly responsible for the backlog. I told José that I
would start working on it some months since but just have not had the time.
I can do some of the reviews but still do not have much time to spare.
Perhaps you could divide them up between us.
Andrew Benson has b
Hi Tobias,
This is OK for mainline and as far back in the branches as you feel
inclined to go.
Thanks for the patch.
Paul
On Fri, 15 Oct 2021 at 22:19, Tobias Burnus wrote:
> This patch fixes two issues:
>
> First, to print 'CLASS(t2)' instead of:
> Error: Type mismatch in argument ‘x’ at (1
Hi Tobias,
I can only echo Harald's comment that this is an impressive bit of work.
I spent some time messing with fc-descriptor-7.f90/gc-descriptor-7-c.cc
because it kept failing on me. This came about because I missed one of the
chunks not applying in the C component of the test; namely:
for
Hi Tobias,
s/However, as argument they are also iteroperable/However, as an argument
they are also interoperable/
s/ /* else: valid only sind F2018 - and an assumed-shape/rank
array; however, gfc_notify_std is already called when
those array type are used. Thus, silently accept F200x. */
Hi Harald,
It looks good to me. OK for mainline. You might even consider backporting
to 11-branch.
Best regards
Paul
On Fri, 27 Aug 2021 at 21:15, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the ICE in the original testcase does no longer occur but leads to an
> error in a later stage o
Hi Harald,
Looks good to me - OK for as many branches as you have sufficient fortitude
for.
Regards
Paul
On Thu, 3 Jun 2021 at 21:22, Harald Anlauf via Fortran
wrote:
> *PING*
>
> > Gesendet: Donnerstag, 27. Mai 2021 um 22:20 Uhr
> > Von: "Harald Anlauf"
> > An: "fortran" , "gcc-patches" <
Hi José,
I can second Dominique's thanks. I applied it to my tree when you first
posted, set the regtest in motion and have not been able to return to
gfortran matters since.
OK for master.
I am especially happy that you have tackled this area and have rationalised
it to a substantial degree. Th
Hi Harald,
I meant to deal with this myself since I am the guilty party. However, the
last two weeks have been taken up by a house move and so gfortran has been
on the backburner.
The patch looks good and seems to do the job - OK for master and 11-branch.
Thanks a million for dealing with it!
P
It's 46991 of course.
Many thanks
Paul
On Thu, 6 May 2021 at 17:15, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Blast! Thanks for pointing it out. The testcase is in a directory
> ~/prs/pr46691, which I then took from the editor. Original sin and all
>
Blast! Thanks for pointing it out. The testcase is in a directory
~/prs/pr46691, which I then took from the editor. Original sin and all
that.
Paul
On Thu, 6 May 2021 at 17:06, Jonathan Wakely wrote:
> PR 46691 is the wrong PR number:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691
>
/ChangeLog
PR fortran/46691
PR fortran/99819
* gfortran.dg/class_dummy_6.f90: New test.
* gfortran.dg/class_dummy_7.f90: New test.
On Thu, 6 May 2021 at 07:57, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> Although I had undertaken to concentrate on PDTs
Hi All,
Although I had undertaken to concentrate on PDTs, PR99819 so intrigued me
that I became locked into it :-( After extensive, fruitless rummaging
through decl.c and trans-decl.c, I realised that the problem was far
simpler than it seemed and that it lay in class.c. After that PR was fixed,
P
Ping!
On Tue, 20 Apr 2021 at 12:51, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> This is another PDT warm-up patch before tackling the real beast: PR82649.
>
> As the contributor wrote in the PR, "The F08 standard clearly
> disting
Hi José!
The fix is fine.
Note however that the testcase will pass even without the fix because you
haven't included the
! { dg-options "-fcheck=pointer" }.
In fact, I suggest that you use the version of the tescase that I have
attached that does not run but counts the number of occurrences of '
Hi Harald,
Another good one - OK for master but wait a while for 11-branch.
I am a bit hesitant about 10-branch because this is not a regression. That
said, this is harmless because it is permissive, so I will leave it to you
to decide.
Is there a test for an error with -std=f2003? If not, you s
Hi Harald,
It looks good to me! Keep clear of 11-branch until release but OK for the
others.
Thanks
Paul
On Fri, 23 Apr 2021 at 00:18, Harald Anlauf via Fortran
wrote:
> Now with the correct patch attached ...
>
> Sorry for the confusion!
>
> ---
>
> Dear Fortranners,
>
> we need to check th
Hi All,
This is another PDT warm-up patch before tackling the real beast: PR82649.
As the contributor wrote in the PR, "The F08 standard clearly distinguishes
between type parameter definition statements and component definition
statements. See R425, R431, R435, and in particular see Note 6.7 whi
20.04.21 11:58, Tobias Burnus wrote:
> > Hi Paul,
> >
> > is there a reason why you did not apply the patch to mainline ('master')
> > but only to GCC 11 ('releases/gcc-11')?
> >
> > While GCC 11 is okay, I had expected it to be (onl
;
> On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote:
> > I was just about to announce that I will only do backports and
> regressions,
> > while I finally attack the fundamental problem with the representation of
> > Parameterized Derived Types. Then this PR c
Hi All,
I was just about to announce that I will only do backports and regressions,
while I finally attack the fundamental problem with the representation of
Parameterized Derived Types. Then this PR came up that was such clear low
hanging fruit that I decided to fix it right away.
Regtests on FC
Hi Martin,
It looks good to me - please push before release.
Thanks
Paul
On Mon, 12 Apr 2021 at 16:59, Martin Liška wrote:
> A column with empty values seems suspicious.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/fortran/ChangeLog:
>
> * intrinsic.texi: The table has first
Hi Jose,
Please take a look at my reply on the PR, which points to PR98534.
Regards
Paul
On Fri, 16 Apr 2021 at 20:47, José Rui Faustino de Sousa via Fortran <
fort...@gcc.gnu.org> wrote:
> Hi All!
>
> Proposed patch to:
> PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS enti
101 - 200 of 1227 matches
Mail list logo
