On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote: > On 2/21/24 22:00, Steve Kargl wrote: > > Unfortunately, valgrind does not work on AMD FX-8350 cpu. > > Do you mean valgrind does not work at all? > For gcc, you need to configure --enable-valgrind-annotations > to not get bogus warnings.
It does not work at all unless one tracks done an obscure patch for valgrind. The FX-8350 has a tbm instruction. Everything on the system would need be compiled with -mno-tbm (or -fno-tbm). % valgrind ./z ... ==88861== Process terminating with default action of signal 4 (SIGILL): dumping core ==88861== Illegal opcode at address 0x4D30D87 ==88861== at 0x4D30D87: ??? (in /lib/libc.so.7) ==88861== by 0x4D213DE: ??? (in /lib/libc.so.7) ==88861== by 0x4D2B935: ??? (in /lib/libc.so.7) ==88861== by 0x4D2C34E: ??? (in /lib/libc.so.7) ==88861== by 0x400AB8C: ??? (in /libexec/ld-elf.so.1) ==88861== by 0x4009828: ??? (in /libexec/ld-elf.so.1) ==88861== by 0x4006AE8: ??? (in /libexec/ld-elf.so.1) > > memleak vs ICE. I think I'll take one over the other. > > Probably need to free code->expr3 before the copy. > > Yep. > > > 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. > > Yes, that's why I tried to make up the above example. > I think %re and %im are not too special, they work > here pretty much like component refs elsewhere. > I see. The %re and %im complex-part-ref correspond to ref->u.i == INQUIRY_RE and INQUIRY_IM, respectively. A part-ref for a user-defined type doesn't have an INQUIRY_xxx, so we'll need to see if there is a way to easily identify, e.g., cc%tt%re from your testcase. -- Steve
