From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129271 invoked by alias); 10 Oct 2016 10:49:02 -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 129255 invoked by uid 89); 10 Oct 2016 10:49:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 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=outcome, business X-HELO: mail-qk0-f178.google.com Received: from mail-qk0-f178.google.com (HELO mail-qk0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Oct 2016 10:48:51 +0000 Received: by mail-qk0-f178.google.com with SMTP id f128so82995461qkb.1 for ; Mon, 10 Oct 2016 03:48:51 -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=1qk0wvea/FTZqZMDSLPLSvFPklEKRqHoVJvcHF6O/oQ=; b=Hb6tALVzCynkjC4np6zkRFwk/zZ1f4C/y8r4MmVtEEG0Ssi+ZrH+L2bD2FEkScRSes LmfHFMXMKWsaKJkCtWb0a6teUympZ2IKsBZJkiwdrZqMPyEpilVCf2RZj2zrDjg31BOo IuTni/q4JdQeTTgLwO4GExmzJO75gr5hz0wQke7aWkArBFGD+pSDcktY4T/K0/Ta+n32 gYbsf2PVRZSUB3iGMeTWxQAkjmTwe4pKEQyWZu+wj7HqhsdUgBiaLEBqxmwkjPw97js2 MJRdmLcs9v4X2iXe8omKW7MO3lZX6KXnAvfgN3migJqKkWmzylie0jI1TA6cZjG9ux+k MV1A== X-Gm-Message-State: AA6/9RnVCWzvVw/ylb1M+/AyY2ZS4qj9QogHYAfD63d8YyJZpbBpm1/84iMQN2KUtpGRoLUFOYM+WasWsn/eXg== X-Received: by 10.194.82.100 with SMTP id h4mr29165216wjy.183.1476096529990; Mon, 10 Oct 2016 03:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.155.146 with HTTP; Mon, 10 Oct 2016 03:48:48 -0700 (PDT) In-Reply-To: <2004625.PcKOVMIpSq@polaris> References: <1863165.r8qPLI7fxq@polaris> <2004625.PcKOVMIpSq@polaris> From: Richard Biener Date: Mon, 10 Oct 2016 10:49: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/msg00594.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. Yes. But that's not the only source for DECL_UID differences. Btw, I see lots of FOR_EACH_HASH_TABLE_ELEMENT in var-tracking.c but they don't look like their outcome is supposed to be dependent on element ordering. Did you track down where exactly the code-gen difference appeared? >> 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? > > It's certainly old code (r29604, September 1999). > > -- > Eric Botcazou