://gcc.gnu.org/wiki/Fortran2008Status and
https://gcc.gnu.org/wiki/Fortran2018Status. I will update these pages once
I am entirely sure of the state of each.
Cheers
Paul
On Fri, 13 Oct 2023 at 07:32, Richard Biener
wrote:
> On Thu, Oct 12, 2023 at 6:54 PM Paul Richard Thomas
> wrote:
>
Hi Harald,
That's good for mainline.
Thanks for the patch
Paul
On Thu, 26 Oct 2023 at 21:43, Harald Anlauf wrote:
> Dear all,
>
> the attached patch improves the diagnostics of MODULE PROCEDURE declaration
> conflicts, when one of the declarations is an alternate return. We used to
> ICE
The interpretation request came in a long time ago but I only just got
around to implementing it.
The updated text from the standard is in the comment. Now I am writing
this, I think that I should perhaps use switch(op)/case rather than using
if/else if and depending on the order of the
* gfortran.dg/interface_50.f90: New test.
On Wed, 1 Nov 2023 at 20:12, Harald Anlauf wrote:
> Hi Paul,
>
> Am 01.11.23 um 19:02 schrieb Paul Richard Thomas:
> > The interpretation request came in a long time ago but I only just got
> > around to implementing it.
> >
> > T
Hi All,
I have pushed as 'obvious' a fix for this regression to both 13-branch and
mainline. The patch itself looks substantial but it consists entirely of
the removal of a condition and repagination of the corresponding block.
Please see below for part of my first comment on the PR for an
Hi Harald,
This looks good to me. OK for mainline.
Thanks for the patch.
Paul
On Wed, 1 Nov 2023 at 22:10, Harald Anlauf wrote:
> Dear all,
>
> I've dusted off and cleaned up a previous attempt to fix the handling
> of allocatable or pointer actual arguments to OPTIONAL+VALUE dummies.
> The
Bizarrely, since the fix for pr101625, the testcase compiles and runs
correctly with s/select type (y => x)/select type (y => (x))/ !
The fix is straightforward and appears to be one of those wrinkles arising
from the use of associate variables as a selector. The fault is reasonable
since the
I found this 'obvious' fix, while going through PRs assigned to me.
Regtests. OK for mainline?
Cheers
Paul
Fortran: Allocatable automatic charlen must not be saved [PR64120].
2023-10-31 Paul Thomas
gcc/fortran
PR fortran/64120
* trans-decl.cc (gfc_trans_deferred_vars): Detect automatic
Hi All,
The attached patch fixes the original problem, in which parentheses around
the selector in select type constructs caused ICES. Stacked parentheses
caused problems in trans-stmt.cc. Rather than tracking this down, the
redundant parentheses were removed on resolution of the selector
Hi Martin,
This looks to be 'obvious' and is certainly OK for mainline. Backport if
you wish.
Thanks
Paul
On Fri, 3 Nov 2023 at 12:54, Martin Jambor wrote:
> Hi,
>
> when developing an otherwise unrelated patch I've discovered that the
> fnspec for the Fortran library function
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 trunk and, I w
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
*
>
> you'll likely want
>
> ! { dg-do run }
>
> (Note the space before the dg-command.)
>
> Cheers,
> Harald
>
> On 10/11/23 21:06, Harald Anlauf wrote:
> > Hi Paul,
> >
> > On 10/11/23 10:48, Paul Richard Thomas wrote:
> >> Hi All,
>
I have posted the version 4 of Ian Chivers and Jane Sleightholme's F2008
compliance table as an attachment to PR39627.
With Harald Anlauf's help it has been updated to correspond to gfortran
13.2. In the previous return for gfortran, a number of lines had not been
filled out at all. This has now
Hi All,
The title line of the PR should have been changed a long time since. As
noted in comment 5, the original problem was fixed in 10.5.
This patch fixes the problem described in comments 4 and 6, where the
hidden string length component was not being set in pointer assignment of
character
> Hi Paul,
>
> On 12/6/23 17:09, Paul Richard Thomas wrote:
> > Dear All,
> >
> > This patch was rescued from my ill-fated and long winded attempt to
> provide
> > a fix-up for function selector references, where the function is parsed
> > after the procedure
Dear All,
This patch was rescued from my ill-fated and long winded attempt to provide
a fix-up for function selector references, where the function is parsed
after the procedure containing the associate/select type construct (PRs
89645 and 99065). The fix-ups broke down completely once these
Hi Harald,
It might be a simple patch but I have to confess it took a while for me to
get my head around the difference between gfc_is_not_contiguous and
!gfc_is_simply_contigous :-(
Yes, this is OK for mainline and, after a short delay, for 13-branch.
Thanks for the patch
Paul
On Sat, 16
Hi Harald,
'from' is slightly better but either will be understood.
Cheers
Paul
Happy New Year to you all!
On Mon, 1 Jan 2024 at 21:25, Harald Anlauf wrote:
> Hi Thomas!
>
> Am 30.12.23 um 12:08 schrieb Thomas Koenig:
> > Replying to myself...
> >
> >
> >> I think this also desevers a
These PRs come about because of gfortran's single pass parsing. If the
function in the title is parsed after the associate construct, then its
type and rank are not known. The point at which this becomes a problem is
when expressions within the associate block are parsed. primary.cc
Hi Harald,
The original testcase is accepted by the two other brands to which I have
access.
OK for mainline and, I would suggest, 13-branch.
Thanks
Paul
On Wed, 29 Nov 2023 at 21:16, Harald Anlauf wrote:
> Dear all,
>
> the attached simple patch fixes the handling of the TARGET
>
Dear All,
I have attached a mostly completed version of the Chivers and Sleightholme
F2018 compliance table to the above PR.
For features 1.x to 6.x, I wrote explicit tests, which are also attached to
the PR.
Much of the rest, I was able to fill out by inspection of the gfortran
source or the
Hi Harald,
The patch is OK for mainline.
Thanks
Paul
On Mon, 4 Dec 2023 at 22:47, Harald Anlauf wrote:
> Dear all,
>
> the attached patch picks up an observation by Tobias that we did
> not specify the RESTRICT qualifier for optional arguments even
> if that was allowed. In principle this
Hi Andrew,
This is OK by me.
I attach a slightly edited version of the patch itself in the hope that it
will make the code a bit clearer.
Thanks and welcome!
Paul
On Mon, 27 Nov 2023 at 17:35, Andrew Jenner wrote:
> This is the second version of the patch - previous discussion at:
>
Hi All,
Evidently -w causes gfc_option.allow_std to be set to default, which allows
anything and everything to happen, including these f2003/8 finalizations.
The fix is trivial.
Regtests fine - OK for mainline and -13 branch?
Paul
Fortran: Prevent unwanted finalization with -w option
/trans-stmt.cc:2383
> [...]
>
> I don't see anything wrong with it: NAG groks it, like Nvidia and Flang,
> while Intel crashes at runtime.
>
> Can you have another brief look?
>
> Thanks,
> Harald
>
>
> On 1/6/24 18:26, Paul Richard Thomas wrote:
> > These
Hi Harald,
This all looks good to me. OK for mainline and, according to intestinal
fortitude on your part, earlier branches.
Thanks
Paul
On Tue, 5 Mar 2024 at 21:24, Harald Anlauf wrote:
> Dear all,
>
> error recovery on arithmetic errors during simplification has bugged
> me for a long
Hi Harald,
This looks good to me. OK for mainline and, since it is so straightforward,
for backporting.
Thanks for the patch.
Paul
On Mon, 11 Mar 2024 at 21:20, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes an ICE-on-valid code when assigning
> a procedure pointer that is a
Hi All,
This is the last posting of this patch before I push it. Harald is OK with
it on the grounds that the inferred_type flag guards the whole lot,
except for the chunks in trans-stmt.cc.
In spite of Harald's off-list admonition not to try to fix everything at
once, this version fixes most of
Hi Harald,
This looks good to me. The testcase gives the same result with other brands.
OK for mainline and for backporting.
Thanks
Paul
On Tue, 12 Mar 2024 at 22:12, Harald Anlauf wrote:
> Dear all,
>
> here's another small fix: IS_CONTIGUOUS did erroneously always
> return .true. for
s approach was
very clever but has found it's limit with the associate construct. The sad
thing is that this is the only blocker that I know of.
Thanks
Paul
On Tue, 12 Mar 2024 at 21:07, Harald Anlauf wrote:
> Hi Paul,
>
> On 3/12/24 15:54, Paul Richard Thomas wrote:
> > Hi All,
Hi Mikael,
This is very good. I am pleased to see global variables disappear and I
like the new helper functions.
As before, OK for mainline and, if you wish, 13-branch.
Thanks
Paul
On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote:
> This fixes a spurious invalid variable in specification
Hi Mikael,
Sorry, I am replying to these in the order that they appear in my intray :-)
OK for mainline and, if you wish, 13-branch.
Thanks
Paul
On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote:
> Hello,
>
> these patches correct diagnostics dealing with variables in specification
>
Hi Mikael,
This looks completely "obvious" to me. OK for mainline and, I would
suggest, 13-branch.
Thanks
Paul
On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote:
> This fixes invalid undeclared fortran array bound variables
> in the testsuite.
>
> gcc/testsuite/ChangeLog:
>
> *
Hi Harald,
Yes, that's a good idea. I'll take a look tomorrow morning to see what I
think needs doing and then let's put heads together.
Regards
Paul
On Sun, 24 Mar 2024 at 20:23, Harald Anlauf wrote:
> Dear all,
>
> the gfortran wiki (https://gcc.gnu.org/wiki/GFortran) seems to have been
>
Hi All,
This bug emerged in a large code and involves possible recursion with a
"hidden" module procedure; ie. where the symtree name starts with '@'. This
throws the format decoder. As the last message in the PR shows, I have
vacillated between silently passing on the possible recursion or
Hi Harald,
I have made a start on this: I have updated the text around bug reports in
the developers section, added the bugs fixed etc.. for 2022/23 and
eliminated the links to the Doxygen documentation.
The biggest part of the job will be to add "what's new" in 10-14 branches
and F2003/8/18
Hi All,
The attached patch has two elements:
(i) A fix for gimplifier ICEs with derived type having no components. The
reporter himself suggested (thanks Kirill!):
- if (derived && derived->attr.zero_comp)
+ if (derived && (derived->components == NULL))
As far as I can tell, this is the
This regression has a relatively simple fix. The passing of a subroutine
procedure pointer component to a dummy variable was being missed
completely. The error has been added. Conversely, an error was generated
for a procedure pointer variable but no use was being made of the
interface, if one was
Hi Harald,
>
> I had only a quick glance at your patch. I guess you unintentionally
> forgot to remove those parts that you already committed for PR110987,
> along with the finalize-testcases.
>
Guilty as charged. I guess I got out of the wrong side of the bed :-)
>
> I am still trying to find
Patch pushed after pre-approval by Harald on Bugzilla.
Fortran: Fix ICE in gfc_trans_pointer_assignment [PR113956]
2024-04-09 Paul Thomas
gcc/fortran
PR fortran/113956
* trans-expr.cc (gfc_trans_pointer_assignment): Remove assert
causing the ICE since it was
Hi Jerry,
It looks good to me. Noting that this is not a regression, OK for mainline
on condition that you keep a sharp eye out for any associated problems.
Likewise with backporting to 13-branch.
Thanks
Paul
On Thu, 4 Apr 2024 at 02:34, Jerry D wrote:
> Hi all,
>
> The attached log entry
Hi Harald,
This is completely fine - if you haven't committed, please do so.
Thanks
Paul
On Fri, 22 Mar 2024 at 17:32, Harald Anlauf wrote:
> Dear all,
>
> here's a simple and obvious patch for a rejects-valid case when
> we pass a NULL() actual to an optional dummy for variants where
>
Hi All,
This one is blazingly 'obvious'. I haven't had the heart to investigate why
somebody thought that it is a good idea to check if unreferenced symbols
are finalizable because, I suspect, that 'somebody' was me. Worse, I tried
a couple of other fixes before I hit on the 'obvious' one :-(
Hi Harald,
Thanks for the thumbs-up. Committed as
3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6.
I will backport to 13-branch in a couple of weeks.
Best regards
Paul
On Thu, 28 Mar 2024 at 22:27, Harald Anlauf wrote:
> ...snip...
> yes, this looks good here.
>
> ...snip...
The patch looks
Hi All,
This patch corrects incorrect results from assignment of unlimited
polymorphic function results both in assignment statements and allocation
with source.
The first chunk in trans-array.cc ensures that the array dtype is set to
the source dtype. The second chunk ensures that the lhs _len
This ICE was caused by my patch r14-9489-g3fd46d859cda10. However, the ICE
hid a wrong error going back to at least 6.4.1 20180703. The patch fixes
both and exposed incorrect error messages in existing tests in gfortran.dg.
The fix for these was to add 'IMPLICIT NONE' in call cases so that there
Hi All,
This is a more or less obvious patch. The action is in resolve.cc. The
chunk in symbol.cc is a tidy up of a diagnostic marker to distinguish where
the 'no IMPLICIT type' error was coming from and the chunk in trans-decl.cc
follows from discussion with Harald on the PR.
Regtests fine. OK
Hi Harald,
>
> the patch is OK, but I had to manually fix it. I wonder how you managed
> to produce:
>
Yes, I had to use --whitespace fix when I reapplied it a few minutes ago.
>
> diff --git a/gcc/testsuite/gfortran.dg/pr93484.f90
>
I had followed comment 1 in the PR and wrongly named the
>
>
> Hi Harald,
> Indeed, the gfc_fatal_error always wins.
:-(
>
> This PR is marked as a regression. Depending on your progress,
> it might be worth to consider fixing what you think is needed
> to get rid of the regression marker and defer the improvement
> of the diagnostics to a second
Hi All,
Jakub pinpointed the source of this bug in comment 6 of the PR. The rest
was 'obvious' :-)
I plan to push the patch to mainline in the next 24 hours unless there are
opinions to the contrary. Backporting is proposed to occur a couple of
weeks later.
Best regards
Paul
Fortran: Generate
PS ignore the chunk in trans-array.cc. It is an attempt to fix PR93678 that
literally did nothing.
Paul
On Wed, 24 Apr 2024 at 07:05, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi,
>
> The linaro pre-commit error testing picked up errors for arm and aarch
&
more.
Paul
On Tue, 23 Apr 2024 at 16:25, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> Jakub pinpointed the source of this bug in comment 6 of the PR. The rest
> was 'obvious' :-)
>
> I plan to push the patch to mainline in the next 24 hours unl
Hi there,
This regression turned out to be low hanging fruit, although it has taken
four years to reach it :-(
The ChangeLog says it all. OK for mainline and backporting after a suitable
delay?
Paul
Fortran: Fix ICE in gfc_trans_create_temp_array from bad type [PR93678]
2024-04-24 Paul
Hi Harald,
This patch is verging on 'obvious', . once one sees it :-)
Yes, it's good for mainline and all active branches, when available.
Thanks
Paul
PS The fall-out pr114874 is so peculiar that I am dropping everything to
find the source.
On Mon, 29 Apr 2024 at 19:39, Harald Anlauf
Hi All,
Could this be looked at quickly? The timing of this regression is more than
a little embarrassing on the eve of the 14.1 release. The testcase and the
comment in gfc_trans_class_init_assign explain what this problem is all
about and how the patch fixes it.
OK for 15-branch and
40 40 4 5$
> >abcdefghij^@^@^@^@^@^@^@^@^@^@<$
>
> So since the physical representation of chr_a is sufficient
> to hold star_a (F2023:16.9.212), no reallocation with a wrong
> calculated size should happen. (Intel and NAG get this right.)
>
.
A resubmission of the patch for PR113363 will follow since it depends on
this one to fix all the memory problems.
OK for mainline?
Regards
Paul
On Thu, 9 May 2024 at 08:52, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> The Linaro people caught that
Hi Harald,
Please find attached my resubmission for pr113363. The changes are as
follows:
(i) The chunk in gfc_conv_procedure_call is new. This was the source of one
of the memory leaks;
(ii) The incorporation of the _len field in trans_class_assignment was done
for the pr84006 patch;
(iii) The
Hi Mikael,
That is an ingenious solution. Given the complexity, I think that the
comments are well warranted.
OK for master and, I would suggest, 14-branch after a few weeks.
Thanks!
Paul
On Sun, 12 May 2024 at 14:16, Mikael Morin wrote:
> Hello,
>
> Here is my final patch to fix the ICE of
Hi All,
I have been around several circuits with a patch for this regression. I
posted one in Bugzilla but rejected it because it was not direct enough.
This one, however, is more to my liking and fixes another bug lurking in
the shadows.
The way in which select type has been implemented is a
:
> Hello,
>
> Le 28/04/2024 à 23:37, Paul Richard Thomas a écrit :
> > Hi All,
> >
> > Could this be looked at quickly? The timing of this regression is more
> > than a little embarrassing on the eve of the 14.1 release. The testcase
> > and the comment in g
Hi Harald,
Please do commit, with or without the extra bit for the function result.
As well as having to get back to pr113363, I have patches in a complete
state for pr84006 and 98534. However they clash with yours. You arrived at
the head of the queue first and so after you :-)
Regards
Paul
This fix is straightforward and described by the ChangeLog. Jose Rui
Faustino de Sousa posted the same fix for the ICE on the fortran list
slightly more than three years ago. Thinking that he had commit rights, I
deferred but, regrettably, the patch was never applied. The attached patch
also fixes
Hi Harald,
You were absolutely right about returning 'false' :-) The patch is duly
corrected.
Committed to mainline and will be followed by backports in a few weeks.
Regards
Paul
On Tue, 21 May 2024 at 19:58, Harald Anlauf wrote:
> Hi Paul,
>
> Am 20.05.24 um 11:06 schrieb Pau
Hi All,
I don't think that this PR is really a regression although the fact that it
is marked as such brought it to my attention :-)
The fix turned out to be remarkably simple. It was found after going down a
silly number of rabbit holes, though!
The chunk in dependency.cc is probably more
Hi Jose and Tobias,
I am glad that you produced the list of patches waiting for approval. I
have been out of action following a house move and will likely not be doing
any reviewing or contributing for another month or so. As soon as I am
ready, I will make use of this list to check out what has
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 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,
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, PR99819
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!
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.
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
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
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 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)
Hi Dominique,
What I meant was a test that would confirm the fix on all targets.
BTW thanks for testing the patch!
A
Paul
On Fri, 26 Mar 2021 at 17:29, wrote:
> Hi Paul,
>
> I have your first patch in my working tree for some time. It works as
> expected without breaking anything in my own
> Hence:
> - Please include the attached testcases or some variants of them.
> - Check that removing !UNLIMITED_POLY does not cause any regressions
>
> If that works: OK for mainline
>
> Thanks for looking into this issue and working on the patches.
>
> Tobias
>
>
Hi Tobias,
I took something of a detour in reviewing this patch. Although short,
understanding it is not straightforward!
Your patch works as advertised and regtests OK (with the patch for PR93660
on board as well). Is NULL the only case where this can happen?
Just to aid my understanding, I
Cancel the thought on my patchlet null_5.f90 fails on excess errors.
Paul
On Tue, 23 Mar 2021 at 17:34, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Tobias,
>
> I took something of a detour in reviewing this patch. Although short,
> understanding it is n
This patch is straightforward but the isolation of the problem was rather
less so. Many thanks to Juergen for testcase reduction.
Regtested on FC33/x86_64 - OK for master?
Paul
Fortran: Fix problem with runtime pointer chack [PR99602].
2021-03-26 Paul Thomas
gcc/fortran/ChangeLog
PR
Hi Tobias,
Please go ahead and commit the patch. I think that your analysis is correct
about expr_null and that your patch is the best way to deal with the
problem.
Best regards
Paul
On Tue, 23 Mar 2021 at 17:54, Tobias Burnus wrote:
> Hi Paul,
>
> On 23.03.21 18:34, Paul Richa
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
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
:
> 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 Tobias,
I'll do the reviews for you tomorrow morning. Right now my brain has turned
to mush after an excess of online meetings :-(
I'll take a look through my PRs to see what might need pushing onto
10-branch.
Cheers
Paul
On Fri, 19 Mar 2021 at 14:15, Tobias Burnus wrote:
> FYI.
>
> On
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
Pushed to master in commit 9a0e09f3dd5339bb18cc47317f2298d9157ced29
Thanks
Paul
On Wed, 14 Apr 2021 at 14:51, Tobias Burnus wrote:
> On 11.04.21 09:05, Paul Richard Thomas wrote:
> > Tobias noticed a major technical fault with the resubmission below: I
> > forgot to a
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
amp;& (gfc_option.allow_std & GFC_STD_F2003))
return;
Modify or replace the comment, as desired. The change to the condition
gives the desired result in terms of standard compliance.
Regards
Paul
On Fri, 16 Apr 2021 at 09:32, Paul Richard Thomas <
paul.richard.tho...@g
Hi All,
Harald, that is to say the least of it an elegant and minimalist fix. With
the patch applied, gfortran behaves like the "other brand" and regtests OK.
Bernhard correctly points out that there should be a comment. Not only
this, there must be an F2003 standard check, since F95 forbids
aul,
>
> 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
1: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 (only) on mainline!
> >
>
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
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 <
fortran@gcc.gnu.org> wrote:
> Hi All!
>
> Proposed patch to:
> PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS
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 Andrew,
Not long before I had to step aside (temporarily, I hope) from gfortran
maintenance, I made quite a lot of progress on missing finalizations. I'll
dig out the in-progress patch for you and remind myself of the remaining
issues. One of these was a standards problem, where the patched
Hi Harald,
The overfilled constructor in transfer_simplify_2.f90 is indeed an error.
The error is picked up correctly for arrays in
expr.c(gfc_check_conformance):3579 but not for array components.
Regards
Paul
On Thu, 14 Oct 2021 at 10:26, Tobias Burnus wrote:
> Dear all, hello Harald,
>
>
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 - 100 of 219 matches
Mail list logo
