[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 --- Comment #8 from paul.richard.thomas at gmail dot com --- Hi Harald, After a lot of messing around, I managed to backport the patch; essentially by hand. However, two of the testcases ICEd in trans-array.cc and so there were obviously dependences that I had missed. I will not be backporting r14-1629, if for no other reason than it is not a regression but also because the amount of work that would be involved doesn't warrant it. It's a pity that I didn't keep 13-branch up to speed with mainline on the associate fixes but we will just have to live with it now. Regards Paul On Tue, 2 Apr 2024 at 14:32, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Harald, > > I will have a stab at backporting r14-1629 later this afternoon and will > let you know what happens. I am just rebuilding after applying the fix for > pr112407 (yes, I did add -std=f2008 :-) ). > > I don't think that there is any point in going back to 12-branch at this > point in the release cycle. > > Cheers > > Paul > > > > > On Mon, 1 Apr 2024 at 21:42, anlauf at gcc dot gnu.org < > gcc-bugzi...@gcc.gnu.org> wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 >> >> anlauf at gcc dot gnu.org changed: >> >>What|Removed |Added >> >> >> Status|NEW |ASSIGNED >> >> --- Comment #6 from anlauf at gcc dot gnu.org --- >> (In reply to Paul Thomas from comment #5) >> > Hi Harald, >> > >> > I am pinning this one on you since it needs backporting to 13-branch, at >> > least. It also keeps the audit trail clean. >> >> Hi Paul, >> >> this one is at the top of my backport list. >> >> It depends on backporting r14-8902 (mine), and has weak conflict if >> r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90 >> was introduced in that commit. >> >> I could amend backporting the fix for the current PR as well as r14-8902 >> to 13-branch by removing the changes to pr99350.f90 from the backport. >> That is likely the most simple solution, as backporting r14-1629 might >> introduce regressions. >> >> Nevertheless, the current fixes can only be backported to 13-branch, >> as some of the infrastructure changes for better error recovery after >> arithmetic errors and when array ctors are involved are to risky to >> backport to 12-branch. >> >> What do you think? >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > >
[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 --- Comment #7 from paul.richard.thomas at gmail dot com --- Hi Harald, I will have a stab at backporting r14-1629 later this afternoon and will let you know what happens. I am just rebuilding after applying the fix for pr112407 (yes, I did add -std=f2008 :-) ). I don't think that there is any point in going back to 12-branch at this point in the release cycle. Cheers Paul On Mon, 1 Apr 2024 at 21:42, anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > > Status|NEW |ASSIGNED > > --- Comment #6 from anlauf at gcc dot gnu.org --- > (In reply to Paul Thomas from comment #5) > > Hi Harald, > > > > I am pinning this one on you since it needs backporting to 13-branch, at > > least. It also keeps the audit trail clean. > > Hi Paul, > > this one is at the top of my backport list. > > It depends on backporting r14-8902 (mine), and has weak conflict if > r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90 > was introduced in that commit. > > I could amend backporting the fix for the current PR as well as r14-8902 > to 13-branch by removing the changes to pr99350.f90 from the backport. > That is likely the most simple solution, as backporting r14-1629 might > introduce regressions. > > Nevertheless, the current fixes can only be backported to 13-branch, > as some of the infrastructure changes for better error recovery after > arithmetic errors and when array ctors are involved are to risky to > backport to 12-branch. > > What do you think? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448 --- Comment #6 from paul.richard.thomas at gmail dot com --- Hi Harald, I had forgotten about this PR because the fix became incorporated in the patch for PR89645. In consequence, pr87448.f90 disappeared from the pr87477 failures :-) One of the last tasks before submitting the fix-up patch for PR89645 was to remove this chunk because I couldn't understand why it was there. Thanks for the reminder. Paul On Sun, 17 Dec 2023 at 17:49, anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448 > > --- Comment #5 from anlauf at gcc dot gnu.org --- > (In reply to Paul Thomas from comment #4) > > Created attachment 56484 [details] > > Fix for this PR > > > > Somehow this missed being a blocker for the ASSOCIATE meta-bug. > > > > The patch is so unbelievably simple that I am going to think about it > for 24 > > hours, even though it regtests just fine :-) > > And it is so simple that you seem to have forgotten about it... > > Are you going to pursue it? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961 --- Comment #8 from paul.richard.thomas at gmail dot com --- Hi Harald, I have just returned from a trip to the General Atomics DIIID facility in San Diego and feel like death warmed up :-( I'll try to get to the backport this afternoon once I have unpacked and had a nap. Regards Paul On Sat, 29 Jul 2023 at 21:18, anlauf at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > CC||anlauf at gcc dot gnu.org > > --- Comment #7 from anlauf at gcc dot gnu.org --- > (In reply to Paul Thomas from comment #6) > > I will backport to 13-branch in a few weeks. > > Could you please ping me after the backport? > > I would like to backport the fix for pr110825 and avoid a merge conflict, > as the changes are adjacent. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug.
[Bug fortran/109066] Segfault when using defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066 --- Comment #4 from paul.richard.thomas at gmail dot com --- Hi Steve, Indeed - I found that paragraph shortly after writing. Thanks for posting it. Cheers Paul On Thu, 9 Mar 2023 at 15:33, kargl at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066 > > kargl at gcc dot gnu.org changed: > >What|Removed |Added > > > CC||kargl at gcc dot gnu.org > > --- Comment #3 from kargl at gcc dot gnu.org --- > (In reply to Paul Thomas from comment #2) > > Hi Andrew, > > > > Thanks for the report. However, IMHO the code is invalid since the > result of > > hdf5Constructor is not defined. > > > > function hdf5Constructor() result(self) > > implicit none > > type(hdf5Object) :: self > > self = hdf5Object (resourceManager()) > > return > > end function hdf5Constructor > > > > works a treat. > > > > If there is a requirement in the standard that a function result such as > > this be initialised, I am unable to find it in the F2018 standard. > > > > Paul > > F2018, page 319. > If the function result is not a pointer, its value shall be defined by > the function. If the function result is a pointer, on return the pointer > association status of the function result shall not be undefined. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/104382] Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 --- Comment #5 from paul.richard.thomas at gmail dot com --- Hi Thomas, My stepping out of gfortran activities has been for rather longer than I expected. I had hoped to have completed the finalization work by now and to have got on with fixing PDTs. I will try to find the time over the summer because it is evident that a sufficient number of colleagues are on vacation that sustaining the pace of work might be difficult :-) I hope that all is well with you. Paul On Wed, 10 Aug 2022 at 08:40, tkoenig at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 > > Thomas Koenig changed: > >What|Removed |Added > > > CC||tkoenig at gcc dot > gnu.org > > --- Comment #4 from Thomas Koenig --- > To add some variety to the tests, nagfor gives > > destructor4(complicated) 2.000 2.000 > destructor5 (simple2) 5 > destructor5 (simple2) 6 > destructor2(simple) 1 1 > final_count after assignment = 4 > destructor4(complicated) 4.000 5.000 > destructor5 (simple2) -1 > destructor5 (simple2) -2 > destructor2(simple) 3 4 > final_count after deallocation = 8 > > -- > You are receiving this mail because: > You reported the bug.
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #17 from paul.richard.thomas at gmail dot com ---
Good morning all,
I have attached the revised patch and an additional testcase. I had totally
forgotten about the class pointer gotcha.
OK for master?
Paul
Fortran: Fix runtime errors for class actual arguments [PR99602].
2021-03-18 Paul Thomas
gcc/fortran
PR fortran/99602
* trans-array.c (gfc_conv_procedure_call): For class formal
arguments, use the _data field attributes for runtime errors.
For class expressions use the class_pointer attribute.
gcc/testsuite/
PR fortran/99602
* gfortran.dg/pr99602.f90: New test.
* gfortran.dg/pr99602a.f90: New test.
On Wed, 17 Mar 2021 at 17:57, anlauf at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
>
> --- Comment #16 from anlauf at gcc dot gnu.org ---
> (In reply to Jürgen Reuter from comment #15)
> > > LGTM. It's by Paul. He simply needs to get the testcase's dg-foo
> right...
> > > ;-)
> >
> > Now I'm confused. So you consider the fix ok? Will it then be committed?
>
> The fix was basically OKed on the fortran ML by Tobias, he only wondered
> if there should be a runtime test. One could simply change the line
>
> ! { dg-do compile }
>
> to
>
> ! { dg-do run }
>
> before committing. Still confused?
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> You are on the CC list for the bug.
[Bug fortran/96386] Internal compiler error in ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96386 --- Comment #3 from paul.richard.thomas at gmail dot com --- Hi Thomas, When did it get fixed? I seem to have done so many associate fixes that I barely know where to start - was it even me? Lots of the recent PRs are low lying fruit. It's pleasing to see patches of a few lines doing the job :-) Are you on to teams now? Cheers Paul On Mon, 25 Jan 2021 at 19:36, tkoenig at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96386 > > Thomas Koenig changed: > >What|Removed |Added > > > Resolution|--- |FIXED > CC||tkoenig at gcc dot > gnu.org > Status|NEW |RESOLVED > > --- Comment #2 from Thomas Koenig --- > The code has been fixed in the meantime. I have committed the > test case as r11-6899-g7d54cccad332074d5fb81123796239f0f61b11a7 > to make sure there is no regression. > > Thanks for the bug report! > > -- > You are receiving this mail because: > You are on the CC list for the bug.
