is not exactly legacy stuff.
Thanks,
Harald
> Gesendet: Montag, 09. Januar 2023 um 21:42 Uhr
> Von: "Harald Anlauf"
> An: "Paul Richard Thomas"
> Cc: "Jerry D" , "fortran"
> Betreff: Aw: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization)
point of view, a "F2018+ only" compliant
finalization would be more than most competitors offer... :)
Thanks,
Harald
Gesendet: Samstag, 07. Januar 2023 um 11:57 Uhr
Von: "Paul Richard Thomas"
An: "Harald Anlauf"
Cc: "Jerry D" , "fortran"
Betreff: Re:
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 Paul,
What causes the ICES?
There were a few PRs along this line. Usually, it is the
front-end pass inserting code which is illegal Fortran, and
the later stages then asserting that it doesn't happen.
Here are a few examples:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 (function
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
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 finalization calls should be
moved to the front end! I will take a quick look to see how easy this would
be to
rry,
>
> > Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> > Von: "Jerry D"
> > An: "Harald Anlauf" , "fortran"
> > Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03]
> Finish derived-type finalization
> >
> > O
Hi Jerry,
> Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> Von: "Jerry D"
> An: "Harald Anlauf" , "fortran"
> Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish
> derived-type finalization
>
> On 1/5/23 1:14
quot; , "Alessandro Fanfarillo" , "Andrew
Benson" , "Thomas Koenig" , "Damian Rouson"
Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish
derived-type finalization
Dear Paul, all,
I had a first look at the patch and the testcases, and I
Benson"
, "Thomas Koenig" , "Damian
Rouson"
Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish
derived-type finalization
Dear Paul, all,
I had a first look at the patch and the testcases, and I really look forward to
getting this into gfortran.
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
Hi Paul,
I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am struggling with assignment
number 6 in the attached. I would be very grateful if you would
Hi Paul,
Am 16.02.22 um 19:49 schrieb Paul Richard Thomas via Fortran:
Hi Harald and Jerry,
I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am
Hi Harald and Jerry,
I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am struggling with assignment
number 6 in the attached. I would be very grateful if
Hi Harald and Jerry,
I am reworking my way through, line by line wit F2018 in hand. Up to test
with offset 70, NAG looks to be right. I introduced an assignment with a
direct by ref function call, which doesn't finalise at the moment. Class
entities are yet to come. I'll report back early next
Hi Paul,
Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran:
Your "stupid questions" are not at all stupid. The finalization of
'variable' that occurs in your testcase demonstrates that the finalization
with my patch is occurring at the wrong time. I now see that NAG is correct
on
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
For what it is worth.
On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote:
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of
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
Remember the days when reading very old cryptic Fortran code? Remember
the fixed line lengths and cryptic variable names!
I fear the Standards committee has achieved history with the Standard
itself it is so difficult to understand sometimes.
Cheers to Paul and Harald for digging on this.
Hi Paul,
Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran:
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
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
Hi Paul,
thanks for attacking this.
I haven't looked at the actual patch, only tried to check the new
testcases with other compilers.
Am 03.02.22 um 18:14 schrieb Paul Richard Thomas via Fortran:
I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible.
This is not always
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
25 matches
Mail list logo
