On Wed, Feb 21, 2024 at 09:28:16PM +0100, Harald Anlauf wrote: > On 2/21/24 20:41, Jerry D wrote: > > On 2/21/24 10:30 AM, Steve Kargl wrote: > > > I have attached a patch to PR114024, see > > > > > > https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html > > > > > > The patch contains a new testcase and passes regression > > > testing on x86_64-*-freebsd. Could someone castr an eye > > > over the patch and commit it? > > > > > > > Hi Steve, > > > > I looked it over and looks reasonable. I will try to apply it next few > > days and test here. If OK, I will commit. > > > > Jerry > > > > Actually the patch has two issues: > > - a minor one: a new front-end memleak which can be avoided by > using either gfc_replace_expr (see its other uses) > Hint: try valgrind on f951
Unfortunately, valgrind does not work on AMD FX-8350 cpu. memleak vs ICE. I think I'll take one over the other. Probably need to free code->expr3 before the copy. I tried gfc_replace_expr in an earlier patch. It did not work. > - it still fails on the following code, because the traversal > of the refs is incomplete / wrong: > > program foo > implicit none > complex :: cmp(3) > real, pointer :: pp(:) > class(*), allocatable :: uu(:) > type t > real :: re > real :: im > end type t > type u > type(t) :: tt(3) > end type u > type(u) :: cc > > cmp = (3.45,6.78) > cc% tt% re = cmp% re > cc% tt% im = cmp% im > allocate (pp, source = cc% tt% im) ! ICE cc%tt%im isn't a complex-part-ref, so this seems to be a different (maybe related) issue. Does the code compile with 'source = (cc%tt%im)'? If so, perhaps, detecting a component reference and doing the simply wrapping with parentheses can be done. > print *, pp > allocate (uu, source = cc% tt% im) ! ICE Ditto. Not to mention I know nothing about the implementation of CLASS in gfortran. -- Steve
