Hi All,
Recently a lot of work has been done on the "partial" or "no"s in the F2008
and F2018 implementation statuses.
Please send me updates and I will do the editing in time for the gcc-15
release.
Thanks
Paul
Hi All,
Now that the reduce intrinsic seems to be OK on all platforms, I thought
that it was time to catch up with the documentation.
The attached produces good .html without any additional warnings or errors
using texi2any and ~/share/info/gfortran.info is as intended.
OK for mainline?
Paul
di
Hi All,
Now that the reduce intrinsic seems to be OK on all platforms, I thought
that it was time to catch up with the documentation.
The attached produces good .html without any additional warnings or errors
using texi2any and ~/share/info/gfortran.info is as intended.
OK for mainline?
Paul
di
Hi Andre and Mikael,
The associate block is added *after* the associate statement is matched and
the associate_names added to the parent namespace; see
parse.cc(parse_associate).
nagfor and flang-new both behave in the same way as gfortran. So ifort and
ifx are the odd ones out.
In F2018 and F20
Hi Andre,
On Mon, 7 Apr 2025 at 07:29, Andre Vehreschild wrote:
> Hi Paul,
>
> shouldn't this be done in iresolve.cc to make other parts of gfortran
> benefit
> from learning, that the sym is allocatable?
>
> I'll give it a try. I was attempting to eliminate any wider side effects
by setting the
Hi Andre,
On Mon, 7 Apr 2025 at 07:29, Andre Vehreschild wrote:
> Hi Paul,
>
> shouldn't this be done in iresolve.cc to make other parts of gfortran
> benefit
> from learning, that the sym is allocatable?
>
> I'll give it a try. I was attempting to eliminate any wider side effects
by setting the
Hi All,
As far as I can tell, the attached patch fixes the problems with the reduce
intrinsic. I would be grateful to the reporters if they would confirm that
this is the case.
The key to the fix appears in reduce_3.f90, which failed even with -m64.
Although it was not apparent from the tree dump
Hi All,
As far as I can tell, the attached patch fixes the problems with the reduce
intrinsic. I would be grateful to the reporters if they would confirm that
this is the case.
The key to the fix appears in reduce_3.f90, which failed even with -m64.
Although it was not apparent from the tree dump
Hi Andre,
I am reasonably familiar with the mess that is gfc_conv_procedure_call :-)
So in spite of you having a hard time explaining things today, I see your
patch as verging on 'obvious' and is certainly the best that can be done
without refactoring the whole thing.
OK fo mainline.
Thanks for
, Christophe Lyon
wrote:
> On Thu, 3 Apr 2025 at 17:55, Paul Richard Thomas
> wrote:
> >
> > Hi Christophe,
> >
> > As far as I can tell, the problem with reduce_1.f90 is restricted to one
> call to the scalar valued version of the new intrinsic function. When
goes away for you. In either case, I will seek Jakub
Jelnik's help because I have completely run out of ideas.
Je vous en remercie d'avance.
Paul
On Wed, 2 Apr 2025 at 10:12, Christophe Lyon
wrote:
> Hi!
>
> On Wed, 19 Mar 2025 at 19:22, Paul Richard Thomas
> w
drawn a total blank with finding a fix. If necessary, I will
comment out the offending test.
Best regards
Paul
On Wed, 2 Apr 2025 at 10:12, Christophe Lyon
wrote:
> Hi!
>
> On Wed, 19 Mar 2025 at 19:22, Paul Richard Thomas
> wrote:
> >
> > Hi Andre,
> >
> >
Hello there,
You had previously warned me of the problem with the pre-commit patch, from
which I was able to identify the problem. Unfortunately, I screwed up by
only correcting the cast of 'dim' in three out of four places. Hans-Peter
Nilsson has put it right and I believe that the regression wil
Hello Hans-Peter,
Many thanks for that. The folk at Linaro posted a testsuite failure for the
submitted patch. I corrected three of the casts but, as you found, somehow
the fourth escaped me. Linaro notified me that the pushed version was
failing and it was my intention to attend to that today. Yo
Hi Andre,
I am reasonably familiar with the mess that is gfc_conv_procedure_call :-)
So in spite of you having a hard time explaining things today, I see your
patch as verging on 'obvious' and is certainly the best that can be done
without refactoring the whole thing.
OK fo mainline.
Thanks for
Hi Andre,
Gosh, that's a mighty complicated patch :-) I suggest changing the comment
in the test case:
s/Check that components of procedure pointer aren't freeed./Do not free
procedure pointer components/ or some such.
OK for mainline and, I propose, 14-branch.
Regards and thanks
Paul
On Fri
Hi Andre,
Gosh, that's a mighty complicated patch :-) I suggest changing the comment
in the test case:
s/Check that components of procedure pointer aren't freeed./Do not free
procedure pointer components/ or some such.
OK for mainline and, I propose, 14-branch.
Regards and thanks
Paul
On Fri
t; w/o producing
> to
> many merge conflicts.
>
> Thanks again and regards,
> Andre
>
> On Wed, 19 Mar 2025 10:51:49 +
> Paul Richard Thomas wrote:
>
> > Hi Andre and Harald,
> >
> > It looks good to me too.
> >
> > Indeed, the associat
utable stack when working in
> OpenCoarrays, but haven't had time (or desire) to look into it. I will put
> myself into CC of the pr Jerry mentioned.
>
> Besides the mentions above, this looks good to me.
>
> Thanks for the patch and
>
> Regards,
> Andre
>
&
utable stack when working in
> OpenCoarrays, but haven't had time (or desire) to look into it. I will put
> myself into CC of the pr Jerry mentioned.
>
> Besides the mentions above, this looks good to me.
>
> Thanks for the patch and
>
> Regards,
> Andre
>
&
Hi Andre and Harald,
It looks good to me too.
Indeed, the associate construct is a strange one since TKR guessing is done
at a very early stage so that the associate block can be parsed. About a
year ago, I started looking at tackling this by delaying parsing the blocks
until the containing block
Hi Andre and Harald,
It looks good to me too.
Indeed, the associate construct is a strange one since TKR guessing is done
at a very early stage so that the associate block can be parsed. About a
year ago, I started looking at tackling this by delaying parsing the blocks
until the containing block
Hi All,
This version of the REDUCE intrinsic patch has evolved somewhat since the
posting on 2nd March. The most important changes are to the wrapper
function and the addition of two testsuite entries.
The wrapper function now effects:
subroutine wrapper (a, b, c)
type_of_ARRAY, inte
Hi All,
This version of the REDUCE intrinsic patch has evolved somewhat since the
posting on 2nd March. The most important changes are to the wrapper
function and the addition of two testsuite entries.
The wrapper function now effects:
subroutine wrapper (a, b, c)
type_of_ARRAY, inte
Hi Thomas,
It looks good to me. Thanks for the patch.
Regards
Paul
On Sat, 15 Mar 2025 at 15:15, Thomas Koenig wrote:
> Hello world,
>
> the attached patch, tested with "tidy -e", puts the two parts
> mentioning UNSSIGNED into a single paragraph, mentions
> extensions to -fc-prototypes and m
Hi Thomas,
It looks good to me. Thanks for the patch.
Regards
Paul
On Sat, 15 Mar 2025 at 15:15, Thomas Koenig wrote:
> Hello world,
>
> the attached patch, tested with "tidy -e", puts the two parts
> mentioning UNSSIGNED into a single paragraph, mentions
> extensions to -fc-prototypes and m
Hi Andre,
Thanks for all these comments, aka early review:
>
> + if (formal->sym->attr.allocatable || formal->sym->attr.allocatable
> + || formal->sym->attr.pointer || formal->sym->attr.pointer
> + || formal->sym->attr.optional || formal->sym->attr.optional
> + || formal->sym->ts
Hi Andre,
You beat me to it! I had just noticed the missing indirect reference. Yes,
this is good for mainline and backporting to 14-branch at very least.
Thanks for the patch. If you want to do the push to mainline, I will do the
backporting if you like? I'll not be back at base for a little whi
Hi Andre,
You beat me to it! I had just noticed the missing indirect reference. Yes,
this is good for mainline and backporting to 14-branch at very least.
Thanks for the patch. If you want to do the push to mainline, I will do the
backporting if you like? I'll not be back at base for a little whi
Hi All,
This is very much an early version of the F2018 REDUCE intrinsic. I am
posting it now because I have totally forgotten how to include new
functions in libgfortran.so. -static-libfortran works fine and the results
are the same as the other brands.
At present, it produces several of link wa
Hi Andre,
This looks fine to me. You say that this is a regression. How far back does
it go?
OK for mainline and, if required, for backporting.
Thanks for the patch.
Paul
On Fri, 28 Feb 2025 at 15:54, Andre Vehreschild wrote:
> Hi all,
>
> on this regression I had to chew a longer time. Ass
Hi Andre,
This looks fine to me. You say that this is a regression. How far back does
it go?
OK for mainline and, if required, for backporting.
Thanks for the patch.
Paul
On Fri, 28 Feb 2025 at 15:54, Andre Vehreschild wrote:
> Hi all,
>
> on this regression I had to chew a longer time. Ass
* ve...@gmx.de
>
> Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas <
> paul.richard.tho...@gmail.com>:
>
>> This regression must have been generated during my ASSOCIATE campaign; I
>> am not sure when or where. Fortunately the fix is extremely simple and is
>
* ve...@gmx.de
>
> Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas <
> paul.richard.tho...@gmail.com>:
>
>> This regression must have been generated during my ASSOCIATE campaign; I
>> am not sure when or where. Fortunately the fix is extremely simple and is
>
This regression must have been generated during my ASSOCIATE campaign; I am
not sure when or where. Fortunately the fix is extremely simple and is
explained in the ChangeLog.
Regression tests fine. OK for both affected branches?
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran
This regression must have been generated during my ASSOCIATE campaign; I am
not sure when or where. Fortunately the fix is extremely simple and is
explained in the ChangeLog.
Regression tests fine. OK for both affected branches?
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran
Hi All,
This PR was fixed by the patch for PR109066. I have had the attached
testcase in my tree for more than a week now and I propose to push it
tomorrow, unless there are any objections.
The reporter has requested that the patch be backported. Neither PR is a
regression and component defined a
Hi All,
Pushed as an 'obvious' one-liner(less additional comments) in r15-7224
Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640]
2025-01-27 Paul Thomas
gcc/fortran
PR fortran/118640
* resolve.cc (generate_component_assignments): Make sure that
the rhs temporary does not
Hi All,
Pushed as an 'obvious' one-liner(less additional comments) in r15-7224
Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640]
2025-01-27 Paul Thomas
gcc/fortran
PR fortran/118640
* resolve.cc (generate_component_assignments): Make sure that
the rhs temporary does not
;s just from reading the code, so if you think
> that
> can not happen, feel free to commit w/o the assert.
>
> Regards,
> Andre
>
> On Wed, 22 Jan 2025 14:03:15 +
> Paul Richard Thomas wrote:
>
> > Hi All,
> >
> > This patch fixes a double I
;s just from reading the code, so if you think
> that
> can not happen, feel free to commit w/o the assert.
>
> Regards,
> Andre
>
> On Wed, 22 Jan 2025 14:03:15 +
> Paul Richard Thomas wrote:
>
> > Hi All,
> >
> > This patch fixes a double I
Hi All,
This patch fixes a double ICE arising from confusion between the dummy
symbol arising from a module function/subroutine interface and the module
procedure itself. In both cases, use of the name is unambiguous, as
explained in the ChangeLog. The testcase contains both the original and the
v
Hi All,
This patch fixes a double ICE arising from confusion between the dummy
symbol arising from a module function/subroutine interface and the module
procedure itself. In both cases, use of the name is unambiguous, as
explained in the ChangeLog. The testcase contains both the original and the
v
Hi Harald,
How did we miss that one for so long? This is certainly OK for mainline
and, I would suggest, 14-branch.
Thanks for the patch.
Paul
On Sun, 19 Jan 2025 at 20:42, Harald Anlauf wrote:
> Dear all,
>
> this patch addresses a long-standing difference between gfortran and
> other brand
Hi Harald,
How did we miss that one for so long? This is certainly OK for mainline
and, I would suggest, 14-branch.
Thanks for the patch.
Paul
On Sun, 19 Jan 2025 at 20:42, Harald Anlauf wrote:
> Dear all,
>
> this patch addresses a long-standing difference between gfortran and
> other brand
Hi Harald, hi all,
As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
out of a total of 54 for fortran and libgfortran. It's time that some of
these bugs are swatted, I think :-)
As well as this PR, 106946 seems to have fixed itself and I have fixes for
102333 and 96087 w
Hi Harald, hi all,
As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
out of a total of 54 for fortran and libgfortran. It's time that some of
these bugs are swatted, I think :-)
As well as this PR, 106946 seems to have fixed itself and I have fixes for
102333 and 96087 w
Hi Jerry,
With such an illustrious group of contributors, I can hardly say 'no', can
I? :-)
It looks fine to me - OK for trunk.
Regards
Paul
On Sun, 29 Dec 2024 at 23:10, Jerry D wrote:
> Attached is the revised patch incorporating handling of optional
> arguments of a calling procedure and
Hi Jerry,
With such an illustrious group of contributors, I can hardly say 'no', can
I? :-)
It looks fine to me - OK for trunk.
Regards
Paul
On Sun, 29 Dec 2024 at 23:10, Jerry D wrote:
> Attached is the revised patch incorporating handling of optional
> arguments of a calling procedure and
Hi Andre,
It looks good to me.
Thanks
Paul
On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote:
> Hi all,
>
> I did an ooppsie with the patch for 107635. Attached is a patch that fixes
> this. Essentially the regexp was to complicated for what was needed. So
> now we
> just count the numbe
Hi Andre,
It looks good to me.
Thanks
Paul
On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote:
> Hi all,
>
> I did an ooppsie with the patch for 107635. Attached is a patch that fixes
> this. Essentially the regexp was to complicated for what was needed. So
> now we
> just count the numbe
Hi Andre,
It looks good to me.
Thanks
Paul
On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote:
> Hi all,
>
> I did an ooppsie with the patch for 107635. Attached is a patch that fixes
> this. Essentially the regexp was to complicated for what was needed. So
> now we
> just count the numbe
Hi All,
These bugs were tricky to find because neither were detected by regression
testing on my platform.
PR116254: This bug was sporadic even where the regression was detected.
Richard Sandiford found "Conditional jump or move depends on uninitialised
value" errors in the library, triggered by
Hi All,
These bugs were tricky to find because neither were detected by regression
testing on my platform.
PR116254: This bug was sporadic even where the regression was detected.
Richard Sandiford found "Conditional jump or move depends on uninitialised
value" errors in the library, triggered by
Hi All,
This bug was so obviously in defiance of the standard that I pushed it to
mainline as r15-6260. I meant to post this message immediately but was
distracted before I could press send. I will be backporting today.
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/trans-ex
Hi All,
This bug was so obviously in defiance of the standard that I pushed it to
mainline as r15-6260. I meant to post this message immediately but was
distracted before I could press send. I will be backporting today.
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/trans-ex
ptr_size always the same
> as a
> descriptor->span? Can't the later be larger because of padding? If that is
> the
> case, then the first `else if (UNLIMITED...` you removed in
> `gfc_get_array_span
> ()` would return a larger number.
>
> Regards,
> Andre
ptr_size always the same
> as a
> descriptor->span? Can't the later be larger because of padding? If that is
> the
> case, then the first `else if (UNLIMITED...` you removed in
> `gfc_get_array_span
> ()` would return a larger number.
>
> Regards,
> Andre
Andre
>
> On Tue, 10 Dec 2024 08:46:10 +
> Paul Richard Thomas wrote:
>
> > Hi All,
> >
> > This was a rather vexatious bug to track down and squash. I was led
> astray
> > by the appearance of the bug in the tests for the implementation of
>
Hi All,
This was yet another regression that I caused, which was backported and so
I am rather anxious to fix it promptly.
The modifications that I made to gfc_get_array_span caused
unlimited polymorphic array components to be missed, when contained in a
dummy. Instead, the dummy was taken to be
Hi All,
This was yet another regression that I caused, which was backported and so
I am rather anxious to fix it promptly.
The modifications that I made to gfc_get_array_span caused
unlimited polymorphic array components to be missed, when contained in a
dummy. Instead, the dummy was taken to be
Hi All,
This was a rather vexatious bug to track down and squash. I was led astray
by the appearance of the bug in the tests for the implementation of
intrinsic transformational functions with class arguments. It turns out to
be an incipient bug in the handling of character(*) array associate name
Hi All,
This was a rather vexatious bug to track down and squash. I was led astray
by the appearance of the bug in the tests for the implementation of
intrinsic transformational functions with class arguments. It turns out to
be an incipient bug in the handling of character(*) array associate name
Hi All,
I must apologise for reintroducing this regression again, after the second
application of the fix for PR102689. I must admit that I had totally
forgotten about it, even though it was the reason for withdrawing the patch
the first time, and the failure was sporadic on my system, so I missed
Hi All,
I must apologise for reintroducing this regression again, after the second
application of the fix for PR102689. I must admit that I had totally
forgotten about it, even though it was the reason for withdrawing the patch
the first time, and the failure was sporadic on my system, so I missed
Hi Andre,
The patch looks to be straightforward. OK for mainline.
Thanks!
Paul
On Wed, 4 Dec 2024 at 12:16, Andre Vehreschild wrote:
> Hi all,
>
> I figured this patch has not been okay'ed yet. Anyone in for a review?
>
> Regtests ok on x86_64-pc-linux-gnu / F39. Ok for trunk?
>
> Regards,
>
Hi Andre,
The patch looks to be straightforward. OK for mainline.
Thanks!
Paul
On Wed, 4 Dec 2024 at 12:16, Andre Vehreschild wrote:
> Hi all,
>
> I figured this patch has not been okay'ed yet. Anyone in for a review?
>
> Regtests ok on x86_64-pc-linux-gnu / F39. Ok for trunk?
>
> Regards,
>
f you can reproduce the above, then please
> open a separate PR to track this. Given what the patch resolves,
> this is not a real show-stopper, so you may go ahead.
>
Committed as r15-5897. I will be following up with a new PR for the ICE.
Thanks for the review.
Paul
>
> Thanks,
f you can reproduce the above, then please
> open a separate PR to track this. Given what the patch resolves,
> this is not a real show-stopper, so you may go ahead.
>
Committed as r15-5897. I will be following up with a new PR for the ICE.
Thanks for the review.
Paul
>
> Thanks,
Hi Jerry,
That's fine for trunk and, after a decent interval, I would suggest that
you backport to 14-branch.
Please add the name of the contributor to the testcase unless you have been
asked not to.
Thanks
Paul
On Tue, 3 Dec 2024 at 04:13, Jerry D wrote:
> Hi all,
>
> Attached patch adds a
Hi Jerry,
That's fine for trunk and, after a decent interval, I would suggest that
you backport to 14-branch.
Please add the name of the contributor to the testcase unless you have been
asked not to.
Thanks
Paul
On Tue, 3 Dec 2024 at 04:13, Jerry D wrote:
> Hi all,
>
> Attached patch adds a
Hi Jerry,
Thanks for the green light. I am holding off for 24 hours because I have a
much cleaner solution in the offing.
Cheers
Paul
On Mon, 2 Dec 2024 at 01:46, Jerry D wrote:
> On 12/1/24 1:31 PM, Paul Richard Thomas wrote:
> > Hi All,
> >
> > This is a regression c
Hi All,
This is a regression caused by my patch for PR109345 - r15-5083.
I overlooked the possibility that the unlimited polymorphic container might
be the component of a dummy derived type. The fix is simple and relatively
obvious.
Regards
Paul
Fortran: Fix regression caused by r15-5083 [PR1
f90, and the chunks in
> class.cc and resolve.cc). Can you please check?
>
> Cheers,
> Harald
>
> Am 29.11.24 um 17:34 schrieb Paul Richard Thomas:
> > Hi All,
> >
> > This patch was originally pushed as r15-2739. Subsequently memory faults
> > were found an
f90, and the chunks in
> class.cc and resolve.cc). Can you please check?
>
> Cheers,
> Harald
>
> Am 29.11.24 um 17:34 schrieb Paul Richard Thomas:
> > Hi All,
> >
> > This patch was originally pushed as r15-2739. Subsequently memory faults
> > were found an
Hi All,
This patch was originally pushed as r15-2739. Subsequently memory faults
were found and so the patch was reverted. At the time, I could find where
the problem lay. This morning I had another look and found it almost
immediately :-)
The fix is the 'gfc_resize_class_size_with_len' in the ch
Hi All,
This patch was originally pushed as r15-2739. Subsequently memory faults
were found and so the patch was reverted. At the time, I could find where
the problem lay. This morning I had another look and found it almost
immediately :-)
The fix is the 'gfc_resize_class_size_with_len' in the ch
Hi Harald,
>
>> I'll wait until tomorrow to see if Paul intervenes. Otherwise I will
>> proceed and push.
>>
>
I succeeded in breaking things even more! Please proceed and push.
Thanks
Paul
Hi Harald,
>
>> I'll wait until tomorrow to see if Paul intervenes. Otherwise I will
>> proceed and push.
>>
>
I succeeded in breaking things even more! Please proceed and push.
Thanks
Paul
Hi Harald and Jerry,
I cannot see why the segfault is occurring of course:
_gfortran_transfer_character_write (&dt_parm.9, &"line 4:"[1]{lb:
1 sz: 1}, 7);
{
struct array01_integer(kind=4) parm.10;
integer(kind=8) D.4841;
struct array01_intege
Hi Harald and Jerry,
I cannot see why the segfault is occurring of course:
_gfortran_transfer_character_write (&dt_parm.9, &"line 4:"[1]{lb:
1 sz: 1}, 7);
{
struct array01_integer(kind=4) parm.10;
integer(kind=8) D.4841;
struct array01_intege
Pushed as r15-5716.
Paul
On Wed, 27 Nov 2024 at 09:15, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> Yes indeed, I did regtest the patch :-)
>
> Thanks for the thumbs up.
>
> Paul
>
>
> On Wed, 27 Nov 2024 at 09:07, An
Pushed as r15-5716.
Paul
On Wed, 27 Nov 2024 at 09:15, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Andre,
>
> Yes indeed, I did regtest the patch :-)
>
> Thanks for the thumbs up.
>
> Paul
>
>
> On Wed, 27 Nov 2024 at 09:07, An
patch.
>
> - Andre
>
> On Wed, 27 Nov 2024 08:57:25 +
> Paul Richard Thomas wrote:
>
> > Hi All,
> >
> > The "fix" for PR84674 caused this regression.
> >
> > The diagnostics that I had used for PR117763 allowed me to find a much
>
patch.
>
> - Andre
>
> On Wed, 27 Nov 2024 08:57:25 +
> Paul Richard Thomas wrote:
>
> > Hi All,
> >
> > The "fix" for PR84674 caused this regression.
> >
> > The diagnostics that I had used for PR117763 allowed me to find a much
>
Hi All,
The "fix" for PR84674 caused this regression.
The diagnostics that I had used for PR117763 allowed me to find a much
better fix for PR84674 and so this patch reverts the chunk in resolve.cc.
The chunk in class.cc works because non_overridable typebound procedures,
whose parent is abstrac
Hi All,
The "fix" for PR84674 caused this regression.
The diagnostics that I had used for PR117763 allowed me to find a much
better fix for PR84674 and so this patch reverts the chunk in resolve.cc.
The chunk in class.cc works because non_overridable typebound procedures,
whose parent is abstrac
Hi Harald,
Looks good to me.
Thanks
Paul
On Tue, 26 Nov 2024 at 19:51, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes two minor front-end memleaks I saw when working
> on recent PRs (pr117774 is one of them) and running f951 under valgrind.
>
> Regtested on x86_64-pc-linux-gnu.
Hi Harald,
Looks good to me.
Thanks
Paul
On Tue, 26 Nov 2024 at 19:51, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes two minor front-end memleaks I saw when working
> on recent PRs (pr117774 is one of them) and running f951 under valgrind.
>
> Regtested on x86_64-pc-linux-gnu.
Hi Harald,
The pull said that the rebase was successful. Where that #define came from
is a mystery to me. What do I do with it?
Cheers
Paul
On Sun, 24 Nov 2024 at 21:26, Harald Anlauf wrote:
> Am 24.11.24 um 17:40 schrieb Paul Richard Thomas:
> > Fixed as 'obvious' on 13
Hi Harald,
The pull said that the rebase was successful. Where that #define came from
is a mystery to me. What do I do with it?
Cheers
Paul
On Sun, 24 Nov 2024 at 21:26, Harald Anlauf wrote:
> Am 24.11.24 um 17:40 schrieb Paul Richard Thomas:
> > Fixed as 'obvious' on 13
Hi Jerry,
OK by me.
A small nit: s/too/to/ in the ChangeLog.
Thanks for the patch
Paul
On Mon, 25 Nov 2024 at 02:50, Jerry D wrote:
> I would like to commit the attached patch for Steve.
>
> Regression tested on x86-64-linux-gnu.
>
> OK for trunk?
>
> Author: Steve Kargl
> Date: Sun Nov
Hi Jerry,
OK by me.
A small nit: s/too/to/ in the ChangeLog.
Thanks for the patch
Paul
On Mon, 25 Nov 2024 at 02:50, Jerry D wrote:
> I would like to commit the attached patch for Steve.
>
> Regression tested on x86-64-linux-gnu.
>
> OK for trunk?
>
> Author: Steve Kargl
> Date: Sun Nov
Hi All,
The breakage was caused by the patch for PR109345. As it happens, this part
of the patch was not required to fix the PR and looked to be a considerable
simplification of the condition. Although correct that all is left are
class dummies, it caused the regression by not checking that it is
Hi All,
The breakage was caused by the patch for PR109345. As it happens, this part
of the patch was not required to fix the PR and looked to be a considerable
simplification of the condition. Although correct that all is left are
class dummies, it caused the regression by not checking that it is
Fixed as 'obvious' on 13-branch to mainline with commit
r15-5629-g470ebd31843db58fc503ccef38b82d0da93c65e4
An error with PR number in the mainline ChangeLogs will be corrected
tomorrow.
Fortran: Fix segfault in allocation of unlimited poly array [PR84869]
2024-11-24 Paul Thomas
g
Fixed as 'obvious' on 13-branch to mainline with commit
r15-5629-g470ebd31843db58fc503ccef38b82d0da93c65e4
An error with PR number in the mainline ChangeLogs will be corrected
tomorrow.
Fortran: Fix segfault in allocation of unlimited poly array [PR84869]
2024-11-24 Paul Thomas
g
Hi All,
I was going through some of the older regressions and found pr84674, which
was distinctly low hanging fruit because the contributor has found the
offending bit of code. However, buried in this PR, on the grounds that it
looked similar, was what has now become pr117730. This was quite diffi
Hi All,
I was going through some of the older regressions and found pr84674, which
was distinctly low hanging fruit because the contributor has found the
offending bit of code. However, buried in this PR, on the grounds that it
looked similar, was what has now become pr117730. This was quite diffi
Hi Thomas,
This has to be the shortest interval between submission and pushing of a
patch that I have experienced!
Pushed to mainline as r15-5347...
Thanks for the review!
Paul
On Sat, 16 Nov 2024 at 15:46, Thomas Koenig wrote:
> Hi Paul,
>
>
> > This is a particularly straightforward, goin
1 - 100 of 1142 matches
Mail list logo
