urpose. It simply shows that GCC evolved over
its lifetime ;)
Richard.
> Thanks,
>
> Gary
>
>
>
> From: Richard Biener
> Sent: Monday, January 3, 2022 11:28 PM
> To: Gary Oblock
> Cc: gcc@gcc.gnu.org
> Subject: Re: Why do thes
k
Cc: gcc@gcc.gnu.org
Subject: Re: Why do these two trees print differently
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Mon, Jan 3, 2022 at 9:16 PM Gary Oblock wrote:
&
gnoring qualifiers. */
> && (TYPE_MAIN_VARIANT (TREE_TYPE (node))
> == TYPE_MAIN_VARIANT
> (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1)
> && (!(flags & TDF_ALIAS)
> || MR_DEPENDENCE_CLIQUE (node) == 0))
>
>
_
From: Richard Biener
Sent: Monday, January 3, 2022 5:49 AM
To: Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: Why do these two trees print differently
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information
On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc wrote:
>
> This is one of those things that has always puzzled
> me so I thought I break down and finally ask.
>
> There are two ways a memory reference (tree) prints:
>
> MEM[(struct arc_t *)_684].flow
>
> and
>
> _684->flow
>
> Poking under the
This is one of those things that has always puzzled
me so I thought I break down and finally ask.
There are two ways a memory reference (tree) prints:
MEM[(struct arc_t *)_684].flow
and
_684->flow
Poking under the hood of them, the tree codes and
operands are identical so what am I missing?
T
