From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71757 invoked by alias); 5 May 2017 21:27:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 69273 invoked by uid 89); 5 May 2017 21:27:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 May 2017 21:27:47 +0000 Received: by mail-wm0-f46.google.com with SMTP id m123so16830088wma.0 for ; Fri, 05 May 2017 14:27:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=HC6FjotK9V52jxaStBN5qSCLZiiqk/9OZhHU1UCa/44=; b=RKw28z2D9O3rLKhE4x8LWkWeTxy1kzTY8w+VDTthWm7gQZEQtcnVTkyQXxZ01knpNk a8b3Zfpkgo3IuTF1TqrGA7ST5VzD11PE35zM4Glpxc6aaLp/neQlsjHAwWMb551nIzSR dfMn9bVoNAzr7bOofwwattSigkrEH0bHqhZHudAA1aWKyNw5mcsOW7Vg+Jhd4XoneUDS xRm2QjuEza6YiDAEqoRXxCPYlgHC1GETB/d8QmbvFT9BAAAanu5gnvkBD6QbBQ2zHdK+ m+1TNC7Od/lJWCnTzIt+yxUtFi9XqCtHNd/fuaYpG2OSI7a+w/F44GeidzBJ/hL2XAzs ZrAg== X-Gm-Message-State: AN3rC/4zwhySDi1M+qcgsUq5gt/eXNmSpSHOWdXcQ/7Q2sA9V+T8B2WP vqhe8wFzhBIGDw== X-Received: by 10.28.20.84 with SMTP id 81mr6673727wmu.51.1494019667452; Fri, 05 May 2017 14:27:47 -0700 (PDT) Received: from s49-GXYS7-B.weghof (212-60-180-250.adsl.highway.telekom.at. [212.60.180.250]) by smtp.gmail.com with ESMTPSA id e187sm4220624wmf.31.2017.05.05.14.27.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 14:27:46 -0700 (PDT) Date: Fri, 05 May 2017 22:03:00 -0000 In-Reply-To: References: <87tw52s73r.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Handle data dependence relations with different bases To: Richard Biener ,GCC Patches ,Richard Sandiford From: Bernhard Reutner-Fischer Message-ID: <59C09304-5211-4CE3-BB4A-3CE00109C92D@gmail.com> X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00461.txt.bz2 On 4 May 2017 14:12:04 CEST, Richard Biener wr= ote: >nonoverlapping_component_refs_of_decl_p >should simply skip ARRAY_REFs - but I also see there: > > /* ??? We cannot simply use the type of operand #0 of the refs here > as the Fortran compiler smuggles type punning into COMPONENT_REFs > for common blocks instead of using unions like everyone else. */ > tree type1 =3D DECL_CONTEXT (field1); > tree type2 =3D DECL_CONTEXT (field2); > >so you probably can't simply use TREE_TYPE (outer_ref) for type >compatibility. >You also may not use types_compatible_p here as for LTO that is _way_ >too >lax for aggregates. The above uses > > /* We cannot disambiguate fields in a union or qualified union. */ > if (type1 !=3D type2 || TREE_CODE (type1) !=3D RECORD_TYPE) > return false; > >so you should also bail out on unions here, rather than the check you >do later. > >You seem to rely on getting an access_fn entry for each >handled_component_p. >It looks like this is the case -- we even seem to stop at unions (with >the same >fortran "issue"). I'm not sure that's the best thing to do but you >rely on that. Is there a PR for the (IIUC) common as union? Maybe around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D41227 COMMON block, BIND(C) and LTO interoperability issues Thanks