Bug 49563 - Expansion forgets to set MEM_VOLATILE_P for TARGET_MEM_REF
Summary: Expansion forgets to set MEM_VOLATILE_P for TARGET_MEM_REF
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 09:05 UTC by Duncan Sands
Modified: 2021-09-12 08:41 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan Sands 2011-06-28 09:05:53 UTC 
In expr.c, this code

        if (TREE_THIS_VOLATILE (exp))
          MEM_VOLATILE_P (temp) = 1;

sets MEM_VOLATILE_P for a volatile MEM_REF.  But this is not done for a volatile
TARGET_MEM_REF.  This doesn't matter right now because tree-ssa-loop-ivopts.c
bails out if it sees a volatile memory reference, so volatile TARGET_MEM_REFs
don't (yet) occur in the wild.
Comment 1 Richard Biener 2011-06-28 09:18:30 UTC 
It looks like set_mem_attributes () will set it via a similar check.
Comment 2 Andrew Pinski 2021-09-12 08:41:03 UTC 
    case TARGET_MEM_REF:
      {
        addr_space_t as
          = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0))));
        unsigned int align;

        op0 = addr_for_mem_ref (exp, as, true);
        op0 = memory_address_addr_space (mode, op0, as);
        temp = gen_rtx_MEM (mode, op0);
        set_mem_attributes (temp, exp, 0);

.....
void
set_mem_attributes_minus_bitpos (rtx ref, tree t, int objectp,
                                 poly_int64 bitpos)
{
...
  /* If T is not a type, we may be able to deduce some more information about
     the expression.  */
  if (! TYPE_P (t))
    {
      tree base;

      if (TREE_THIS_VOLATILE (t))
        MEM_VOLATILE_P (ref) = 1;
----- CUT ----
The code in set_mem_attributes has been there since Oct 2001 (r0-37666, 3.1.0)


The code to call set_mem_attributes has not changed since Aug 2010, r0-102267 (when TMR_ORIGINAL was removed and instead of calling set_mem_attributes on TMR_ORIGINAL, it is called on the TMR itself).

So GCC is doing the correct thing for TARGET_MEM_REF as Richard Biener reported in comment #1.