_Region_Get and strict aliasing

[Sergei Organov]

"accounts" <accounts at sakuraindustries.com> writes:
> Hi Sergei,
>
> Have you actually looked at the code I pointed out?

No, I obviously didn't, and I even wrote that I didn't, though maybe in
my answer to your other post.

> Also I think you miss a fundamental point about the strict aliasing
> rules.  It is all about locality of scope.

Really? Care to point me to the wording in the standard (I only have a
copy of draft handy) where it talks about locality of scope
w.r.t. aliasing rules? The only place where I see scopes and aliasing
issues described together is in the description of restricted
pointers, but it's rather different issue we don't currently discuss.

> (somewhat loosely described in the example on page 60, ln 17 "would
> only have come about if the address of a were SOMEWHERE cast to
> double*")

The example there, that you apparently refer to, is:

int a;
void f( double *b )
{
  a = 1;
  *b = 2.0;
  g(a);
}

In this example, compiler is indeed free to optimize g(a) to g(1). Why?
Because if somebody calls f() so that 'b' actually points to 'a', he
made f() to violate aliasing rules, as in this case 'a' of type 'int'
will be accessed using pointer of type 'double*' that is not allowed
according to aliasing rules.

It only means that according to the aliasing rules, it's unsafe to call
a function with type-converted argument as presumably the function will
access the object, the address of which you passed, as lvalue of the
type declared in the arguments list of the function. In this particular
example, it's unsafe to call f((double*)&a). And this has nothing to do
with scoping.

This example shows why GCC has troubles in providing reliable warnings
on aliasing violation. To make reliable warnings, all the code of entire
program should be analyzed.

> Just because at some dark distant point in time in another
> section of code a pointer to a Objects_Control structure used to
> actually be a pointer to a Region_Control structure, the compiler is
> not required to consider that, further it can not be guaranteed that
> it is or was, the compiler must assume it is an (in this case)
> "Objects_Control*".

I don't care what compiler must assume. It's a business of compiler
writers to figure that out. I, as language user, care about not
violating the rules. The aliasing rules are pretty simple and
self-explanatory, why don't read them instead?:

  An object shall have its stored value accessed only by an lvalue
  expression that has one of the following types:

  - a type compatible with the effective type of the object
  [... a few more allowed types skipped ...]


So once again, the rules apply when one accesses an object, and one
should access the object through a pointer of compatible type. Period.
All intermediate conversions of pointers just don't matter, and no
"scoping" issues are involved.

> The C99 rationale calls it a "dubious possibility" (pg 60, ln 20).
> The compiler only needs to consider what is plain before it, in the
> current piece of code it is translating.

Exactly. In the example above you referred to, the compiler sees "double
*b" pointer and "int a" variable, and due to the aliasing rules, it can
safely assume that "a" just can't be changed through "*b" as "b" can't
alias "a". No any "scoping" business here.

> It is this whole locality of scope issue that shows how really broken
> this rule is,

You are still reading the rationale. Please read the aliasing rules in
the standard themselves. There is no single word about scoping there.

> you can safely pointer convert through functions returning punned
> pointers, if you can guarantee that the compiler won't inline them.

No. According to the standard, you can't violate aliasing rules no
matter what.

Relying on the fact that current GCC is not clever enough to optimize
between non-inlined functions and doesn't perform inter-compilation-unit
optimizations is not a good thing, IMHO.

> If it does inline them, well your results may vary.

If I don't violate aliasing rules, the results won't vary. If I do
violate the aliasing rules, then anything could happen.

-- Sergei.