Segmentation fault on exit from a custom constructor of an inherited type that has no new data members
I've discovered an apparent bug in gfortran 13.2.1, which to me looks like it could be a duplicate of an existing bug. I'm wondering if I should add a comment to the existing bug with my MWE code, file a new bug and reference the existing one as possibly related, or not file a bug since it's probably a duplicate. Here's the details of the bug. The attached program produces a segmentation fault in gfortran 13.2 and later but not in gfortran 11 or 12. From my own experimentation and that of some community members on the fortran-lang discourse, we determined that the following is required to trigger the segmentation fault: - A child type inherits from a parent type, but adds no new data members - The child type has a finalization procedure - A variable of the child type is instantiated by calling a custom constructor You can see the Discourse discussion on this at https://fortran-lang.discourse.group/t/segmentation-fault-when-finalizing-an-inherited-type-with-custom-constructor/7319. In the discussion it was pointed out that this might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987. In light of that, I'm wondering if it would be best to file a bug on this, or to *not* file a bug since it's a likely duplicate of an existing bug. segfault_finalizing_type.f90 Description: Binary data
Re: GPU offloading question
> Am 03.02.2024 um 01:22 schrieb Steve Kargl > : > > All, > > Suppose one is working in a funding-constrained environment > such as an academician with limited grant funding. If one > wanted to dabble in GPU offloading with gcc/gfortran, what > recommendations would one have for minimum required hardware? > In addition, are there any vendor software layers that are > required (such as AMD ROCm with an AMD GPU)? You need the HSA runtime for AMD which comes with ROCm and libcuda for NvIDIA which comes with CUDA. I’ve had success getting both a very low end gtx1650 and a high end rx6900xt running with simple offloading. The officially supported set of hardware is way bigger with CUDA when it comes to lower end cards. I can’t say anything about performance with regard to how GCC handles both. Note that double precision math performance is said to be severely constrained for consumer hardware. Richard > > -- > Steve
Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.
Jerry, Steve, Am 03.02.24 um 04:24 schrieb Steve Kargl: Jerry, The patch looks good to me, but please give Harald a chance to comment. I just tested it a little, and it looked good. We even get a runtime error on E0.0 now as required. :-) Thanks for the patch! Harald
Re: Segmentation fault on exit from a custom constructor of an inherited type that has no new data members
If you have a gcc bugzilla account, add a comment to the exist bug with your example. The execution paths through gfortran for CLASS and "derive type" have significant overlap, so likely a patch the CLASS issue may also fix your issue. Note, if you comment out the generic interface for "child", the code compiles and executes as expected. Interestingly, the Fortran standard permits this overloading of a structure constructor. -- steve On Sat, Feb 03, 2024 at 07:50:43AM -0500, John Haiducek wrote: > I've discovered an apparent bug in gfortran 13.2.1, which to me looks like > it could be a duplicate of an existing bug. I'm wondering if I should add a > comment to the existing bug with my MWE code, file a new bug and reference > the existing one as possibly related, or not file a bug since it's probably > a duplicate. > > Here's the details of the bug. The attached program produces a segmentation > fault in gfortran 13.2 and later but not in gfortran 11 or 12. From my own > experimentation and that of some community members on the fortran-lang > discourse, we determined that the following is required to trigger the > segmentation fault: > > - A child type inherits from a parent type, but adds no new data members > - The child type has a finalization procedure > - A variable of the child type is instantiated by calling a custom > constructor > > You can see the Discourse discussion on this at > https://fortran-lang.discourse.group/t/segmentation-fault-when-finalizing-an-inherited-type-with-custom-constructor/7319. > > > In the discussion it was pointed out that this might be related to > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987. In light of that, I'm > wondering if it would be best to file a bug on this, or to *not* file a bug > since it's a likely duplicate of an existing bug. -- Steve
Re: GPU offloading question
On Sat, Feb 03, 2024 at 02:37:05PM +0100, Richard Biener wrote: > > > Am 03.02.2024 um 01:22 schrieb Steve Kargl > > : > > > > All, > > > > Suppose one is working in a funding-constrained environment > > such as an academician with limited grant funding. If one > > wanted to dabble in GPU offloading with gcc/gfortran, what > > recommendations would one have for minimum required hardware? > > In addition, are there any vendor software layers that are > > required (such as AMD ROCm with an AMD GPU)? > > You need the HSA runtime for AMD which comes with ROCm and libcuda > for NvIDIA which comes with CUDA. Thanks. I'll need to check the level of support for the above in FreeBSD. I suspect it's non-existent, so looks like I'll take a plunge down the linux rabbit hole. > I’ve had success getting both a very low end gtx1650 and a high > end rx6900xt running with simple offloading. The officially supported > set of hardware is way bigger with CUDA when it comes to lower end cards. > > I can’t say anything about performance with regard to how GCC handles both. > > Note that double precision math performance is said to be severely > constrained for consumer hardware. Ah, good point. I'll need to find a card I can afford that supports double precision. -- steve > > Richard > > > > > -- > > Steve -- Steve
Re: GPU offloading question
On 03/02/2024 19.13, Steve Kargl wrote: > On Sat, Feb 03, 2024 at 02:37:05PM +0100, Richard Biener wrote: >> >>> Am 03.02.2024 um 01:22 schrieb Steve Kargl >>> : >>> >>> All, >>> >>> Suppose one is working in a funding-constrained environment >>> such as an academician with limited grant funding. If one >>> wanted to dabble in GPU offloading with gcc/gfortran, what >>> recommendations would one have for minimum required hardware? >>> In addition, are there any vendor software layers that are >>> required (such as AMD ROCm with an AMD GPU)? >> >> You need the HSA runtime for AMD which comes with ROCm and libcuda >> for NvIDIA which comes with CUDA. > > Thanks. I'll need to check the level of support for the above > in FreeBSD. I suspect it's non-existent, so looks like I'll take > a plunge down the linux rabbit hole. > >> I’ve had success getting both a very low end gtx1650 and a high >> end rx6900xt running with simple offloading. The officially supported >> set of hardware is way bigger with CUDA when it comes to lower end cards. >> >> I can’t say anything about performance with regard to how GCC handles both. >> >> Note that double precision math performance is said to be severely >> constrained for consumer hardware. > > Ah, good point. I'll need to find a card I can afford that supports > double precision. > > Consider https://allocations.access-ci.org/resources for a PI based in the USA. Use the limited funding to support your time improving off loading support for GFortran.
Re: GPU offloading question
On Sat, Feb 03, 2024 at 09:15:21PM +0300, Benson Muite wrote: > >>> I wrote: > >>> Suppose one is working in a funding-constrained environment > >>> such as an academician with limited grant funding. If one > >>> wanted to dabble in GPU offloading with gcc/gfortran, what > >>> recommendations would one have for minimum required hardware? > >>> In addition, are there any vendor software layers that are > >>> required (such as AMD ROCm with an AMD GPU)? > >> > > > Consider https://allocations.access-ci.org/resources > for a PI based in the USA. Use the limited funding to support your time > improving off loading support for GFortran. Thanks for the link. I'll see what might be available to me. I already support gfortran development (although not offloading) with my limited time. See gcc/fortran/ChangeLog* from the last 25 or so years. :-) -- Steve
Re: GPU offloading question
> Am 03.02.2024 um 19:15 schrieb Benson Muite : > > On 03/02/2024 19.13, Steve Kargl wrote: >>> On Sat, Feb 03, 2024 at 02:37:05PM +0100, Richard Biener wrote: >>> Am 03.02.2024 um 01:22 schrieb Steve Kargl : All, Suppose one is working in a funding-constrained environment such as an academician with limited grant funding. If one wanted to dabble in GPU offloading with gcc/gfortran, what recommendations would one have for minimum required hardware? In addition, are there any vendor software layers that are required (such as AMD ROCm with an AMD GPU)? >>> >>> You need the HSA runtime for AMD which comes with ROCm and libcuda >>> for NvIDIA which comes with CUDA. >> >> Thanks. I'll need to check the level of support for the above >> in FreeBSD. I suspect it's non-existent, so looks like I'll take >> a plunge down the linux rabbit hole Support is likely non existent on FreeBSD since there’s a driver component as well. For modern GPUs the driver is open source in Linux for both vendors but the firmware is not. CUDA is proprietary while the HSA runtime part is easily built from source (it’s hosted on GitHub) >>> I’ve had success getting both a very low end gtx1650 and a high >>> end rx6900xt running with simple offloading. The officially supported >>> set of hardware is way bigger with CUDA when it comes to lower end cards. >>> >>> I can’t say anything about performance with regard to how GCC handles both. >>> >>> Note that double precision math performance is said to be severely >>> constrained for consumer hardware. >> >> Ah, good point. I'll need to find a card I can afford that supports >> double precision. >> >> > Consider https://allocations.access-ci.org/resources > for a PI based in the USA. Use the limited funding to support your time > improving off loading support for GFortran. Yeah, I would also suggest development resources available as part of SC center access here. Richard
