Hi All,
The moment I saw the DIN4 proposal for "Generic processing of assumed rank
objects", I thought that this was a highly intuitive and implementable
proposal. I implemented a test version in June and had some correspondence
with Reinhold Bader about it shortly before he passed away.
Malcolm
Hi All,
The moment I saw the DIN4 proposal for "Generic processing of assumed rank
objects", I thought that this was a highly intuitive and implementable
proposal. I implemented a test version in June and had some correspondence
with Reinhold Bader about it shortly before he passed away.
Malcolm
Hi Graziano,
I think that you will find https://gcc.gnu.org/wiki/GFortranBinaries to be
helpful.
Regards
Paul
On Mon, 16 Sept 2024 at 18:56, graziano genuini wrote:
> Dear Programmer,
>I would like to use The GNU Fortran Compiler.
> What do I have to do?
> Looking forward to hearing from
Hi All,
This correspondence touches on something that I was going to raise - how do
we incorporate experimental F202Y features?
The reason that I ask is that Reinhold Bader proposed extensions to the
processing of assumed rank objects, which became a DIN proposal to WG5 -
see attached. It made so
Hi Steve,
Thanks for doing the review. If it's good enough for you, it is certainly
good enough.
Many thanks to you too, Thomas.
Regards
Paul
On Fri, 6 Sept 2024 at 20:02, Steve Kargl
wrote:
> On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
> > Hello world,
> >
> > this versi
Hi Steve,
Thanks for doing the review. If it's good enough for you, it is certainly
good enough.
Many thanks to you too, Thomas.
Regards
Paul
On Fri, 6 Sept 2024 at 20:02, Steve Kargl
wrote:
> On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
> > Hello world,
> >
> > this versi
Hi Harald,
The invalid testcase is posted as PR116543. I plan to hit PDTs in the
second half of September, when daytime work will lighten up a bit.
Cheers
Paul
On Fri, 30 Aug 2024 at 17:28, Harald Anlauf wrote:
> Hi Paul,
>
> Am 30.08.24 um 18:09 schrieb Paul Richard Thomas:
>
Hi Harald,
The patch is good for mainline.
The PDT testcase is invalid because the component has a fixed length
initializer, while its length is a len parameter. One of the fixes that I
will have to do in the PDT revamp. Ignore it for now.
Thanks for the patch.
Paul
On Thu, 29 Aug 2024 at 2
Hi Harald,
The patch is good for mainline.
The PDT testcase is invalid because the component has a fixed length
initializer, while its length is a len parameter. One of the fixes that I
will have to do in the PDT revamp. Ignore it for now.
Thanks for the patch.
Paul
On Thu, 29 Aug 2024 at 2
Hi All,
Since the patch for PR102689 was committed, sporadic time outs at -O1 have
been recorded and so I have reverted the patch.
This is a bit awkward because I have yet to see the problem. However, I
will endeavour to understand what went wrong.
Paul
-- Forwarded message -
Fr
Indeed - thanks, Jerry.
I haven't had enough bandwidth to support gfortran these last few weeks and
will only be able to return to normal service in a couple of weeks.
Cheers
Paul
On Wed, 21 Aug 2024 at 08:42, Andre Vehreschild wrote:
> Hi Jerry,
>
> thank you for the review. Committed as gc
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,
>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
/
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
/
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
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
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
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
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 Thomas,
Welcome back!
I was going to propose that we introduce -std=f2028 and to allow proposed
features to be run only if that option is selected; ie. not by default or
-std=gnu. gfortran.dg should have an f2028 directory as well.
I have already written and tested a patch for Reinhold Bader'
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
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
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,
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 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 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
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.
&
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.
&
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,
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
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
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 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,
> + /* 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 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 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,
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 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 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,
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 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 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 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 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 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
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
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
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*)
>
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*)
>
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
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
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 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 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,
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
, Thiago Jung Bauermann <
thiago.bauerm...@linaro.org> wrote:
> Hello Paul,
>
> Paul Richard Thomas writes:
>
> > Thank you very much for your debugging efforts. You really pulled out
> the stops.
>
> You're welcome. In the future if there are other issues or que
, Thiago Jung Bauermann <
thiago.bauerm...@linaro.org> wrote:
> Hello Paul,
>
> Paul Richard Thomas writes:
>
> > Thank you very much for your debugging efforts. You really pulled out
> the stops.
>
> You're welcome. In the future if there are other issues or que
Hi Thiago,
Thank you very much for your debugging efforts. You really pulled out the
stops.
Can I take it then that you will update the toolchain system wide so that I
can commit the patch without triggering you every night? It would be a pity
to XFAIL it after your efforts.
I thought that since
Hi Thiago,
Thank you very much for your debugging efforts. You really pulled out the
stops.
Can I take it then that you will update the toolchain system wide so that I
can commit the patch without triggering you every night? It would be a pity
to XFAIL it after your efforts.
I thought that since
Hi There,
I have been withholding the commit of this patch until I hear from you.
Regards
Paul
On Tue, 2 Jul 2024 at 08:48, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi there,
>
> You detected a failure in gfortran.dg/class_transformational_2.f90:
>
ul 2024 at 11:20, Andre Vehreschild wrote:
> Hi Paul,
>
> please, please, please let me know what the cause was. I have a similar
> error
> that my testcase fails, but for -O2, -O3 and -Os, which I have not figured
> yet.
>
> - Andre
>
> On Tue, 2 Jul 2024 11:
Hi Andre,
I have to hold back on the commit until the business below is sorted out.
Cheers
Paul
-- Forwarded message -
From: Paul Richard Thomas
Date: Tue, 2 Jul 2024 at 08:48
Subject: [Linaro-TCWG-CI] gcc patch #93154: FAIL: 1 regressions on arm
To:
Hi there,
You
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 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 there,
You detected a failure in gfortran.dg/class_transformational_2.f90:
PASS: gfortran.dg/class_transformational_2.f90 -O0 (test for excess
errors)
PASS: gfortran.dg/class_transformational_2.f90 -O0 execution test
PASS: gfortran.dg/class_transformational_2.f90 -O1 (test for excess
e
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 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
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
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 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,
>
>
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,
>
>
his looks fine. Thanks for the patch. Me having been away for some
> time
> from gfortran, I recommend you wait for Harald's ok, too.
>
> Regards,
> Andre
>
> On Thu, 13 Jun 2024 22:43:03 +0100
> Paul Richard Thomas wrote:
>
> > Hi Both,
> >
>
& 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
& 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
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
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
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
&
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
&
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 so
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 so
this
another day.
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
this
another day.
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
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.)
>
&
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.)
>
&
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
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
1 - 100 of 1007 matches
Mail list logo
