From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id 456683858D34; Wed, 21 Feb 2024 21:42:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 456683858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 456683858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=128.95.76.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708551756; cv=none; b=AoNSHvN0WLm7dtkkacYmKsFhVL/kpcYTThI2PhxvqAUl6FEx9+tZI17YODHJEiBzTEP+26kA5a5d+A2RO8Ddj6tr/K9kelMvV7vtMzZ1/i+kRzRXnzUBIHXZcj+kz9QWsLecwJ2jNKMjV+rnX9vQdo1MhGuN6jObKf87eq5qCOo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708551756; c=relaxed/simple; bh=QSzxI57SIkQ4H1qeGyvQHzTpc+5JoBHLtqxJlJo8ym0=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=PivDXLlDe6u+CyPk7sIjMcAHl9QCwqx3fC2Tb5ikTAGz5UI+UTTtGuhv8cxt/g/tzTfsi1icPFZV+7kQ/FATfGOWVYZT6J3naFRPocb80Vu4mOPpwLFuNZojvGyDYZJiRtjjqhXiXYuo/P0VwJ69xI5v6GMyC7lBIs+nROXfBzg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 41LLgXnI089145; Wed, 21 Feb 2024 13:42:33 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 41LLgXnI089145 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1708551753; bh=QSzxI57SIkQ4H1qeGyvQHzTpc+5JoBHLtqxJlJo8ym0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=dBjQMSUI10tiIgtj9FDlOJP9bWViqkpR5Q3Y47utFJ4FLlMYnfjjzj68mGkpLdRd+ asHptywoQEW/fbYSxp17Tuogxr+Xpy6u8BPhKJP6K0m7ZKWGvm5ZjYoAz9hWNJb3IR mNZG1pEUenSPHf7mUoxWRLe7Nbt+Z7L3fovAJwidiXti4U8HuTvtWqWduKT4rjEygY PU60RriBl1Keo1ZAi5y5Cx0/GANb6LtZwjhFL5/3uxIeU1urkSmp1l/JNNGG9HEmXj zPAd6+mOlo01WCHZ+U/fLZvS/gGRZLCMBQ4f075RConLos2B3Dwrn0Xnjo+8ZZTDb9 ldcLnj69x4zNg== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 41LLgWXx089144; Wed, 21 Feb 2024 13:42:32 -0800 (PST) (envelope-from sgk) Date: Wed, 21 Feb 2024 13:42:32 -0800 From: Steve Kargl To: Harald Anlauf Cc: Jerry D , fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix fortran/PR114024 Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <29ba08a7-8218-4591-8c3f-36c17090e497@gmail.com> <3444d912-2e79-4e16-a425-79810d161ebb@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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