From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116142 invoked by alias); 10 Oct 2016 10:45:32 -0000 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 Received: (qmail 116116 invoked by uid 89); 10 Oct 2016 10:45:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=business X-HELO: mail-lf0-f67.google.com Received: from mail-lf0-f67.google.com (HELO mail-lf0-f67.google.com) (209.85.215.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Oct 2016 10:45:19 +0000 Received: by mail-lf0-f67.google.com with SMTP id p80so9311037lfp.1 for ; Mon, 10 Oct 2016 03:45:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mny7eBUk6TUxvudGkIez0n9393ZTO+eUKkI2Zgx0efU=; b=GXrmTttSd/28x984k0t8vv5Bz/30CCueKXpo/XKlI0aycAnP35P+pmOtmMiBXJZr8g 9fkMpolhDp14CdTAV69IL6T+HoFMjUwNFP0eXiP4QKIfI7F3JR0BU1x9GPPWXe1yDTj8 Mh5sgGT4mTh7ShcSVfT9mqMoCPl84NhRmUGOZ45MkFHtr94dODS0wUXu93UP8tw9pCxB EqCTsYrgpPutlAAhv1CIcpoNjZZmivs44H0JR5id6LY7CKLm29zy63XIs05BdVN9m84Z VmU/UsmkivnANnck/RwBY5MIFUnljKhR4pDZvPFBQRc+gBKM17EDwqg4oPljdePxxg7h w1bA== X-Gm-Message-State: AA6/9RkgKpBHjrIEl68xq6XCqDQzcgQ1VmpP7Ei20KdbIwvhzmTQnoj7TJCSZcN+3ddDJMOOiw1RBM16VYJC4Q== X-Received: by 10.194.235.34 with SMTP id uj2mr28263274wjc.144.1476096316051; Mon, 10 Oct 2016 03:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.155.146 with HTTP; Mon, 10 Oct 2016 03:45:14 -0700 (PDT) In-Reply-To: <2004625.PcKOVMIpSq@polaris> References: <1863165.r8qPLI7fxq@polaris> <2004625.PcKOVMIpSq@polaris> From: Richard Biener Date: Mon, 10 Oct 2016 10:45:00 -0000 Message-ID: Subject: Re: [patch] Fix GC issue triggered by arithmetic overflow checking To: Eric Botcazou Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00593.txt.bz2 On Mon, Oct 10, 2016 at 12:38 PM, Eric Botcazou wrote: >> I believe the rule is that you might only depend on the order of objects >> with respect to their DECL_UID, not the actual value of the DECL_UID. >> As var-tracking shouldn't look at TYPE_DECLs (?) it's probably a latent >> var-tracking bug as well. > > It presumably doesn't look at TYPE_DECLs, simply the DECL_UID of variables is > also different so this changes some hashing. > >> I'd prefer the named parameter to be defaulted to false and the few >> places in the FEs fixed (eventually that name business should be >> handled like names for nodes like integer_type_node -- I see no >> reason why build_complex_type should have this special-case at all! >> That is, why are the named vairants in the type hash in the first place?) > > I think that the calls in build_common_tree_nodes need to be changed too then: > > complex_integer_type_node = build_complex_type (integer_type_node); > complex_float_type_node = build_complex_type (float_type_node); > complex_double_type_node = build_complex_type (double_type_node); > complex_long_double_type_node = build_complex_type (long_double_type_node); > > in addition to: > > ./ada/gcc-interface/decl.c: = build_complex_type > ./ada/gcc-interface/decl.c: return build_complex_type (nt); > ./ada/gcc-interface/trans.c: tree gnu_ctype = build_complex_type > (gnu_type); > ./c/c-decl.c: specs->type = build_complex_type (specs->type); > ./c/c-decl.c: specs->type = build_complex_type (specs->type); > ./c/c-decl.c: specs->type = build_complex_type (specs->type); > ./c/c-parser.c: build_complex_type > ./c/c-typeck.c: return build_complex_type (subtype); > ./c-family/c-common.c: return build_complex_type (inner_type); > ./c-family/c-lex.c: type = build_complex_type (type); > ./cp/decl.c: type = build_complex_type (type); > ./cp/typeck.c: return build_type_attribute_variant (build_complex_type > (subtype), > ./fortran/trans-types.c:gfc_build_complex_type (tree scalar_type) > ./fortran/trans-types.c: type = gfc_build_complex_type (type); > ./go/go-gcc.cc: > build_complex_type(TREE_TYPE(real_tree)), > ./go/go-gcc.cc: type = build_complex_type(type); > ./lto/lto-lang.c: return build_complex_type (inner_type); > > Or perhaps *only* the calls in build_common_tree_nodes need to be changed? I think only the calls in build_common_tree_nodes -- those are the ones built early and that survive GC. The patch is ok if it passes testing with that. Richard. > It's certainly old code (r29604, September 1999). > -- > Eric Botcazou