Hi Harald,
This looks good to me. OK for mainline and, dare I suggest, 11-branch?
>From a quick run through resolve.c, there are many places where the extra
checks that you introduced in the patch have been implemented. This makes
me wonder whether a function or macro might not make the relevant
6 schrieb Paul Richard Thomas via Fortran:
> > Hi Harald,
> >
> > This looks good to me. OK for mainline and, dare I suggest, 11-branch?
> >
> > From a quick run through resolve.c, there are many places where the
> extra
> > checks that you introduced in th
Hi Sandra,
That's a good shout to query suppress_errors. The patch is OK by me.
Thanks
Paul
On Wed, 5 Jan 2022 at 03:21, Sandra Loosemore
wrote:
> This patch fixes an ICE that appeared after I checked in my patch for
> PR101337 back in November, which made the resolve phase try harder to
> c
I doubt that this is a regression on 9-11 branches since the testcase
compiles correctly on each of my copies of these branches. IMHO it is
rather more likely to have been caused by
64f9623765da3306b0ab6a47997dc5d62c2ea261, which introduced this new form of
gfc_conv_gfc_desc_to_cfi_desc.
The patch
Hi All,
Strictly speaking, the attached patch is branching out into a more
generalised attack on PR37336(Finalization) - [F03] Finish derived-type
finalization but most of it fixes PR64290.
I started work on this patch almost a year ago but had to drop it due
daytime work pressure and only picked
Hi Jerry,
I am trying to fix the failure of my latest patch with this very test case.
Otherwise it fixes most of the remaining dependencies in PR37336.
At a pinch, I could submit the earlier patch that Andrew mentions and work
from there. However, you will note that it does miss one of the
finali
Hi Salvatore,
My reading of F2018: 7.5.6.3 "When finalization occurs" is that three calls
is correct. (i) Paragraph 1 stipulates that the 'var' expression be
evaluated before the reallocation and intrinsic assignment; (ii)stipulates
that the function result be finalised "the result is finalized a
Hi Salvatore,
That's correct. It's what ifort does too. Thus far I have found only one or
two minor niggles with the Intel implementation of finalization. Since, as
often or not, the two compilers are frequently used by the same users, I
will attempt to make them compliant with one another. I will
This patch has been an excessively long time in coming. Please accept my
apologies for that.
All but two of the PR37336 dependencies are fixed, The two exceptions are
PRs 59694 and 65347. The former involves lack of finalization of an
unreferenced entity declared in a block, which I am sure is tri
Hi Harald and Mikael,
This looks fine to me. OK for all the listed branches.
Thanks for the patch
Paul
On Wed, 2 Feb 2022 at 20:20, Harald Anlauf via Fortran
wrote:
> Hi Mikael,
>
> Am 29.01.22 um 15:24 schrieb Mikael Morin:
> > Hello,
> >
> > the attached patch is a fix for PR104228.
> > Ev
Hi Harald,
Indeed, this is obvious, as you say. OK for the affected branches.
Regards
Paul
On Tue, 1 Feb 2022 at 22:38, Harald Anlauf via Fortran
wrote:
> Dear Fortranners,
>
> a check in gfc_calculate_transfer_sizes had a bug in the logic:
> it did not trigger for MOLD having a storage size
Hi Damian,
Tobias Burnus fixed it in 12-branch:
GNU Fortran (GCC) 12.0.1 20220203 (experimental)
./a.out
- complex(c_float_complex)
a_desc->type = 1028
a_desc->elem_len = 8
CFI_type_float_Complex = 1028
CFI_type_double_Complex = 2052
- complex(c_double_complex) ---
a_desc-
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
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:
>> >
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
Hi Harald,
You will, perhaps, rue having me back when you see the updated finalization
patch :-) This time, I will be breaking it up into digestible chunks!
I'll be posting in about one week.
Regards
Paul
On Sun, 4 Dec 2022 at 19:40, Harald Anlauf wrote:
> Hi Paul,
>
> thanks - and it is go
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
Hi All,
Please find attached a patch for trans-array.cc that does what Harald
suggests; ie. finalization of array and structure constructors only occurs
with -std=f2003/8. Two versions of finalize_38.f90 are attached. One which
tests -std=gnu/f20018 and the other -std=f2008.
Frankly, I think that
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 with -fwrapv and -std=legac
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 is a first in my recent experience - a
o be rife!
>
> Cheers
>
> Paul
>
>
> On Wed, 29 Mar 2023 at 09:24, Manfred Schwarb wrote:
>
>> 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
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 Richard Thomas via Gcc-patches wrote:
Hi Harald,
Well done on noticing the memory leak :-) I have a fix for it that I was
going to post separately. Actually, it is a trivial one liner, which I
could include with the patch.
@@ -2554,23 +2559,25 @@ gfc_conv_string_length (gfc_charlen * cl, gfc_expr
* expr, stmtblock_t * pblock)
e
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 was
> going to post
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:
> > Hi All,
> >
> > I think that the c
Hi Harald,
The fix was trivial. An updated patch and testcase are attached.
Thanks
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-14 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length
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
> > ending in an inquiry_len still retain
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
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
I should perhaps have remarked that, following the divide error,
gfc_simplify_expr was returning a mutilated version of
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
Hi Harald,
Well, at least you found the testcase :-)
Thanks for pointing out the obvious; ie. that I had deviated from the
original testcase. This is an important clue for some of the PRs that
come up under the "select type flag". What is surprising is that it is
gcc_assert (st->n.sym->assoc) tha
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 Richard Thomas via Gcc-patch
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
Hi Harald,
I feel very foolish! You are absolutely right about gfc_is_ptr_fcn
(gfc_expr *e). I never checked what gfc_expr_attr did here.
I have fixed character (kind=4) but have now run into trouble with
expressions such as cont = tContainer(sqrt (2.0_8)). I think that
simplification is being mi
Hi Harald,
Let's try again :-)
OK for trunk?
Regards
Paul
Fortran: Enable class expressions in structure constructors [PR49213]
2023-06-27 Paul Thomas
gcc/fortran
PR fortran/49213
* expr.cc (gfc_is_ptr_fcn): Remove reference to class_pointer.
* resolve.cc (resolve_assoc_var): Call gfc_is_
Hi Harald,
I'll change to gfc_charlen_type_node.
Thanks for your patience in reviewing this patch :-)
Cheers
Paul
On Tue, 27 Jun 2023 at 20:27, Harald Anlauf wrote:
>
> Hi Paul,
>
> this is much better now.
>
> I have only a minor comment left: in the calculation of the
> size of a character
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.
Hi Harald,
I don't believe that a memory leak is possible since tmp is only
non-null if it points to an existing symbol. I agree with you about
the style but have to plead innocence because I am not the author :-)
I will change it though.
Thanks for the nit, Steve.
Pushed as r14-2397-g9a2eab6172
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
1 - 100 of 161 matches
Mail list logo
