[PATCH] include MEM_REF type in tree dumps (PR 90676)

[Martin Sebor]

I spent a bunch of time the other day trying to understand why
the second of the two assignments below to a char array was
apparently not being done by trunk

   a[0] = 1;
   a[1] = 0;

The optimized GIMPLE dump simply shows:

   MEM[(char *)&a] = 1;

when in the past it showed:

   MEM[(char[2] *)&a2] = 1;

After some debugging I figured out that this is the result of
the store merging pass transforming the two assignments into
one:

   *(short int *)a = 1;

and the MEM_REF dump mentioning only the type of the second
operand and not the type of the access.

To avoid this confusion the attached patch adds to the dump
a cast to the MEM_REF type for accesses whose size is not equal
to the size of the operand (when the sizes are the same no new
cast is prepended).  The effect is that with store merging in
effect, the dump for the above becomes

   MEM[(short int *)(char *)&a] = 1;

This should make both the size and the type of the access clear
and help avoid the confusion.  The output isn't the same as in
earlier releases because because the access really is done via
a short pointer and not as an array of char.

There is more detail in MEM_REF that could be included here but
it seems that the size of the access is essential to interpreting
the dumps.

Tested on x86_64-linux with only minimal testsuite fallout.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-90676.diff
Type: text/x-patch
Size: 8293 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190601/665b8203/attachment.bin>