|
|
We have to decide how the C++ front-end and middle-end are going to deal
with "volatile"; we're seeing ICEs due to a conceptual mismatch.
Here is the minimal test case
struct S {
S(const S&);
};
volatile S* p;
void f() {
*p;
}
The C++ front end correctly preserves "*p" for the middle-end. It does
not, however, create a TARGET_EXPR or any other explicit temporary; it
just does: (INDIRECT_REF (VAR_DECL)). The way the middle end wants to
handle this is to create a temporary variable of the "S" and copy the
data there, as if the user had written:
S temp = *p;
However, the middle-end recognizes that "S" is TREE_ADDRESSABLE (i.e.,
cannot be bit-wise copied) and therefore aborts.
As with other memory model things, the standard is not particularly
clear about what volatile accesses mean, but it does make clear they are
side-effects. Since we try to generate a read when "p" is "volatile int
*", we should also do so when it is "volatile S*", and the copy
constructor should not make any difference. (Note how I neatly
side-step the issue of whether or not the read is required; I'm just
saying that the semantics ought to be consistent.)
In this case, I can't see any reason why the fact there's a copy
constructor ought to cause any problems. I think we should just
generate the raw MODIFY_EXPR to copy the data into the temporary
variable. Nothing will ever look at the copy, and we'll have read the
bytes. The other consistent option would be to change the compiler so
that "*p" was not enough to trigger a load, but that would be a change
in semantics. The third, inconsistent option, would be just to ignore
this kind of volatile access to TREE_ADDRESSABLE type, and require that
users explicitly create a temporary in which to place the variable.
(The C++ front end cannot do that itself because that would result in an
extra copy constructor call, which the standard does not permit.)
So, I'm proposing that we create an unchecked version of create_tmp_var
that just creates the variable, even though its type is TREE_ADDRESSABLE.
Thoughts?
--
Mark Mitchell
CodeSourcery, LLC
mark@xxxxxxxxxxxxxxxx
(916) 791-8304
|
|