Re: odd internal failure

[Gabriel Ravier via Gcc]

On 12/4/21 00:54, Gary Oblock via Gcc wrote:
David,
Thanks, I've bookmarked your advice. I do use gdb but I've always
found the macros in common use are the biggest hurdle. In addition
C++ has its own associated difficulties.

Note, in the past working on other compilers I've always tried to have
a function version of the macros available.

#if USE_FUNCTIONS
foo_t
MUMBLE( grumble_t *g)
{
   return FU( BAR(g));
}
#else
MUMBLE(g) FU(BAR(g))
#endif

There are many advantages to this. Some are, better type checking,
being able to step into them and invoke them in gdb "p MUMBLE(x)".

Thanks again,

Gary
Shouldn't it be possible to use `-ggdb3` when compiling GCC to get debug 
information that includes macros ? It seems like that'd avoid having to 
manually define a bunch of equivalent functions for the sole purpose of 
being able to step through them.

________________________________
From: David Malcolm <dmalc...@redhat.com>
Sent: Thursday, December 2, 2021 6:04 AM
To: Richard Biener <richard.guent...@gmail.com>; Gary Oblock 
<g...@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 Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote:
On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock <g...@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.guent...@gmail.com>
Sent: Wednesday, December 1, 2021 1:09 AM
To: Gary Oblock <g...@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.