From patchwork Sun Jan 16 09:21:50 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kai Tietz X-Patchwork-Id: 79080 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]) by ozlabs.org (Postfix) with SMTP id 5DE29B6EE8 for ; Sun, 16 Jan 2011 20:22:01 +1100 (EST) Received: (qmail 32685 invoked by alias); 16 Jan 2011 09:21:58 -0000 Received: (qmail 32675 invoked by uid 22791); 16 Jan 2011 09:21:56 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 16 Jan 2011 09:21:52 +0000 Received: by qwi2 with SMTP id 2so3834878qwi.20 for ; Sun, 16 Jan 2011 01:21:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.245.14 with SMTP id ls14mr2535796qcb.19.1295169710205; Sun, 16 Jan 2011 01:21:50 -0800 (PST) Received: by 10.229.214.131 with HTTP; Sun, 16 Jan 2011 01:21:50 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Jan 2011 10:21:50 +0100 Message-ID: Subject: Re: [patch java]: Intialize va_list_type_node to avoid segfault for x86_64 targets in respect for alignment From: Kai Tietz To: Richard Guenther Cc: Andreas Schwab , GCC Patches , Andrew Haley X-IsSubscribed: yes 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 2011/1/12 Richard Guenther : > On Tue, Jan 11, 2011 at 9:38 PM, Andreas Schwab wrote: >> Kai Tietz writes: >> >>> 2011/1/11 Andreas Schwab : >>>> Kai Tietz writes: >>>> >>>>> Andreas, did this patch fixed rs6000 java bootstrap for you? >>>> >>>> The discrepancies with TYPE_STRING_FLAG and char_type_node remain.  I >>>> don't know what kind of hidden effect that will have. >>>> >>>> Andreas. >>> >>> I don't know if there are side-effects, or not. I just know that this >>> type wasn't set before, so it seems not to be used before. >> >> But it is used now, so care must be taken.  Especially the different >> char_type_node is worrying. > > Indeed.  Please either revert the full series or work towards > using build_common_tree_nodes. > > Richard. > >> Andreas. Well, as described in bug-report this missing va_list_type_node in java's decl.c is a regression from 1999. I attaced a patch, which is reverting it, but it is a paper-patch. That char_type_node is used within va_list_type_node of java's decl.c, shouldn't lead here to any issues, as java FE didn't used that types before (as otherwise there would be ICEs without that patch already), and now those types are used just in va_list_type_node construction. The va_list types are just used in comparison by some backends. Java doesn't operate with va_list_type_node and you can't specify them within this language AFAICS. 2011-01-16 Kai Tietz PR bootstrap/47215 * decl.c (java_init_decl_processing): Remove va_list_type_node related type initializations. 2011-01-16 Kai Tietz PR bootstrap/47215 * config/i386/i386.c (ix86_local_alignment): Handle case for va_list_type_node is nil. (ix86_canonical_va_list_type): Likewise. Tested for x86_64-pc-linux-gnu and x86_64-w64-mingw32. Ok for apply? Regards, Kai Index: gcc/gcc/config/i386/i386.c =================================================================== --- gcc.orig/gcc/config/i386/i386.c 2011-01-09 14:50:57.000000000 +0100 +++ gcc/gcc/config/i386/i386.c 2011-01-16 09:53:42.379793400 +0100 @@ -22931,8 +22931,9 @@ ix86_local_alignment (tree exp, enum mac && TARGET_SSE) { if (AGGREGATE_TYPE_P (type) - && (TYPE_MAIN_VARIANT (type) - != TYPE_MAIN_VARIANT (va_list_type_node)) + && (va_list_type_node == NULL_TREE + || (TYPE_MAIN_VARIANT (type) + != TYPE_MAIN_VARIANT (va_list_type_node))) && TYPE_SIZE (type) && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 16 @@ -33682,7 +33683,7 @@ ix86_canonical_va_list_type (tree type) else if (POINTER_TYPE_P (type) && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE) type = TREE_TYPE (type); - if (TARGET_64BIT) + if (TARGET_64BIT && va_list_type_node != NULL_TREE) { wtype = va_list_type_node; gcc_assert (wtype != NULL_TREE); Index: gcc/gcc/java/decl.c =================================================================== --- gcc.orig/gcc/java/decl.c 2011-01-11 20:36:15.000000000 +0100 +++ gcc/gcc/java/decl.c 2011-01-16 09:46:13.187101100 +0100 @@ -1153,21 +1153,6 @@ java_init_decl_processing (void) soft_lrem_node = add_builtin_function ("_Jv_remJ", t, 0, NOT_BUILT_IN, NULL, NULL_TREE); - /* Initialize va_list_type_node. */ - unsigned_type_node = make_unsigned_type (INT_TYPE_SIZE); - long_integer_type_node = make_signed_type (LONG_TYPE_SIZE); - - t = targetm.build_builtin_va_list (); - - /* Many back-ends define record types without setting TYPE_NAME. - If we copied the record type here, we'd keep the original - record type without a name. This breaks name mangling. So, - don't copy record types and let c_common_nodes_and_builtins() - declare the type to be __builtin_va_list. */ - if (TREE_CODE (t) != RECORD_TYPE) - t = build_variant_type_copy (t); - - va_list_type_node = t; initialize_builtins ();