From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 702453858D35 for ; Mon, 27 Jul 2020 09:09:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 702453858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 19E7DD6E; Mon, 27 Jul 2020 02:09:01 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7EDC93F718; Mon, 27 Jul 2020 02:09:00 -0700 (PDT) From: Richard Sandiford To: Richard Biener via Gcc-patches Mail-Followup-To: Richard Biener via Gcc-patches , Stefan Schulze Frielinghaus , Richard Biener , richard.sandiford@arm.com Subject: Re: [PATCH] [RFC] vect: Fix infinite loop while determining peeling amount In-Reply-To: (Richard Biener via Gcc-patches's message of "Mon, 27 Jul 2020 09:06:04 +0200") Date: Mon, 27 Jul 2020 09:41:01 +0100 Message-ID: References: <20200722151450.1540130-1-stefansf@linux.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 09:09:02 -0000 Richard Biener via Gcc-patches writes: > On Wed, Jul 22, 2020 at 5:18 PM Stefan Schulze Frielinghaus via > Gcc-patches wrote: >> >> This is a follow up to commit 5c9669a0e6c respectively discussion >> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549132.html >> >> In case that an alignment constraint is less than the size of a >> corresponding scalar type, ensure that we advance at least by one >> iteration. For example, on s390x we have for a long double an alignment >> constraint of 8 bytes whereas the size is 16 bytes. Therefore, >> TARGET_ALIGN / DR_SIZE equals zero resulting in an infinite loop which >> can be reproduced by the following MWE: > > But we guard this case with vector_alignment_reachable_p, so we shouldn't > have ended up here and the patch looks bogus. The above sounds like it ought to count as reachable alignment though. If a type requires a lower alignment than its size, then that's even more easily reachable than a type that requires the same alignment as the size. I guess at one extreme, a target alignment of 1 is always reachable. Thanks, Richard