public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>,
	Gary Oblock <gary@amperecomputing.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: odd internal failure
Date: Thu, 02 Dec 2021 09:04:10 -0500	[thread overview]
Message-ID: <332033ff89dcde61932adacd4d509cded5728bd2.camel@redhat.com> (raw)
In-Reply-To: <CAFiYyc0qQ4dRxBNYieyGaJ-0Vcsx-FAV8KVufK6wQVPBSU2a3w@mail.gmail.com>

On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote:
> On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock <gary@amperecomputing.com>
> wrote:
> > 
> > Richard,
> > 
> > I rebuilt at "-O0" and that particular call now works but on a call
> > to
> > the same function with a different offset it fails. 😱
> 
> use a debugger to see why

In case you haven't seen them, I put together some tips on debugging
GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
https://github.com/davidmalcolm/gcc-newbies-guide/blob/master/debugging.rst

Inserting print statements only gets you so far; at some point you
really need a debugger.

Dave

> 
> > Thanks,
> > 
> > Gary
> > 
> > 
> > ________________________________
> > From: Richard Biener <richard.guenther@gmail.com>
> > Sent: Wednesday, December 1, 2021 1:09 AM
> > To: Gary Oblock <gary@amperecomputing.com>
> > Cc: gcc@gcc.gnu.org <gcc@gcc.gnu.org>
> > Subject: Re: odd internal failure
> > 
> > [EXTERNAL EMAIL NOTICE: This email originated from an external
> > sender. Please be mindful of safe email handling and proprietary
> > information protection practices.]
> > 
> > 
> > On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc <gcc@gcc.gnu.org>
> > wrote:
> > > 
> > > What is happening should be trivial to determine but for some
> > > reason it's
> > > not. I'd normally bounce this off a coworker but given the pandemic
> > > and modern dispersed hiring practices it's not even remotely
> > > possible.
> > > 
> > > I'm making this call and tree_to_uhwi is failing on an internal
> > > error.
> > > That's normally easy to fix, but here is where the weirdness kicks
> > > in.
> > > 
> > >   unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);
> > > 
> > > tree_to_uhwi from tree.h is:
> > > 
> > > extern inline __attribute__ ((__gnu_inline__)) unsigned
> > > HOST_WIDE_INT
> > > tree_to_uhwi (const_tree t)
> > > {
> > >   gcc_assert (tree_fits_uhwi_p (t));
> > >   return TREE_INT_CST_LOW (t);
> > > }
> > > 
> > > and
> > > 
> > > tree_fits_uhwi_p from tree.c is
> > > 
> > > bool
> > > tree_fits_uhwi_p (const_tree t)
> > > {
> > >   return (t != NULL_TREE
> > >  && TREE_CODE (t) == INTEGER_CST
> > >  && wi::fits_uhwi_p (wi::to_widest (t)));
> > > }
> > > 
> > > Here's what this instrumentation shows (DEBUG_A is an indenting
> > > fprintf to
> > > stderr.)
> > > 
> > >   DEBUG_A ("TREE_CODE(offset) = %s  && ", code_str (TREE_CODE
> > > (offset)));
> > >   DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ?
> > > "true" : "false");
> > >   DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p
> > > (offset) ? "true" : "false");
> > > 
> > >            TREE_CODE(offset) = INTEGER_CST  && fits true
> > >            tree_fits_uhwi_p(offset) true
> > > 
> > > By the way, offset is:
> > > 
> > > _Literal (struct BASKET * *) 8
> > > 
> > > And it's an operand of:
> > > 
> > > MEM[(struct BASKET * *)&perm + 8B]
> > > 
> > > Any clues on what's going on here?
> > 
> > it should just work.
> > 
> > > Thanks,
> > > 
> > > Gary
> > > 
> > 
> > Btw, try to setup things so you don't spam below stuff to public
> > mailing lists.
> > 
> > > CONFIDENTIALITY NOTICE: This e-mail message, including any
> > > attachments, is for the sole use of the intended recipient(s) and
> > > contains information that is confidential and proprietary to Ampere
> > > Computing or its subsidiaries. It is to be used solely for the
> > > purpose of furthering the parties' business relationship. Any
> > > unauthorized review, copying, or distribution of this email (or any
> > > attachments thereto) is strictly prohibited. If you are not the
> > > intended recipient, please contact the sender immediately and
> > > permanently delete the original and any copies of this email and
> > > any attachments thereto.
> 



  reply	other threads:[~2021-12-02 14:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01  7:44 Gary Oblock
2021-12-01  9:09 ` Richard Biener
2021-12-01 20:56   ` Gary Oblock
2021-12-02 11:40     ` Richard Biener
2021-12-02 14:04       ` David Malcolm [this message]
2021-12-03 23:54         ` Gary Oblock
2021-12-04  0:10           ` Gabriel Ravier

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=332033ff89dcde61932adacd4d509cded5728bd2.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gary@amperecomputing.com \
    --cc=gcc@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).