From patchwork Mon Apr 3 19:03:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nathan Sidwell X-Patchwork-Id: 746636 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vxhNR3xKcz9s7m for ; Tue, 4 Apr 2017 05:04:07 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Dv/F40mZ"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:cc:message-id:date:mime-version:content-type; q=dns; s=default; b=SZ8IToEXlPBnm+aWZ2bCsTheDALKtDxCJRtLjmGpfyC73snyey Fa6Du36AYD2slCPehqz/6cPdnaSlvaAJoILsUmC3Gu5gkNuJffk6Yrflclo3gQtD jUFI2ixJgyYDZCT3R7oelS7j1ZGdvhOUR/kW8bMzQGhPi+Q9HAnhYnnsY= 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:from :subject:to:cc:message-id:date:mime-version:content-type; s= default; bh=Uaf59rzmZsodKHwZHp/5aHa/bY4=; b=Dv/F40mZFOgV6O64bbtF OGigikb7Hk5Ti5lpiyS6atlG63YZC/GU6GTzGCU/NsQrs89vGJVYNtddAV7jD2Ni Aek8dgo9g51YuNGfTUaucxNyDFQxIvNAGeZ9TxtUC7dldixjZGOiybXKDSYnimMo H0BI+HKScbq9uodxkvW8ivw= Received: (qmail 96378 invoked by alias); 3 Apr 2017 19:03:59 -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 96364 invoked by uid 89); 3 Apr 2017 19:03:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.4 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-yb0-f171.google.com Received: from mail-yb0-f171.google.com (HELO mail-yb0-f171.google.com) (209.85.213.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Apr 2017 19:03:57 +0000 Received: by mail-yb0-f171.google.com with SMTP id i124so40679011ybc.3 for ; Mon, 03 Apr 2017 12:03:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:subject:to:cc:message-id:date :user-agent:mime-version; bh=ItL3O9OEPdKlbLYV+SHkCbRg+NE053LtHAvcF/jmcmw=; b=uYeL+XvK3sQj4+7EZG4Ncyddys9VUR3p2W74bd4KFABrNAWda4sxs9zLUGqMNgxOBX f+0rVaaDzcyxYdZMLujQNr4OVeKp7mR6Ov7O4oqkCcBvSrvbXuKPb8izZCi6P7C4y1qX P51gUEMftZYnMrA50Dyfv+v+JwAFLyY1zkHg6gPl/CJhjFsP6cdVVAFnlRBnaUF/JjcZ jaMruU+csE7IjL37A1DDBc5qPXg3/pZzbBG6opPM1JsUvvPzQ3LIcxoLwdNHlUwBnbdu MvUBnrn/Iox3VY9X3IoW/jimIJHXGi+c39LHpCIYjZBAn2/btr1AoJTEEIjYXmpbwuDJ MMuw== X-Gm-Message-State: AFeK/H2O6dhi8qGJ5A78dPJ5i0NOq3I+FZTMIAVDFpdk6/uPkFXSQpgTE0ssd2wFQxjc6A== X-Received: by 10.13.251.197 with SMTP id l188mr12865804ywf.113.1491246236904; Mon, 03 Apr 2017 12:03:56 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a3:20fb:f6d0:5ac5:64cd:f102? ([2620:10d:c091:200::2:e3ca]) by smtp.googlemail.com with ESMTPSA id f6sm7003675ywd.78.2017.04.03.12.03.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 12:03:56 -0700 (PDT) From: Nathan Sidwell Subject: [PR 79905] ICE with vector_type To: wschmidt@linux.vnet.ibm.com Cc: GCC Patches Message-ID: Date: Mon, 3 Apr 2017 15:03:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Bill, can you give this patch a spin please? I've smoke tested it on a ppc64le x-compiler, but don't have one to run executables. regression testing on an x86_64-linux system is ok. The DEPENDENT_TYPE_VALID_P thing is a red herring. It is the canonical type table's equal function considering most types with different TYPE_NAMEs to be different. Now, you might think that only applies to things like RECORD_TYPE, but no, wchar_t is different from plain int, for example. However, as you can see there's already a get-out for COMPLEX_TYPE, and I think the same is needed for VECTOR_TYPE. Both set_underlying_type and rs6000 set the builtin vector type's TYPE_NAME, and so one constructed via applying __attribute__((vector_size(16))) will never match. And it should. nathan Index: tree.c =================================================================== --- tree.c (revision 246647) +++ tree.c (working copy) @@ -7005,10 +7005,11 @@ type_cache_hasher::equal (type_hash *a, if (a->hash != b->hash || TREE_CODE (a->type) != TREE_CODE (b->type) || TREE_TYPE (a->type) != TREE_TYPE (b->type) - || !attribute_list_equal (TYPE_ATTRIBUTES (a->type), - TYPE_ATTRIBUTES (b->type)) || (TREE_CODE (a->type) != COMPLEX_TYPE - && TYPE_NAME (a->type) != TYPE_NAME (b->type))) + && TREE_CODE (a->type) != VECTOR_TYPE + && TYPE_NAME (a->type) != TYPE_NAME (b->type)) + || !attribute_list_equal (TYPE_ATTRIBUTES (a->type), + TYPE_ATTRIBUTES (b->type))) return 0; /* Be careful about comparing arrays before and after the element type