[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.
[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/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/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/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/116040] [13 regression] New test case gfortran.dg/pr113363.f90 from r13-8926-g7c81ff02a943cd ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116040 --- Comment #2 from paul.richard.thomas at gmail dot com --- I am away on business right now and cannot deal with this. The plan is to revert the backport. Please feel free to do this because I am likely to be seriously jet lagged over the weekend. Regards Paul On Mon, 22 Jul 2024 at 21:47, seurer at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116040 > > seurer at gcc dot gnu.org changed: > >What|Removed |Added > > >Host||powerpc64-linux-gnu, >||powerpc64le-linux-gnu > Build||powerpc64-linux-gnu, >||powerpc64le-linux-gnu > Target||powerpc64-linux-gnu, >||powerpc64le-linux-gnu > CC||bergner at gcc dot > gnu.org, >||pault at gcc dot gnu.org > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 --- Comment #4 from paul.richard.thomas at gmail dot com --- Hi Harald, I logged various regressions before going on vacation. I'll be back in action next week. Regards Paul On Tue, 13 Aug 2024 at 20:58, anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > > CC||anlauf at gcc dot gnu.org > Status|UNCONFIRMED |NEW > Ever confirmed|0 |1 >Last reconfirmed||2024-08-13 > > --- Comment #3 from anlauf at gcc dot gnu.org --- > Running the resulting executable under valgrind shows issues that were not > present in gcc-14: there are many reports of the type > > ==11462== Conditional jump or move depends on uninitialised value(s) > ==11462==at 0x48386ED: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11462==by 0x428DF0: __final_MAIN___T.1 (sizeof_6.f90:5) > ==11462==by 0x42AF7C: __final_MAIN___T2.5 (sizeof_6.f90:5) > ==11462==by 0x426D1E: MAIN__ (sizeof_6.f90:281) > ==11462==by 0x42D581: main (sizeof_6.f90:287) > ==11462== > [...] > ==11462== Use of uninitialised value of size 8 > ==11462==at 0x428FD3: __final_MAIN___T.1 (sizeof_6.f90:5) > ==11462==by 0x42AF7C: __final_MAIN___T2.5 (sizeof_6.f90:5) > ==11462==by 0x426D1E: MAIN__ (sizeof_6.f90:281) > ==11462==by 0x42D581: main (sizeof_6.f90:287) > ==11462== > [...] > > Commenting lines 281..287 (six deallocates at the end of the main), > the issues seems to disappears. > > A bookkeeping issue in the finalization? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 --- Comment #8 from paul.richard.thomas at gmail dot com --- Hi Harald, I simply copied all the associated functions in trans-expr.cc from mainline and plonked them in 13-branch. That's why I said that I hadn't done any weeding. There is also a commit from Jakub in there as well. I'll check to see if the associated PRs are fixed. I got into regression fixing before the 14.1 release and this was one of the low hanging fruit. To be honest, I am not especially bothered about fixing it or not. Up until the ICE of the PR it was giving an error on valid code. I would prefer though that the ICE went away! Cheers Paul On Thu, 23 May 2024 at 19:18, anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 > > 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) > > Created attachment 58277 [details] > > Fix for this PR > > > > This was substantially fixed on 14-branch by the patch for PR49213. > However, > > there have been many subsequent changes to gfc_trans_structure_assign and > > its subsidiary functions as the attachment demonstrates. > > > > I haven't attempted to do any weeding of the changes to separate those > > responsible for fixing this PR. However, 13-branch regtests successfuly > with > > the patch applied. > > > > Should I commit this with a testcase or just close the PR? > > > > Paul > > Paul, > > can you summarize where you gathered the pieces of this patch from? > > From a quick glance, r14-870 and r14-2160 (both yours) seem to be involved. > > Does it also fix any of the issues addressed by the respective PRs? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee 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/83209] [12/13/14/15 Regression] [Coarray] Failure of allocation of a coarray with a pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83209 --- Comment #12 from paul.richard.thomas at gmail dot com --- Yes, indeed. Thanks Paul On Thu, 11 Jul 2024 at 12:28, vehre at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83209 > > Andre Vehreschild changed: > >What|Removed |Added > > >Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot > gnu.org > Status|NEW |WAITING > CC||vehre at gcc dot gnu.org > > --- Comment #10 from Andre Vehreschild --- > This work for me with gfortran 13.3.1 + and trunk. Ok to close? > > -- > You are receiving this mail because: > You reported the bug.
[Bug fortran/115700] [12/13 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 --- Comment #15 from paul.richard.thomas at gmail dot com --- Hi Harald, Yes indeed. This has already been flagged up by the folk at Arm. I was going to remove that test today. The functional test is done in associate_70.f90 in any case. Cheers Paul On Sat, 2 Nov 2024 at 18:32, anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 > > --- Comment #14 from anlauf at gcc dot gnu.org --- > (In reply to GCC Commits from comment #13) > > The master branch has been updated by Paul Thomas : > > > > https://gcc.gnu.org/g:7f93910a8b5d606ad742a3594750f0c2b20d8bda > > > > commit r15-4835-g7f93910a8b5d606ad742a3594750f0c2b20d8bda > > Author: Paul Thomas > > Date: Fri Nov 1 07:45:00 2024 + > > > > Fortran: Fix problems with substring selectors in ASSOCIATE > [PR115700] > > > > 2024-11-01 Paul Thomas > > > > gcc/fortran > > PR fortran/115700 > > * resolve.cc (resolve_assoc_var): Extract a substring > reference > > with missing as well as non-constant start or end. > > > > gcc/testsuite/ > > PR fortran/115700 > > * gfortran.dg/associate_69.f90: Activate commented out tests. > > * gfortran.dg/associate_70.f90: Test correct functioning of > > references in associate_69.f90 tests. > > Paul, > > the addition to testcase gfortran.dg/associate_69.f90 fails on 32-bit > targets > (or using -m32), which can be seen by comparing the dumps: for -m32 the > final > "stop 6" gets optimized away already at -Og, but not at -m64. So the > pattern > needs to be reconsidered. > > Can you have a look? > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug.
[Bug fortran/118640] [15 Regression] cp2k ICE in gfc_conv_expr_present since r15-5347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640 --- Comment #3 from paul.richard.thomas at gmail dot com --- Hi Jakub, I'll take it just as soon as I am in a position to do so - likely Sunday night or Monday morning. Thanks for the reduction. Paul On Fri, 24 Jan 2025, 13:39 jakub at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640 > > --- Comment #2 from Jakub Jelinek --- > Reduced testcase: > > module foo > type t1 > contains > procedure bar > generic :: assignment(=) => bar > end type > type t2 > type(t1) m > end type > contains > subroutine bar (x, y) > intent(in) y > class(t1), intent(out) :: x > end subroutine > end module > subroutine baz (x, y) > use foo > integer y > type(t2), pointer, optional :: x > interface > function qux (x) > use foo > integer x > type(t2) qux > end function > end interface > if (present (x)) then > x = qux (y) > end if > end subroutine > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/103391] [12/13/14/15 Regression] ICE: gimplification failed since r7-4021-g574284e9c49687d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391 --- Comment #9 from paul.richard.thomas at gmail dot com --- That was a question at the end, not a statement :-) I cannot see anything wrong with the test case but wondered if one of the more eagle-eyed of us could see a standardese problem with it. Have you had any experience with ChatGPT or similar? I was wondering whether or not it is up to the resolution of standard questions. Cheers Paul On Mon, 3 Mar 2025 at 14:34, vehre at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391 > > Andre Vehreschild changed: > >What|Removed |Added > > >Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot > gnu.org > Status|NEW |ASSIGNED > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/100818] A temporary is passed to associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818 --- Comment #5 from paul.richard.thomas at gmail dot com --- Hi Thomas, Thanks, that does indeed explain it. The é in José? I have put Sandra in copy because I just wrote to her about these PRs a few minutes ago. Obrigado Paul On Sun, 13 Apr 2025 at 17:52, tkoenig at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818 > > Thomas Koenig changed: > >What|Removed |Added > > > CC||tkoenig at gcc dot > gnu.org > > --- Comment #4 from Thomas Koenig --- > It was in > > commit d514626ee2566c68b8a79c7b99aaf791d69e1b2f > Author: José Rui Faustino de Sousa > Date: Sat Jun 5 11:12:50 2021 + > > Fortran: Fix some issues with pointers to character. > > gcc/fortran/ChangeLog: > > PR fortran/100120 > PR fortran/100816 > PR fortran/100818 > PR fortran/100819 > PR fortran/100821 > > I guess José was hit by the same problem that I was, that > a non-ascii character in the name on the sourceforge database > leads to bugzilla not getting automatic mails from commits. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
