odd internal failure

[Gabriel Ravier]

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 <dmalcolm@redhat.com>
> Sent: Thursday, December 2, 2021 6:04 AM
> 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
>
> [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 <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.
>>>>