public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
Date: Tue, 20 Oct 2020 06:23:27 +0000	[thread overview]
Message-ID: <bug-97360-4-VFLYsrglrv@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97360-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #30)
> On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> >
> > --- Comment #28 from Peter Bergner <bergner at gcc dot gnu.org> ---
> > (In reply to Andrew Macleod from comment #25)
> >> Wonder if it was suppose to be something like:
> >>
> >>
> >>     /* Vector pair and vector quad support.  */
> >>     if (TARGET_EXTRA_BUILTINS)
> >>       {
> >> -      tree oi_uns_type = make_unsigned_type (256);
> >> -      vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> >> +      vector_pair_type_node = make_unsigned_type (256);
> >>         SET_TYPE_MODE (vector_pair_type_node, POImode);
> >>         layout_type (vector_pair_type_node);
> >>         lang_hooks.types.register_builtin_type (vector_pair_type_node,
> >>                                                "__vector_pair");
> >>   
> >> -      tree xi_uns_type = make_unsigned_type (512);
> >> -      vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> >> +      vector_quad_type_node = make_unsigned_type (512);
> >>         SET_TYPE_MODE (vector_quad_type_node, PXImode);
> >>         layout_type (vector_quad_type_node);
> >>         lang_hooks.types.register_builtin_type (vector_quad_type_node,
> > So this passed bootstrap and regtesting with no regressions.
> >
> > Is this really the correct fix?

Yes.

> >  Don't we want a distinct type compared to the
> > unsigned type returned from make_unsigned_type()?

But make_unsigned_type already returns a distinct type.  It's a low-level
worker unless for example make_nonstandard_integer_type which caches types.

> I actually dont know, Richi might have to comment on that.. Nothing was 
> referring to the original unsigned_type that was created?  Its just 
> orphaned?
> 
> tree
> make_unsigned_type (int precision)
> {
>    tree type = make_node (INTEGER_TYPE);
> 
>    TYPE_PRECISION (type) = precision;
> 
>    fixup_unsigned_type (type);
>    return type;
> }
> 
> 
> All it does is create a new node, then fixup goes and creates the MIN 
> and MAX fields and sets a few other little things.     The only reason 
> we saw the old unsigned type is we were picking it up from the MAX and 
> MIN fields,... which  were set to the original type.
> 
> it sure *seems* like that is a resonable fix.  Its not like that first 
> node is creating a system wide node?
> 
> our type system is a bit, umm, flakey,  but it seems reasonable to me.   
> :-)  And its in the spirit of what his patch was doing...
> 
> What could possibly go wrong? :-) :-)

Nothing.

> Andrew

  parent reply	other threads:[~2020-10-20  6:23 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-10  3:08 [Bug tree-optimization/97360] New: " amodra at gmail dot com
2020-10-11 22:07 ` [Bug tree-optimization/97360] " msebor at gcc dot gnu.org
2020-10-12  6:23 ` [Bug tree-optimization/97360] [11 Regression] " rguenth at gcc dot gnu.org
2020-10-12  7:42 ` marxin at gcc dot gnu.org
2020-10-12  8:02 ` amodra at gmail dot com
2020-10-12  8:06 ` amodra at gmail dot com
2020-10-12  8:23 ` marxin at gcc dot gnu.org
2020-10-12  9:28 ` aldyh at gcc dot gnu.org
2020-10-12 23:42 ` amodra at gmail dot com
2020-10-15  6:50 ` amodra at gmail dot com
2020-10-15  8:51 ` marxin at gcc dot gnu.org
2020-10-15 12:14 ` amodra at gmail dot com
2020-10-15 14:09 ` amacleod at redhat dot com
2020-10-16 12:17 ` rguenth at gcc dot gnu.org
2020-10-16 13:38 ` amacleod at redhat dot com
2020-10-16 13:48 ` rguenth at gcc dot gnu.org
2020-10-16 13:55 ` amacleod at redhat dot com
2020-10-16 13:58 ` rguenther at suse dot de
2020-10-16 14:17 ` amacleod at redhat dot com
2020-10-16 15:02 ` rguenther at suse dot de
2020-10-16 15:46 ` amacleod at redhat dot com
2020-10-16 16:55 ` rguenther at suse dot de
2020-10-16 17:00 ` amacleod at redhat dot com
2020-10-19  6:08 ` rguenth at gcc dot gnu.org
2020-10-19 13:29 ` bergner at gcc dot gnu.org
2020-10-19 18:45 ` bergner at gcc dot gnu.org
2020-10-19 19:47 ` amacleod at redhat dot com
2020-10-19 20:50 ` bergner at gcc dot gnu.org
2020-10-19 21:21 ` bergner at gcc dot gnu.org
2020-10-19 22:40 ` bergner at gcc dot gnu.org
2020-10-19 23:11 ` cvs-commit at gcc dot gnu.org
2020-10-19 23:28 ` amacleod at redhat dot com
2020-10-20  6:23 ` rguenth at gcc dot gnu.org [this message]
2020-10-20 14:16 ` bergner at gcc dot gnu.org
2020-10-20 14:41 ` rguenther at suse dot de
2020-10-20 16:03 ` bergner at gcc dot gnu.org
2020-10-20 20:27 ` segher at gcc dot gnu.org
2020-10-21 19:30 ` cvs-commit at gcc dot gnu.org
2020-10-21 19:34 ` bergner at gcc dot gnu.org
2020-11-07 22:32 ` cvs-commit at gcc dot gnu.org
2020-11-07 22:36 ` bergner at gcc dot gnu.org

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=bug-97360-4-VFLYsrglrv@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).