public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@adacore.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [patch] Fix GC issue triggered by arithmetic overflow checking
Date: Mon, 10 Oct 2016 10:38:00 -0000	[thread overview]
Message-ID: <2004625.PcKOVMIpSq@polaris> (raw)
In-Reply-To: <CAFiYyc2ac_zXHz1yqPrzvqrwKYu2_LLropU4RAHxvPpXLmZRMw@mail.gmail.com>

> 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?

It's certainly old code (r29604, September 1999).

-- 
Eric Botcazou

  reply	other threads:[~2016-10-10 10:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-08 18:56 Eric Botcazou
2016-10-10  8:59 ` Richard Biener
2016-10-10 10:38   ` Eric Botcazou [this message]
2016-10-10 10:45     ` Richard Biener
2016-10-11  8:05       ` Eric Botcazou
2016-10-16 18:57         ` Eric Botcazou
2016-10-17  8:40           ` Richard Biener
2016-10-10 10:49     ` Richard Biener
2016-10-13 10:16       ` Eric Botcazou
2016-10-13 10:20         ` Richard Biener
2016-10-13 10:37           ` Jakub Jelinek
2016-10-13 10:59             ` Eric Botcazou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2004625.PcKOVMIpSq@polaris \
    --to=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).