Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
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 elimination in OMP Workshare) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 (forall) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154 (matmul in where) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 (in associate). If you want to do the finalization of function results via a front end pass, creating a variable and then assigning it from within these constructs can cause these kinds of problems. Best regards Thomas
Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)
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: > Hello world, > > this patch fixes Fortran's handling of common subexpression elimination > across ieee_set_rouding_mode calls. It does so using a rather big > hammer, by issuing a memory barrier to force reload from memory > (and thus a recomputation). > > This is a rather big hammer, so if there are more elegant ways > to fix it, I am very much open to suggestions. > > If PR 34678 is fixed, then this solution can also be applied here. > > OK for trunk? How do you feel about a backport? > > Best regards > > Thomas > > Add memory barrier for calls to ieee_set_rounding_mode. > > gcc/fortran/ChangeLog: > > PR fortran/108329 > * trans-expr.cc (trans_memory_barrier): New functions. > (gfc_conv_procedure_call): Insert memory barrier for > ieee_set_rounding_mode. > > gcc/testsuite/ChangeLog: > > PR fortran/108329 > * gfortran.dg/rounding_4.f90: New test. -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
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 think that it is compatible both with forall and where constructs. I guess that I should check whether or not generate_component_assignments should not be placed within frontend_passes.cc. This part of resolve.cc precedes your efforts, I believe. Generating the final calls in the frontend would eliminate a substantial amount of rather opaque code. Best regards Paul On Sun, 8 Jan 2023 at 12:03, Thomas Koenig wrote: > 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 > elimination in OMP Workshare) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 (forall) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154 (matmul > in where) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 (in > associate). > > If you want to do the finalization of function results via > a front end pass, creating a variable and then assigning it > from within these constructs can cause these kinds of problems. > > Best regards > > Thomas > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)
> Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran > : > > Hi Thomas, > > Following your off-line explanation that the seemingly empty looking > assembly line forces an effective reload from memory, all is now clear. It’s not a full fix (for register vars) and it’s ‚superior‘ to the call itself only because asm handling is implemented in a rather stupid way in the Alias oracle. So I don’t think this is a „fix“ at all. Richard > 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: >> >> Hello world, >> >> this patch fixes Fortran's handling of common subexpression elimination >> across ieee_set_rouding_mode calls. It does so using a rather big >> hammer, by issuing a memory barrier to force reload from memory >> (and thus a recomputation). >> >> This is a rather big hammer, so if there are more elegant ways >> to fix it, I am very much open to suggestions. >> >> If PR 34678 is fixed, then this solution can also be applied here. >> >> OK for trunk? How do you feel about a backport? >> >> Best regards >> >>Thomas >> >> Add memory barrier for calls to ieee_set_rounding_mode. >> >> gcc/fortran/ChangeLog: >> >> PR fortran/108329 >> * trans-expr.cc (trans_memory_barrier): New functions. >> (gfc_conv_procedure_call): Insert memory barrier for >> ieee_set_rounding_mode. >> >> gcc/testsuite/ChangeLog: >> >> PR fortran/108329 >> * gfortran.dg/rounding_4.f90: New test. > > > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein
Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)
Hi Richard, Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran : Hi Thomas, Following your off-line explanation that the seemingly empty looking assembly line forces an effective reload from memory, all is now clear. It’s not a full fix (for register vars) and it’s ‚superior‘ to the call itself only because asm handling is implemented in a rather stupid way in the Alias oracle. So I don’t think this is a „fix“ at all. There are no register variables in Fortran, this is Fortran FE only, and it is a fix in the sense that correct code is no longer miscompiled. There's a FIXME in the code pointing to the relevant PR precisely because I think that this is less than elegant (as do you, obviously). Do you have other suggestions how to implement this? If PR 34678 is solved, this would probably provide a mechanism that we could simply re-use. Best regards Thomas
