Hi Harald,
Thanks for giving the patch a whirl.
> the parent components as an array. I strongly suspect that, from reading
> > 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,
> this
> > is another issue to come back to in the future.
>
> Could you specify which version of I
Hi Harald,
I have run your modified version of finalize_38.f90, and now I see
> that you can get a bloody head just from scratching too much...
>
> crayftn 12.0.2:
>
> 1, 3, 1
>
It appears that Cray interpret a derived type constructor as being a
function call and so "6 If a specification ex
Hi Harald,
I have taken gcc-patches out of the loop for now :-)
I am really sorry to be such a bother, but before we think we should
> do the same as Intel, we need to understand what Intel does and whether
> that is actually correct. Or not inconsistent with the standard.
> And I would really l
early next week.
Thanks for all the help. I have (re)learned to read the standard very
carefully.
Best regards
Paul
On Fri, 11 Feb 2022, 21:08 Harald Anlauf, wrote:
> Hi Paul,
>
> Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran:
> > Your "stupid questio
you would run this
testcase for the other brands.
As soon as I fix the 6th assignment, I will get on to class assignments.
Best regards
Paul
On Fri, 11 Feb 2022 at 21:59, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald and Jerry,
>
> I am reworking my way t
Hi Harald and Thomas,
Thank you for your contributions to understanding the interpretation by
different vendors of the F2018 requirements for finalization. While it does
appear to be rather chaotic, the differences are down to a small number of
"features" of each compiler.
Before describing my in
Hi Tobias,
Thanks for the patch and the particularly comprehensive testcase.
OK for mainline as far as I am concerned.
Paul
On Tue, 8 Mar 2022 at 20:06, Tobias Burnus wrote:
> Fix SIZEOF handling.
>
> I have to admit that I do understand what the current code does,
> but do not understand wh
Hi Harald,
It looks good to me - OK for mainline.
Thanks
Paul
On Fri, 8 Apr 2022 at 21:45, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran:
> > Dear all,
> >
> > the logic for checking the allocate-coshape-spec in an ALLOCATE
> > statem
Hi Harald,
It looks good to me.
Thanks to you and Steve for the patch.
Paul
On Mon, 28 Nov 2022 at 20:05, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> as reported, the Fortran standard requires all actual argument
> expressions to be evaluated (e.g. F2018:15.5.3).
>
> There were two case
Hi Harald,
It looks good to me. OK to commit.
Thanks
Paul
On Sat, 3 Dec 2022 at 18:27, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the attached obvious patch fixes a NULL pointer dereference
> that occurs with an invalid CLASS argument to DEALLOCATE.
>
> Regtested on x86_64-pc-linux-gnu
Hi Harald,
That's good to commit.
Thanks for the patch.
Paul
On Sat, 3 Dec 2022 at 20:40, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> here's a small documentation fix for the intrinsic FLOOR.
> Besides that, I adjusted the description of the optional
> KIND argument to Fortran intrinsi
ks - and it is good to see that you are back!
>
> Harald
>
> Am 04.12.22 um 12:48 schrieb Paul Richard Thomas via Gcc-patches:
> > Hi Harald,
> >
> > That's good to commit.
> >
> > Thanks for the patch.
> >
> > Paul
> >
> >
&
Hi Gary,
The equally quick answer is that I don't know.
https://help.imsl.com/fortran/ indicates that the library is compiled with
Intel fortran. While there are fortran 77 interfaces for most (all?) of the
routines, all the examples show use of modules that will have been compiled
with Intel. I s
Hi Jerry and everybody else,
I am with Tobias on this. Between work, gfortran, RSPCA, club and
neighbourhood activities I am "channelled" up to the eyeballs. Adding
another wouldn't make any great odds but I couldn't pay much more attention
to it than many of the others - sorry!
At the present, I
Hi Harald,
Thanks for doing that. My attention is elsewhere gfortran-wise.
Good for mainline.
Paul
On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> I am submitting the attached simple - and obvious - patch on
> behalf of Paul. It prevents a resource exhaustion d
gt; On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote:
> > > Resending as plain text, as the original version did not appear on the
> fortran list...
> > >
> > >
> > > Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr
> > > Von: "Ha
Hi Thomas,
What causes the ICES?
Cheers
Paul
On Sat, 7 Jan 2023 at 15:28, Thomas Koenig wrote:
> Hi Paul,
>
> first, thanks for taking on this rather monumental task!
>
> > Given the scale of the overall patch, I am beginning to have a lot of
> > sympathy with Thomas's suggestion that the fi
Hi Thomas,
Following your off-line explanation that the seemingly empty looking
assembly line forces an effective reload from memory, all is now clear.
OK for mainline and for backporting as you see fit.
Thanks for the patch.
Paul
On Sat, 7 Jan 2023 at 15:46, Thomas Koenig via Fortran
wrote:
Hi Thomas,
I was thinking of a function in resolve.cc, similar
to generate_component_assignments that would generate the final call and,
where necessary, generate a temporary and place rhs finalization after the
assignment. Since this would only involve ordinary assignment and
subroutine calls, I
Hi,
Andrew Benson found a rather horrible bug in my finalization patch that
involved two separate module files and another containing both a module and
the main program. They must be compiled separately for the bug to appear.
This bug arises in finalization because some derived type function resul
Hi Harald,
This is fine for mainline and for backporting if you feel so inclined.
Thanks for the patch.
Paul
On Mon, 16 Jan 2023 at 21:12, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> it appears that the fix for pr107874 uncovered a latent bug
> for the case of arrays of type character a
Hi Thomas and Steve,
Last night, I scoped out the work required to get the patch ready to
commit. Sorting out the testcases will be the main load since they have
grown "organically". I propose to change over to one test for each
paragraph of F2018 7.5.6.2/7.5.6.3 and to verify them against the oth
The alternative is that the patch be reviewed and committed as it is. I
have been neglecting my daytime job to get to this point and must spend
some time catching up.
Cheers
Paul
On Wed, 8 Mar 2023 at 08:05, Thomas Koenig wrote:
> Hi Paul,
>
> > Last night, I scoped out the work required to g
Hi Richard,
Smart pointer applications really torture finalization. That's why Andrew
and Salvatore's help has been so much appreciated.
I haven't run the polyhedron suite for some little while and so I just
downloaded it. I ran into a significant problem with the harness. The
binary segfaulted b
Hi All,
I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as
used in the posted Linux test). The timings are comparable except for
rnflow.f90.
As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
runs successfully at -O2.
I presume that this is a serious
Hi Tobias,
I agree completely with all that you are saying. Declaring derived types in
a module is guaranteed to produce vtables and final wrappers, so that they
are available in scopes where they are used. Had we thought more about
class design, we might have added the vtable to the entity, rathe
g wrote:
>
> > On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote:
> > > As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but
> > > runs successfully at -O2.
> >
> > I can confirm that.
> >
> > > I presume that this is a ser
Hi Thomas,
Before answering that, I thought that I had better try the polyhedron suite
with -fwrapv and -std=legacy together. As far as I can see, all is well and
so, yes, I think that is a good idea.
Cheers
Paul
D
Hi All,
I am awaiting a green light to commit this patch or not.
Cheers
Paul
On Fri, 10 Mar 2023 at 16:49, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Thomas,
>
> Before answering that, I thought that I had better try the polyhedron
> suite wit
Thank you, Richard.
I am planning to commit either very late tonight, Friday night or early on
Saturday morning to avoid any interference by other commits. It will take
me a little while to get it done and so I want to reduce the probability of
a mid-air collision.
Best regards
Paul
>
Hi Thomas,
Thanks for that! I think that your one-liner says it all :-)
There are three PRs left open that PR37336 depends on:
PR65347: Is partially fixed. The F2003/8 feature of finalization of a
structure constructor within an array constructor doesn't work. I wonder if
a compile option -finali
Hi All,
I committed this to 8-branch on 2019-04-24 but not to 9-branch. I have no
record of why I did this.
The patch now requires an additional line,
&& sym->ns->proc_name->attr.proc != PROC_MODULE
to prevent the error message in pr88376.f90 from changing to the less
helpful
Error: Speci
Hi Thomas,
Yes, that's fine for trunk. I wonder if it is worth being explicit that
linear congruential pseudo-random number generators can and do fail at -O3?
Thanks for the doc patches!
Paul
On Sun, 19 Mar 2023 at 08:32, Thomas Koenig via Fortran
wrote:
> Here's also an update on the docs t
Hi Harald,
This is good for trunk and for backporting.
Thanks for the rapid fix.
Paul
On Mon, 20 Mar 2023 at 20:57, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the attached trivial patch catches a MODULE PROCEDURE outside of a
> module interface before we run into an internal error.
>
>
Hi Harald,
If you will excuse the British cultural reference, that's a Norwegian Blue
alright! Good spot.
OK for mainline.
Thanks
Paul
On Sat, 25 Mar 2023 at 19:13, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> I've committed the attached patch from the PR that removes
> a dead code snip
Hi All,
I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging
fruit are already fixed but I have yet to check that they a really fixed
and to close them:
pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & pr93338
The attached patch picks up those PRs involving de
ote:
> Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran:
> > Hi All,
> >
> > I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging
> > fruit are already fixed but I have yet to check that they a really fixed
> > and to close them:
> &
Hi Harald,
OK for mainline. It is sufficiently small that, if there is any fallout in
the next weeks, it can easily be reverted without great impact.
Thanks for the patch.
Paul
On Mon, 3 Apr 2023 at 20:46, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the attached patch fixes an ICE-on-in
Hi All,
This is a first in my recent experience - a very old bug that produces too
many finalizations! It results from a bit of a fix up, where class objects
are allocated using the derived typespec, rather than a source or mold
expression. This occurs upstream in resolve.cc, where the default
ini
Hi Harald,
Quite right - good spot. There was an 'else' that turned out to be
unnecessary.
Thanks
Paul
On Wed, 5 Apr 2023 at 19:50, Harald Anlauf wrote:
> Hi Paul,
>
> On 4/5/23 08:53, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > This i
: ditto
* gfortran.dg/dtio_35.f90 : ditto
* gfortran.dg/goacc/array-with-dt-2.f90 : ditto
* gfortran.dg/gomp/affinity-clause-1.f90 : ditto
* gfortran.dg/pr103258.f90 : ditto
* gfortran.dg/pr59107.f90 : ditto
* gfortran.dg/pr93835.f08 : ditto
On Wed, 29 Mar 2023 at 09:53, Paul Richard Thomas
Dear All,
Please find attached a slightly updated version of the patch with a
consolidated testcase. The three additional testcases are nothing to do
with associate and test fixes of character related bugs.
OK for mainline?
Cheers
Paul
Fortran: Fix some of the bugs in associate [PR87477]
2023-
duuuh! Please find them attached.
Thanks
Paul
On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote:
> Hi Paul,
>
> I don't see the new testcases. Is this an issue on my side,
> or did you forget to attach them?
>
> Thanks,
> Harald
>
> On 4/7/23 09:07, Paul Rich
l->backend_decl && VAR_P (cl->backend_decl))
gfc_add_modify (pblock, cl->backend_decl, se.expr);
Cheers
Paul
On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote:
> Hi Paul,
>
> On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote:
> > duuuh! Please find t
PS Quite right about the allocation in PR93813 - consider it to be included.
Cheers and thanks
Paul
On Fri, 7 Apr 2023 at 22:35, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> Well done on noticing the memory leak :-) I have a fix for it that I
Hi Tobias,
I started applying my poor knowledge of regular expressions to fix this
last night and timed out. Thanks for doing it for me. I will look carefully
and learn from the master :-)
Is it really a regression, when a change exposes a latent bug? Never mind,
though, it's fixed.
Cheers
Paul
Hi Harald,
The patch looks good to me - OK for mainline.
Thanks
Paul
On Tue, 11 Apr 2023 at 21:12, Harald Anlauf via Fortran
wrote:
> Dear all,
>
> the testcase in the PR by Gerhard exhibited a mis-treatment of
> the function decl of the entry master if the function result
> had a pointer at
Hi All,
I think that the changelog says it all. OK for mainline?
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-07 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl before
Hi Harald,
That's interesting - the string length '.q' is not set for either of the
associate blocks. I'm onto it.
Thanks
Paul
On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote:
> Hi Paul,
>
> On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
> &g
assigning the value
returned by gfc_conv_expr_descriptor. Also, guard the backend
decl before testing with VAR_P.
gcc/testsuite/
PR fortran/109451
* gfortran.dg/associate_61.f90 : New test
On Thu, 13 Apr 2023 at 07:18, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
&
Hi Harald,
Committed with the coding error that you spotted put right.
commit r13-7181-gb0e85485fbf042abccee5c0a9eb499da386c8db3
I will build up a composite finalization patch for 12-branch in the coming
days. However, I still have one of Andrew Benson's bugs to put right before
I do that.
Rega
Hi All,
As usual, I received a string of emails on retargeting for PRs for which I
was either responsible or was on the cc list. This time I decided to take a
look at them all, in order to reward the tireless efforts of Richi, Jakub
and Martin with some attention at least.
I have fixed the PRs in
Hi Steve,
Nagfor responds to the test case with "Error: pr97122.f90, line 14: Type T
has final subroutines but is not defined in the specification part of a
module"
F2018:
"C787(R753) A final-subroutine-name shall be the name of a module procedure
with exactly one dummy argument."
Since, of nece
Hi All,
Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
this testcase checked that finalizable derived types could not be specified
in a submodule. I have replaced the original test with a test of the patch.
Thanks also to Malcolm Cohen for guidance on this.
OK for tr
Hi All,
This problem caused the gimplifier failure because the reference chain
ending in an inquiry_len still retained a full array reference. This had
already been corrected for deferred character lengths but the fix extends
this to all characters without a length expression and integer expressio
Duuh! There's even a choice :-)
Paul
On Tue, 9 May 2023 at 19:29, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > This problem caused the gimplifier failure because the reference chain
&g
Hi Larry,
The last time I had to deal with this I removed the offending use
statements, as suggested in the thread pointed to by Andrew, and then
searched for the missing references by name. All were easily replaced by
intrinsic procedures.
Good luck
Paul
On Wed, 17 May 2023 at 21:23, Andrew P
Hi Andre,
It's good to hear from you.
I would suggest the following:
(i) Complete F2003 compliance - Now that finalization is within a whisker
of compliance, this mostly leaves putting PDTs right. The framework is all
there, it just needs revamping. I can provide guidance or a statement of
work h
Hi All,
This started out as the search for a fix to pr109948 and evolved to roll in
5 other prs.
Basically parse_associate was far too clunky and, in anycase, existing
functions in resolve.cc were well capable of doing the determination of the
target expression rank. While I was checking the comm
aul Richard Thomas via Fortran a écrit :
> > Hi All,
> >
> > This started out as the search for a fix to pr109948 and evolved to roll
> in
> > 5 other prs.
> >
> > Basically parse_associate was far too clunky and, in anycase, existing
> > functions in resolve
Hi All,
I propose to backport
r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
soon. Before that, I propose to remove the F2003/2008 finalization of
structure and array constructors in 13- and 14-branches. I can see why
it was removed from the standard in a correction to F2008
Hi Jorge,
As I posted in the Intel Community, the error generated by gfortran
(and nagfor) is consistent with the F2003 constraint: C1210 (R1209)
The IMPORT statement is allowed only in an interface-body.
Could you please raise a problem report in gcc Bugzilla?
Thanks
Paul
On Fri, 2 Jun 2023 a
Hi Jorge,
PRs 108650/106035 cover this problem.
Thanks
Paul
On Fri, 2 Jun 2023 at 15:04, Jorge D'Elia via Fortran
wrote:
>
> Hi,
>
> I have a doubt about IMPORT and SELECT TYPE, please see the
> forwarded message below (that also has a sample code), as well
>
> https://www.ibm.com/docs/en/xffb
Hi Steve,
As noted in the previous email :-), although I didn't mention the partially
cooked patch.
One day, once F2003 is sorted, I might turn to F2008/18!
Cheers
Paul
On Fri, 2 Jun 2023, 16:27 Steve Kargl via Fortran,
wrote:
> On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richar
Hi Harald,
It looks good to me. Thanks to you and Steve for the fix. I suggest
that it is such and obvious one that it deserved back-porting.
Cheers
Paul
On Fri, 2 Jun 2023 at 19:06, Harald Anlauf via Fortran
wrote:
>
> Dear all,
>
> I've committed that attached simple patch on behalf of Steve
Hi Thomas,
I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.
I am dithering about changing the F2003/08 part of finalization since
the default is 2018 compliance. That s
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the .diff + ChangeLog suffice
to explain them. 'rankguessed' was made redundant b
of the expression
and this was somehow connected with successfully simplifying the
parentheses. Copying and replacing on no errors deals with the
problem.
Thanks
Paul
On Wed, 7 Jun 2023 at 19:38, Harald Anlauf wrote:
>
> Hi Paul!
>
> On 6/7/23 18:10, Paul Richard Thomas via Gcc-p
Morin wrote:
> > Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
> >> Hi Harald,
> >>
> >> In answer to your question:
> >> void
> >> gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
> >> {
> >>free_expr0 (dest);
&g
Hi All,
The attached patch is amply described by the comments and the
changelog. It also includes the fix for the memory leak in decl.cc, as
promised some days ago.
OK for trunk?
Regards
Paul
PS This leaves 89645 and 99065 as the only real blockers to PR87477.
These will take a little while to
17 Jun 2023 at 19:01, Harald Anlauf wrote:
>
> Hi Paul,
>
> On 6/17/23 11:14, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > The attached patch is amply described by the comments and the
> > changelog. It also includes the fix for the memory leak
Hi Harald,
Fixing the original testcase in this PR turned out to be slightly more
involved than I expected. However, it resulted in an open door to fix
some other PRs and the attached much larger patch.
This time, I did remember to include the testcases in the .diff :-)
I believe that, between t
Hi Tobias,
This looks good to me. I'm interested to see it in use :-)
OK for trunk
Paul
On Tue, 20 Jun 2023 at 11:50, Tobias Burnus wrote:
>
> When just matching a symbol, one can use 'gfc_match_symbol (&sym, host_assoc)'
> and has the option to match with and without host association.
>
> How
Dear All,
This patch is verging on obvious. The PR was originally, incorrectly
blocking PR87477 and the testcase has remained in my 'associate'
directory. I thought that it is time to get shot of it!
Is there a better way to detect a type(c_ptr) formal argument?
Subject to advice on the question
Committed as r14-2021-gcaf0892eea67349d9a1e44590c3440768136fe2b
Thanks for the pointers, Tobias and Mikael, I used them both.
Paul
On Tue, 20 Jun 2023 at 21:47, Mikael Morin wrote:
>
> Le 20/06/2023 à 18:30, Tobias Burnus a écrit :
> > On 20.06.23 18:19, Paul Richard Thomas via F
Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Thanks for the help and the review Harald. Thanks to Steve too for
picking up Neil Carlson's bugs.
Cheers
Paul
On Tue, 20 Jun 2023 at 22:57, Harald Anlauf wrote:
>
> Hi Paul,
>
> On 6/20/23 12:54, Paul Richa
Hi Both,
> while I only had a minor question regarding gfc_is_ptr_fcn(),
> can you still try to enlighten me why that second part
> was necessary? (I believed it to be redundant and may have
> overlooked the obvious.)
Blast! I forgot about checking that. Lurking in the back of my mind
and going
Hi All,
I was looking through Neil Carlson's collection of gfortran bugs and
was shocked to find this rather fundamental PR. At 12 years old, it is
certainly a "golden oldie"!
The patch is rather straightforward and seems to do the job of
admitting derived, intrinsic and character expressions to
missed somewhere.
I'm onto it.
Paul
On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote:
>
> Hi Paul!
>
> On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote:
> > I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the
> > extra bla
sions.
(gfc_trans_subcomponent_assign): Expand assignment to class
components to include intrinsic and character expressions.
gcc/testsuite/
PR fortran/49213
* gfortran.dg/pr49213.f90 : New test
On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote:
>
> Hi Paul!
>
> On 6/24/23 15:18, Paul Richard Thomas via Gcc-pat
e
> size of a character string you are using an intermediate
> gfc_array_index_type, whereas I have learned to use
> gfc_charlen_type_node now, which seems like the natural
> type here.
>
> OK for trunk, and thanks for your patience!
>
> Harald
>
>
> On 6/27/23
This is a heads up for a patch that has not been exercised enough as yet.
It works rather better and with less pain than I expected.
The testcase is really that of PR99065 but I thought that I should
give Ian Harvey prior credit for PR89645. Both appear in the meta-bug
PR87477.
I'll do the exerc
Hi Alexander,
I suggest that you take a look at PR82649 before going too far down
the road of fixing PDT bugs. This PR underlines just how wrong the PDT
representation is - mea culpa!
The mechanics for constructing PDTs are in
decl.cc(gfc_get_pdt_instance). They need to be turned inside out to
cr
Hi All,
I have gone through the PDT problem reports and made sure that they
block PR82173.
To my utter astonishment (i) There might be only one duplicate; and
(ii) Only 82649, 84119, 90218, 95541, 99079, 102901 & 105380 (out of
50 PRs) depend on the representation.
Regards
Paul
Hi Harald,
This is indeed obvious :-)
Thanks for the patch.
Paul
On Fri, 7 Jul 2023 at 19:32, Harald Anlauf via Fortran
wrote:
>
> Dear all,
>
> I intend to commit the attached obvious patch within 24h unless
> someone objects. gfc_compare_expr() did not handle the case of
> complex constants
The attached patch incorporates two of Steve's "Orphaned Patches" -
https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html
They have in common that they both involve faults in use of default
type and that I was the ultimate cause of the bugs.
The patch regtests with the attached testcases.
generic)
> {
>tmp = gfc_find_dt_in_generic (tmp);
>if (tmp && tmp->attr.flavor == FL_DERIVED)
>
> Both variants are equally readable, though.
>
> I haven't though long enough about possible minor memleaks,
> i.e. if a freeing of gfc_symbol tmp is advi
Hi Mikhail,
That's more than OK by me.
Thanks for attacking this PR.
I have a couple more of Steve's orphans waiting to be packaged up -
91960 and 104649. I'll submit them this evening.100607 is closed-fixed
and 103796 seems to be fixed.
Regards
Paul
On Tue, 11 Jul 2023 at 13:08, Mikael Morin
Hi Mikael,
All 14 patches apply cleanly to trunk, which is rebuilding right now
and will regtest this evening.
I will review the composite patch tomorrow morning and will come back
to you as soon as I can.
At first sight all is well; perhaps the commented out line can be
dispensed with?
Many th
Hi Mikhail,
This patch uses a field for gfc_se called class container, which is
neither declared nor set as far as I can tell.
Regards
Paul
On Thu, 13 Jul 2023 at 10:05, Mikael Morin via Fortran
wrote:
>
> Pass already evaluated class container argument from
> gfc_conv_procedure_call down to g
that it reflects some case where the assertion failed? If
so, it might be prudent to retain the assertion especially in light
of:
gcc_assert (tmp_se.post.head == NULL_TREE); a bit further down.
OK for trunk
Thanks for all the work and the patches.
Paul
On Thu, 13 Jul 2023 at 19:40, Paul
Hi Mikhail,
That's ever so slightly embarrassing :-) My notes for that commit
don't provide any enlightenment.
Thanks
Paul
Committed to trunk as 'obvious' in
r14-3098-gb8ec3c952324f866f191883473922e250be81341
13-branch to follow in a few days.
Paul
I took a look at my calendar and decided to backport right away.
r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7
BTW It is a regression :-)
Paul
On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas
wrote:
>
> Committed to trunk as 'obvious
I wonder why the development 14.0.0 doesn't exhibit this behaviour?
Could you please rerun with the compile options -g -fdump-tree-original .
The later should generate a file *.original with the content:
void test ()
{
character(kind=1) cc[1:32];
__builtin_memmove ((void *) &cc, (void *) &"
Hi Jorge,
> There were some recent patches in this area IIRC.
>
> Jerry
The tree dump is identical to mine, obtained with GNU Fortran (GCC)
14.0.0 20230809 (experimental), so I doubt that any recent patches are
responsible.
Being unable to reproduce the error, there is not much that I can do.
S
Hi Harald,
It all looks good to me and does indeed make the code clearer. OK for trunk.
Thanks for the patch.
I was shocked to find that there are 217 older bugs than 49588. Does
anybody test older bugs to check if any of them have been fixed?
Paul
On Mon, 21 Aug 2023 at 20:48, Harald Anlauf v
Committed as 'obvious'. 13-branch to follow.
commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
Author: Paul Thomas
Date: Sat Aug 26 14:37:49 2023 +0100
Fortran: Supply a missing dereference [PR92586]
2023-08-26 Paul Thomas
gcc/fortran
PR fortran/92586
After two months on trunk, this has been backported:
Fortran: Fix some problems blocking associate meta-bug [PR87477]
2023-08-27 Paul Thomas
gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expr
Hi Harald,
The statement,
in array_bound_check_elemental is redundant since the call is
determined by a more restrictive condition.
+ if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS))
+return;
Apart from that, it looks good to me. OK for mainline.
Thanks for the patch.
Paul
On Thu, 14 Sep
201 - 300 of 349 matches
Mail list logo
