From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31497 invoked by alias); 17 Feb 2003 15:36:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 31476 invoked by uid 71); 17 Feb 2003 15:36:00 -0000 Resent-Date: 17 Feb 2003 15:36:00 -0000 Resent-Message-ID: <20030217153600.31475.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, jbeulich@novell.com Received: (qmail 28762 invoked by uid 48); 17 Feb 2003 15:32:32 -0000 Message-Id: <20030217153232.28761.qmail@sources.redhat.com> Date: Mon, 17 Feb 2003 15:36:00 -0000 From: jbeulich@novell.com Reply-To: jbeulich@novell.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: middle-end/9725: Invalid dependency determination X-SW-Source: 2003-02/txt/msg00713.txt.bz2 List-Id: >Number: 9725 >Category: middle-end >Synopsis: Invalid dependency determination >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Mon Feb 17 15:36:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: Jan Beulich >Release: gcc-3.2.2 >Organization: >Environment: Cygwin host, various targets. >Description: The code below, compiled with -O2 (or -O1 -fstrict-aliasing) causes the compiler to omit (or, in a non-contrived environment) incorrectly schedule the second store. This appears to be related to the incorrect assumption in alias.c (three places) that different alias sets provide for non-conflicting memory accesses; this isn't true if I understand the concept of alias sets (as explained close to the top of that file) correctly; instead, only the inverse conclusion would guarantee correct code - if two accesses are in the same alias set, then there potentially is a conflict. However, the simple change to invert the tests (and return values) in the three affected functions yields various cases where scheduling non-conflicting stores ahead of other operations is suppressed, so appearantly a better than this trivial fix is needed. An interesting (and worrying, at least to me) additional note is that when the type of the second structure field is 'unsigned char' the problem is not present. >How-To-Repeat: struct s { unsigned int h; unsigned short q; }; void test(unsigned long long*pf, unsigned int h, unsigned short q) { unsigned long long f; ((struct s*)&f)->h = h; ((struct s*)&f)->q = q; *pf = f; } >Fix: The simple (to at least guarantee correct code) but inefficient fix is to invert (and move down as far as possible the three instances of if (DIFFERENT_ALIAS_SETS_P (x, mem)) return 0; to if (!DIFFERENT_ALIAS_SETS_P (x, mem)) return 1; in alias.c. >Release-Note: >Audit-Trail: >Unformatted: