On 3/30/25 6:12 PM, Jan Hubicka wrote:
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 situation a copy is
constructed so the callee can possibly overwrite the mutable 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?
Ah, yes, that makes sense.
Jason
