Hi,
I noticed that this patch got forgotten and I think it may be useful to
solve this next stage 1.

> 
> cp_apply_type_quals_to_decl drops 'const' if the type has mutable members.
> Unfortunately TREE_READONLY on the PARM_DECL isn't helpful in the case of an
> invisiref parameter.
> 
> > > But maybe classes with mutable
> > > members are never POD and thus always runtime initialized?
> 
> No.
> 
> > C++ frontend has
> > 
> > /* Nonzero means that this type contains a mutable member.  */
> > #define CLASSTYPE_HAS_MUTABLE(NODE) (LANG_TYPE_CLASS_CHECK 
> > (NODE)->has_mutable)
> > #define TYPE_HAS_MUTABLE_P(NODE) (cp_has_mutable_p (NODE))
> > 
> > but it is not exported to middle-end.
> > 
> > However still this is quite special situation since the object is passed
> > using invisible reference, so I wonder if in this sicuation a copy is
> > constructed so the callee can possibly overwrite the muttable fields?
> 
> The object bound to the invisible reference is usually a copy, mutable
> doesn't make a difference.
If I understand situation right, in the following testcase:

struct foo
{
  mutable int a;
  void bar() const;
  ~foo()
  {
    if (a != 42)
      __builtin_abort ();
  }
};
__attribute__ ((noinline))
void test(const struct foo a)
{
        int b = a.a;
        a.bar();
        if (a.a != b)
          __builtin_printf ("optimize me away");
}

We can not assume that value of a.a was not changed by bar because a is
mutable, but otherwise it is safe to optimize out the final check.
If that is so, I think we want to let middle-end know that a type has
mutable field and use it here, right?

Honza

> 
> Jason
> 

Reply via email to