From: Richard Biener <richard.guenther@gmail.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch] Fix GC issue triggered by arithmetic overflow checking
Date: Mon, 10 Oct 2016 10:49:00 -0000 [thread overview]
Message-ID: <CAFiYyc2YzPFDOh-Pxmna6xWcrkguQ=1YW+uDSJPRyXHApjG-7Q@mail.gmail.com> (raw)
In-Reply-To: <2004625.PcKOVMIpSq@polaris>
On Mon, Oct 10, 2016 at 12:38 PM, Eric Botcazou <ebotcazou@adacore.com> 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
next prev parent reply other threads:[~2016-10-10 10:49 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
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 [this message]
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='CAFiYyc2YzPFDOh-Pxmna6xWcrkguQ=1YW+uDSJPRyXHApjG-7Q@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
/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).