Hi Christopher,
I was somewhat surprised as well to find the pre-release version of
gfortran in Fedora 42.
sudo dnf install gcc14-gfortran.x86_64
will recover gfortran-14.2.1 for you, which is then invoked with:
pault@fedora:~/prs/pr101047$ gfortran-14 --version
GNU Fortran (GCC) 14.2.1 2025021
Hi Andre,
On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild wrote:
> Hi Jerry,
>
> thanks for the review and sorry for the long delay. With publishing the
> team's
> patches for gfortran, I also created a pull request for OpenCoarrays.
> There I
> was asked to add some testcase with more "beef" in
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 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 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
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,
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
>
&
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 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 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
* 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
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
;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 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 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 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
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 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 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,
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
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 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
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 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 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
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 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
Hi All,
This is a particularly straightforward, going on 'obvious', patch. The bug
goes back to at least gcc-6.4.1.
OK for mainline and, after a week or two, to 13- and 14-branches?
Regards
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
Hi Jerry and Harald,
I have on several occasions perused gfc_conv_procedure_call with a view to
doing exactly the refactoring that you suggest. However, it has grown like
Topsy and the logic has become very difficult to follow. This, of course,
makes it ripe for refactoring but has turned it into
Hi Jakub,
Good catch! Does it fix any specific PR?
If you don't have the time, I would be happy to apply the correction to
13-branch through to mainline.
Regards
Paul
On Thu, 14 Nov 2024 at 22:24, Jakub Jelinek wrote:
> On Thu, Nov 14, 2024 at 08:58:26PM +0100, Jan Hubicka wrote:
> > fortra
Hi All,
The ChangeLog and comment make it clear what this patch does and why.
OK for mainline and backporting after a week or so?
Regards
Paul
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 51e0af410c1..c54b3c85621 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolv
>
> Hi Harald,
>
Thanks for the review!
> ... except that the PR number should be corrected (109345 instead of
> 109435) in the testcase and the commit message (Change.logs).
>
> Dyslexics of the world untie!
Paul
'Obvious' patch committed
as r15-5078-g42a2df0b7985b2a4732ba1c29726ac7aabd5eeae. Will backport later
Thanks to Tomas Trnka for investigating identifying the fix.
Regards
Paul
Hi All,
The failing testcase came about because the array reference in the TYPE IS
block required the correct value of the span. The fix separates out
unlimited polymorphic expressions in gfc_get_array_span and ensures that
the value returned is the originating array span, rather than the element
rieb Paul Richard Thomas:
> > Hi All,
> >
> > There is not much to say about the attached patch other than it is
> minimal
> > :-) The testcases are probably a bit more than is strictly needed since
> the
> > interface tests (proc_ptr_55.f90) are already tested els
Hi All,
There is not much to say about the attached patch other than it is minimal
:-) The testcases are probably a bit more than is strictly needed since the
interface tests (proc_ptr_55.f90) are already tested elsewhere. However, it
is as well to check in this context.
OK for mainline and 14-br
Hi All,
After pushing the patch to fix comment 5 of this PR, I noticed that I had
not taken account of the commented out tests in associate_69.f90. The fix
is trivial, being a minor tweak to yesterday's patch, and has been pushed
as r15-4835- after regtesting. The testcases associate_69.f90 an
You see, Jerry, it's the tmp4 that might have been or, perhaps, was and is
no more :-) The comment will be changed.
Thanks for the review.
Paul
On Wed, 30 Oct 2024 at 17:01, Jerry D wrote:
> On 10/30/24 9:58 AM, Steve Kargl wrote:
> > On Wed, Oct 30, 2024 at 04:41:40PM +
This wrinkle to PR115700 came about because the associate-name string
length was not being initialized, when an array selector had a substring
reference with non-constant start or end. This, of course, caused
subsequent references to fail.
The ChangeLog provides an adequate explanation of the atta
Pushed as 'obvious' in commit r15-4702. This patch has been on my tree
since July so I thought to get it out of the way before it died of bit-rot.
Will backport in a week.
Fortran: Fix regressions with intent(out) class[PR115070, PR115348].
2024-10-27 Paul Thomas
gcc/fortran
PR fortran/115070
gfc_expr *expr2 = gfc_copy_expr (e);
> > + tmp = gfc_trans_pointer_assignment (expr1, expr2);
> > + gfc_add_init_cleanup (block, tmp, NULL);
> > + gfc_free_expr (expr1);
> > + gfc_free_expr (expr2);
> > +}
> >else if ((sym->attr.d
Hi Andre,
The handling of submodules is something of a kludge, especially where
module procedures are concerned, that seems to work OK. Given that, your
patch looks right and is good for mainline.
Thanks for the patch.
Paul
On Wed, 16 Oct 2024 at 08:21, Andre Vehreschild wrote:
> Hi all,
>
>
Good catch, Thomas!
Thanks for the fix.
Paul
On Tue, 15 Oct 2024 at 08:50, Thomas Schwinge
wrote:
> Hi!
>
> On 2024-10-14T21:18:17+0100, Sam James wrote:
> > Sam James writes:
> >> Andre Vehreschild writes:
> >>> [...] During latest regression testing of the Fortran suite I got
> >>> typeb
Hi Andre,
This looks fine to me. OK for mainline.
Thanks for the patch and sorry for the wait for review.
Paul
On Mon, 14 Oct 2024 at 08:50, Andre Vehreschild wrote:
> Ping ^ 4.
>
> Really no one to review this 160 something patch?
>
> Regtests ok on x86_64-pc-linux-gnu /Fedora 39? Ok for ma
Hi Tobias,
Good catch! It looks 'obvious' to me too :-)
Regards
Paul
On Fri, 11 Oct 2024 at 14:08, Tobias Burnus wrote:
> I found always error.cc rather confusing but I just realized that
> we can reduce number of lines in that file by 40% - and remove a lot of
> (apparent) complexity.
>
> T
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 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 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
/
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
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
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
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,
> + /* 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 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 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
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*)
>
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
1 - 100 of 344 matches
Mail list logo
