On 1/14/21 12:43 AM, Richard Biener wrote:
On Wed, 13 Jan 2021, Jakub Jelinek wrote:
Hi!
The following patch doesn't actually fix the print_mem_ref bugs, I've kept
it for now as broken as it was, but at least improves the cases where
we can unambiguously map back MEM[&something + off] into som
On Thu, 14 Jan 2021, Jakub Jelinek wrote:
> On Thu, Jan 14, 2021 at 11:05:40AM +0100, Richard Biener wrote:
> > > > Could we print
> > > > t.u.b
> > > > if the TBAA type is compatible with the type of the reference and
> > > > perhaps
> > > > *(int*)&t.u.b
> > > > if it is incompatible?
> > > > >
On Thu, Jan 14, 2021 at 11:05:40AM +0100, Richard Biener wrote:
> > > Could we print
> > > t.u.b
> > > if the TBAA type is compatible with the type of the reference and perhaps
> > > *(int*)&t.u.b
> > > if it is incompatible?
> > > >From the aliasing perspective that is still different, but we don'
On Thu, 14 Jan 2021, Jakub Jelinek wrote:
> On Thu, Jan 14, 2021 at 09:28:31AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > I'm afraid yes, because it is not a toplevel routine, but something called
> > from the c-family pretty-printers, so it can be in the middle of arbitrary
> > C/C++ express
On Thu, Jan 14, 2021 at 09:28:31AM +0100, Jakub Jelinek via Gcc-patches wrote:
> I'm afraid yes, because it is not a toplevel routine, but something called
> from the c-family pretty-printers, so it can be in the middle of arbitrary
> C/C++ expressions. And printing
> (3 * (access to a memory obje
On Thu, Jan 14, 2021 at 08:43:54AM +0100, Richard Biener wrote:
> > But for
> > diagnostics that is what the user actually want to see IMHO.
> > So on the attached testcase, instead of printing what is in left column
> > it prints what is in right column:
> > ((int*)t) + 3 t.u.b
> >
On Wed, 13 Jan 2021, Jakub Jelinek wrote:
> Hi!
>
> The following patch doesn't actually fix the print_mem_ref bugs, I've kept
> it for now as broken as it was, but at least improves the cases where
> we can unambiguously map back MEM[&something + off] into some particular
> reference (e.g. somet
Hi!
The following patch doesn't actually fix the print_mem_ref bugs, I've kept
it for now as broken as it was, but at least improves the cases where
we can unambiguously map back MEM[&something + off] into some particular
reference (e.g. something.foo[1].bar etc.).
In the distant past I think we w
