From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13563 invoked by alias); 9 Jun 2009 17:30:31 -0000 Received: (qmail 13549 invoked by uid 22791); 9 Jun 2009 17:30:29 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from qw-out-1920.google.com (HELO qw-out-1920.google.com) (74.125.92.145) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Jun 2009 17:30:23 +0000 Received: by qw-out-1920.google.com with SMTP id 4so79028qwk.14 for ; Tue, 09 Jun 2009 10:30:20 -0700 (PDT) Received: by 10.224.67.196 with SMTP id s4mr424096qai.198.1244568620696; Tue, 09 Jun 2009 10:30:20 -0700 (PDT) Received: from yakj.usersys.redhat.com (nat-pool-brq.redhat.com [62.40.79.66]) by mx.google.com with ESMTPS id 6sm134479qwk.30.2009.06.09.10.30.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 10:30:19 -0700 (PDT) Message-ID: <4A2E9C1D.7030209@gmail.com> Date: Tue, 09 Jun 2009 17:30:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.17 (X11/20081009) MIME-Version: 1.0 To: Richard Guenther , Steven Bosscher , gcc-patches@gcc.gnu.org, dnovillo@google.com Subject: Re: [PATCH] fix arm neon ICE by widening tree_type's precision field References: <20090608153204.GW21107@codesourcery.com> <4A2D52B2.1090409@gmail.com> <20090608202757.GX21107@codesourcery.com> <4A2E02EB.9070509@gmail.com> <20090609145403.GZ21107@codesourcery.com> <571f6b510906090840m3848d987g5d89c5ad6cd6836a@mail.gmail.com> <84fc9c000906090845q6f9c1dcdr2d2ab0d33ab4147f@mail.gmail.com> <20090609163111.GA21107@codesourcery.com> In-Reply-To: <20090609163111.GA21107@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2009-06/txt/msg00776.txt.bz2 > OK, how about this slightly more aggressive patch, which: > > - Moves packed_flag and user_align into tree_base; I won't complain but, at some point, I'd rather see the flags in tree_base called base_flag_{0,...} if we decide to go this way... (or base_had_some_spare_bits_lets_use_them_for_flag_0). :-) Paolo