odd internal failure

odd internal failure

[Gary Oblock]

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?

Thanks,

Gary


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.

Re: odd internal failure

[Richard Biener]

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.

Re: odd internal failure

[Gary Oblock]

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. 😱

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.

Re: odd internal failure

[Richard Biener]

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

> 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.

Re: odd internal failure

[David Malcolm]

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.
> 

Re: odd internal failure

[Gary Oblock]

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




________________________________
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.
>

Re: 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.
>>>>