From patchwork Wed Jun 26 19:53:45 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 254851 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 7CA862C0096 for ; Thu, 27 Jun 2013 05:54:00 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=TYy8IgEZkT964fqvXiwyCuCjbWzg/ cnUMI+Jo1U6K2qGk79sEPr0MD0rOz2Wn5yUZzNPr945Hy43kJLOPo3c30p5JDUWZ z0p7dsRnMT1Pg1xI+SObrqh6RanZhZqRU15jOvFNhZ7ZykAZyQg5679GeTDbAEW+ oTegEY6pzsNNHc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=oyn38tPVCEtUf27O+GcVqJPiSgA=; b=TAm jqh+6meJ9em0xJkVpT2ohfcaV9QbKo8azux2lYKUdIucoewCNOAXn3dZk5s/+Nl1 E7Oc+2DXW1trhTR2NcEpnhi4yZfHZyELI9R4Bv8nKHwE1nor47rKk5fMJKvNoeGp x4vK9rbFzVHAFpoAnnxTaQNvsJKywnRwSHecE4hQ= Received: (qmail 29629 invoked by alias); 26 Jun 2013 19:53:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 29595 invoked by uid 89); 26 Jun 2013 19:53:50 -0000 X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS, TW_TM autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 26 Jun 2013 19:53:50 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5QJrmHb011844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jun 2013 15:53:48 -0400 Received: from zalov.cz (vpn1-6-121.ams2.redhat.com [10.36.6.121]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5QJrlAN019796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 15:53:48 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r5QJrkpY006912; Wed, 26 Jun 2013 21:53:46 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r5QJrjuJ006911; Wed, 26 Jun 2013 21:53:45 +0200 Date: Wed, 26 Jun 2013 21:53:45 +0200 From: Jakub Jelinek To: Richard Biener , Richard Henderson Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix vectorizable_store Message-ID: <20130626195345.GY2336@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Hi! On the gomp4 branch I've noticed a miscompilation of the simd-3.C testcase I'm adding there, but even say int a[1024] __attribute__((aligned (32))) = { 1 }; int b[1024] __attribute__((aligned (32))) = { 1 }; unsigned short c[1024] __attribute__((aligned (32))) = { 1 }; __attribute__((noinline, noclone)) void foo (int *p) { int i; p = (int *) __builtin_assume_aligned (p, 32); for (i = 0; i < 512; i++) { a[i] *= p[i]; c[i]++; } } int main () { int i; for (i = 0; i < 512; i++) { a[i] = i - 512; b[i] = (i - 51) % 39; c[i] = (unsigned short) i; } foo (b); for (i = 0; i < 512; i++) if (b[i] != (i - 51) % 39 || a[i] != (i - 512) * b[i] || c[i] != (unsigned short) (i + 1)) __builtin_abort (); return 0; } without -fopenmp, just -O3 -mavx. The relevant change was just that ptr_incr has been initialized to NULL in both vectorizable_store and vectorizable_load, because vect_create_data_ref_ptr doesn't initialize it if only_init is true. Looking at it, we just trigger undefined behavior and are just lucky that it works by accident on the trunk and branches. The problem is that if ncopies > 1, vectorizable_store declares the variable inside of the loop, for j == 0 it initializes it through vect_create_data_ref_ptr, but then on the next iteration the variable is uninitialized again (but just due to luck contains the value from the previous iteration, but say if compiler unrolled the loop, it would already misbehave) and then it is passed to bump_vector_ptr. Fixed by moving the var decl outside of the loop. While not strictly necessary, I find it cleaner to initialize it to NULL, though if you disagree with it, I can keep that change local to gomp4 branch for now (i.e. remove " = NULL" from the first hunk and the third hunk). Ok for trunk/4.8? 2013-06-26 Jakub Jelinek * tree-vect-stmts.c (vectorizable_store): Move ptr_incr var decl before the loop, initialize to NULL. (vectorizable_load): Initialize ptr_incr to NULL. Jakub --- gcc/tree-vect-stmts.c.jj 2013-04-22 08:06:41.000000000 +0200 +++ gcc/tree-vect-stmts.c 2013-06-26 21:34:28.609654773 +0200 @@ -3796,6 +3796,7 @@ vectorizable_store (gimple stmt, gimple_ enum vect_def_type dt; stmt_vec_info prev_stmt_info = NULL; tree dataref_ptr = NULL_TREE; + gimple ptr_incr = NULL; int nunits = TYPE_VECTOR_SUBPARTS (vectype); int ncopies; int j; @@ -4041,7 +4042,6 @@ vectorizable_store (gimple stmt, gimple_ for (j = 0; j < ncopies; j++) { gimple new_stmt; - gimple ptr_incr; if (j == 0) { @@ -4314,7 +4314,7 @@ vectorizable_load (gimple stmt, gimple_s tree dummy; enum dr_alignment_support alignment_support_scheme; tree dataref_ptr = NULL_TREE; - gimple ptr_incr; + gimple ptr_incr = NULL; int nunits = TYPE_VECTOR_SUBPARTS (vectype); int ncopies; int i, j, group_size, group_gap;