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
. 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
> 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 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
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 arr
>
> 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,
>
Thanks, Jerry.
On Wed, 4 Jul 2018 at 19:14, Jerry DeLisle wrote:
>
> This patch committed as obvious after regression testing and auditing
> the code. New test case added.
>
> Author: jvdelisle
> Date: Wed Jul 4 18:08:16 2018
> New Revision: 262416
>
> URL: https://gcc.gnu.org/viewcvs?rev=262416
The comment in the patch says it all.
Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
Paul
2018-07-05 Paul Thomas
PR fortran/66679
* trans-intrinsic.c (gfc_conv_intrinsic_transfer): Class array
elements are returned as references to the data element. Get
the class e
Ping!
On Thu, 5 Jul 2018 at 08:51, Paul Richard Thomas
wrote:
>
> The comment in the patch says it all.
>
> Bootstrapped and regtested on FC28/x86_64 - OK for trunk?
>
> Paul
>
> 2018-07-05 Paul Thomas
>
> PR fortran/66679
> * trans-intrinsic.c (gf
Several attempts, including mine, were made to fix this bug since it
was posted. They were all attacking the wrong place. Instead of
providing the free of the class _data as part of the call to
'add_a_type' it should be included in the post block of the argument
processing in the call to 'assign_a_
Daniel Celis Garza and Damian Rouson have developed a runtime library
and include file for the TS 29113 and F2018 C descriptors.
https://github.com/sourceryinstitute/ISO_Fortran_binding
The ordering of types is different to the current 'bt' enum in
libgfortran.h. This patch interchanges BT_DERIVED
Hi Richard,
Ah yes, you are absolutely right. I will sit on it for a bit and do
the interchange at the descriptor conversion stage for now.
Thanks
Paul
On Tue, 31 Jul 2018 at 15:57, Richard Biener wrote:
>
> On Tue, Jul 31, 2018 at 2:07 PM Paul Richard Thomas
> wrote:
> >
&
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
expressi
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 be
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 expr
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
ch
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 gfc_intrin
* 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 explana
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
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 generate_error
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
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***
>
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 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,
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
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,
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
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 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
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:
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
rtran/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:
>
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 time
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 c
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
;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:
> &g
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 CLAS
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:
>
> * gfort
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
> express
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 e
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
> ther
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 corre
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 rathe
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 adding
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
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 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 an
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 :-(
The
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 unnecesary
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 f
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 Dec
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
(gfc_match_vars
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 m
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 const
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 [PR112459]
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:
> https:/
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
> attribute
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
hes.
>
> Regards,
> Andre
>
> PS. I have attached them in plain text and as archive to prevent mailers
> from
> corrupting them.
>
> On Thu, 20 Jun 2024 07:42:31 +0100
> Paul Richard Thomas wrote:
>
> > Hi Andre,
> >
> > Both this patch
Hi All,
This is one of those PRs where one thing led to another I think that
the patch is pretty complete and, while apparently quite heavy, is more or
less self explanatory through comments and the ChangeLog.
The first testcase concentrates on reshape in various guises, while the
second deal
Hi Andre,
Thank you for the review.
> ...snip...
>
> I am confused here, because you are assigning to rhs. When that is
> correct, why
> is there no else assigning zero to the rhs->_len when arg1 is not
> unlimited?
'rhs_class_expr' is highly confusing and came from the original use of this
pa
Hi All,
After messing around with argument mapping, where I found and fixed another
bug, I realised that the problem lay with simplification of len_trim with
an argument that is the element of a parameter array. The fix was then a
straightforward lift of existing code in expr.cc. The mapping bug i
Hi All,
Harald has pointed out that I attached the ChangeLog twice and the patch
not at all :-(
Please find the patch duly attached.
Paul
On Sat, 13 Jul 2024 at 10:58, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> After messing around with argument
Hi Mikael,
The fix is blindingly obvious :-) Not only that, the failing testcase runs
correctly.
OK for mainline and please backport to 14-branch before the 14.2 release.
Thanks for the patch
Paul
On Sat, 13 Jul 2024 at 10:48, Mikael Morin wrote:
> From: Mikael Morin
>
> Hello,
>
> I'm cur
ns-array.cc:483
> 0x243e156 internal_error(char const*, ...)
> ../../gcc-trunk/gcc/diagnostic-global-context.cc:491
> 0x96dd70 fancy_abort(char const*, int, char const*)
> ../../gcc-trunk/gcc/diagnostic.cc:1725
> 0x749d68 gfc_conv_descriptor_stride_get(tree_node*, tree_node*)
>
I've done it again! Patch duly added.
Paul
On Mon, 15 Jul 2024 at 09:21, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> Thank you for the review and for the testing to destruction. Both issues
> are fixed in the attached patch. Note the new f
Hi All,
I am not sure that I understand why this bug occurs. The regression was
introduced by my patch that had gfc_trans_class_init_assign return
NULL_TREE, when all the components of the default initializer are NULL.
Note that this only afflicts scalar dummy arguments.
With pr115070:
void my_su
Hi Harald,
Pushed as r15-2072. I will wait a few days before backporting but I would
be surprised if there are any problems simply because the bug prevented the
code patch from doing anything than ICE.
In answer to some of your latest points:
>
> >> Can we prevent the export of this artificial s
Hi Andre,
It looks good to me. I am happy to see that the principle of the patch has
Richi's blessing too.
OK for mainline. I leave it for you (and Richi?) to decide whether to
backport in time for the 14.2 release.
Regards
Paul
On Wed, 17 Jul 2024 at 14:08, Andre Vehreschild wrote:
> Hi al
Hi All,
This patch is simple and well described by the ChangeLogs and the comments.
Regtests OK.
OK for mainline and backporting?
Cheers
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index ed1213a41cb..c1fb896f587 100644
--- a/gcc/fortr
Hi Andre,
The code is standard boilerplate in handling arrays and looks OK to me.
That said, I know next to nothing about the handling of co-arrays in
gfortran. I hope that others can pick up anything that I have missed.
Since you are likely to produce a stream (and have already) of co-array
patc
Hi Andre,
> + /* Mark so that rhs "used unallocated" warnings can be issued.
> Component
> +references do not generate the warnings. */
> + for (ref = expr1->ref; ref; ref = ref->next)
> + if (ref->type == REF_COMPONENT)
> + break;
>
Good spot - I had gone blind
Hi Haochen,
Try removing lines 37-41 since these are precisely the bogus warnings that
the patch is meant to eliminate.
Regards
Paul
On Thu, 18 Jul 2024 at 14:38, haochen.jiang
wrote:
> On Linux/x86_64,
>
> c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc is the first bad commit
> commit c3aa339ea50f
Hi Andre,
While I realise that this is not your doing, should we not
check DECL_LANG_SPECIFIC ()) before touching GFC_DECL_SAVED_DESCRIPTOR? Or
is access guaranteed by the REF_COMPONENT check?
A micro-nit line 12 s/User/Use/
Apart from this, it looks to be eminently obvious. OK for mainline.
Pa
90"
>
>
>
> After the change, all the tests are passed. However, is that right?
>
>
>
> I am not familiar with either Fortran or libgomp, but the warning
>
> like something declared here which might report variable declaration
>
> conflict seems needed.
&
Hi Andre,
The patch looks fine to me. Please add the original testcase as
pr88624.f90, since it can be a compile only. The addition to
coarray/dummy_1.f90 is fine as well but I think that it is good to address
the reporter's problem directly.
Thanks
Paul
On Wed, 17 Jul 2024 at 14:10, Andre Veh
Hi All,
Ping!
I understand now why this works. The scope of the block is merged and so
all the previous declarations that would otherwise disappear are added,
even by the empty statement.
Regards
Paul
On Mon, 15 Jul 2024 at 17:10, Paul Richard Thomas <
paul.richard.tho...@gmail.com>
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 bit
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 elabo
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 s
Hi Andre,
>From a very rapid scan(in the style of somebody on vacation :-) ) of the
two patches, it all looks good to me. Adding the corank structure to
gfc_expr is long overdue. Thanks also for rolling select type into the
second patch. It would be good if you would check if PRs 46371 and 56496
a
Hi Andre,
I apologise for the slow response. It's been something of a heavy week...
This is good for mainline.
Thanks
Paul
PS That's good news about the funding. Maybe we will get to see "built in"
coarrays soon?
On Tue, 4 Jun 2024 at 11:25, Andre Vehreschild wrote:
> Hi all,
>
> attached
Hi Andre,
I had been working in exactly the same area to correct the implementation
of finalization of function results in array constructors. However, I
couldn't see a light way of having the finalization occur at the correct
time; "If an executable construct references a nonpointer function, the
Hi All,
The attached fixes a problem that, judging by the comments, has been looked
at periodically over the last ten years but just looked to be too
fiendishly complicated to fix. This is not in small part because of the
confusing ordering of dummies in the tlink chain and the unintuitive
placeme
quot;) stop 15
end program p
On Sun, 9 Jun 2024 at 07:14, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> The attached fixes a problem that, judging by the comments, has been
> looked at periodically over the last ten years but just looked to be too
&
t; 0 0 3
>
> Expected:
>
> 2 3 3
>
> Can you please check?
>
> Thanks,
> Harald
>
>
> Am 09.06.24 um 17:57 schrieb Paul Richard Thomas:
> > Hi All,
> >
> > I have extended the testcase - see
& sym->ts.u.cl->length
> + && sym->ts.u.cl->length->expr_type != EXPR_CONSTANT)
> + front = gfc_traverse_expr (sym->ts.u.cl->length, proc_name,
> + dependency_fcn, 0);
>
> This can overwrite a previous fron
Hi Andre,
The patch is OK for mainline. Please change the subject line to have
[PR90076] at the end. I am not sure that the contents of the first square
brackets are especially useful in the commit.
Thanks for the fix
Paul
On Tue, 11 Jun 2024 at 13:57, Andre Vehreschild wrote:
> Hi all,
>
>
After an OK from Harald,
commit r15-2187-g838999bb23303edc14e96b6034cd837fa4454cfd
Author: Paul Thomas
Date: Sun Jul 21 17:48:47 2024 +0100
Fortran: Fix regression caused by r14-10477 [PR59104]
2024-07-21 Paul Thomas
gcc/fortran
PR fortran/59104
* gfort
This patch is straightforward but I am still puzzled as to why it is
necessary for the particular case. Having looked at all the other chunks of
frontend code involving use renaming, it seems that the process just works
everywhere else. I tried putting the new code in gfc_find_symtree but it
caused
Hi Mikael,
You were absolutely right. I looked at the caller and "just didn't get it".
Thanks. I will resubmit when I get back from a business trip.
Cordialement
Paul
On Sat, 27 Jul 2024 at 12:35, Mikael Morin wrote:
> Hello,
>
> Le 27/07/2024 à 11:25, Pau
/
PR fortran/79685
* gfortran.dg/use_rename_12.f90: New test.
On Sat, 27 Jul 2024 at 22:04, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Mikael,
>
> You were absolutely right. I looked at the caller and "just didn't get
> it". Thanks. I wil
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
re
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 f
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 fil
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
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
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
>
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 Thomas
1 - 100 of 1282 matches
Mail list logo
