[Mesa-dev] [PATCH v2] glsls: Modify exec_list to avoid strict-aliasing violations

[Davin McCall]

On 26/06/15 12:55, Erik Faye-Lund wrote:
> On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall <davmac at davmac.org> wrote:
>> On 26/06/15 12:03, Davin McCall wrote:
>>> ... The stored value of 'n' is not accessed by any other type than the
>>> type of n itself. This value is then cast to a different pointer type. You
>>> are mistaken if you think that the cast accesses the stored value of n. The
>>> other "stored value" access that it occurs in that expression is to the
>>> object pointed at by the result of the cast. [...]:
>>
>> I'm sorry, I think that was phrased somewhat abrasively, which I did not
>> intend. Let me try this part again. If we by break up the expression in
>> order of evaluation:
>>
>> From:
>>     return ((const struct exec_node **)n)[0]
>>
>> In order of evaluation:
>>
>> n
>> - which accesses the stored value of n, i.e. a value of type 'struct exec
>> node *', via n, which is obviously of that type.
>>
>> (const struct exec_node **)n
>>   - which casts that value, after it has been retrieved, to another type. If
>> this were an aliasing violation, then casting any pointer variable to
>> another type would be an aliasing violation; this is clearly not the case.
>>
>> ((const struct exec_node **)n)[0]
>> - which de-references the result of the above cast, thereby accessing a
>> stored value of type 'exec node *' using a glvalue of type 'exec node *'.
> I think breaking this up is a mistake, because the strict-aliasing
> rules is explicitly about the *combination* of these two things.

It is not a mistake, and the strict aliasing rules are not about the 
combination of these two things. As I have pointed out, with your 
reading, pretty much any pointer cast constitutes an aliasing violation.

The strict aliasing rules specify what kind of reference you can use to 
access an object of a particular type. They say nothing about how that 
reference is obtained.

> You *are* accessing the underlying memory of 'n' through a different
> type, and this is what strict aliasing is all about. But it takes two
> steps, a single step isn't enough to do so.

I'm sorry, but your understanding is incorrect. Most pointer casts would 
be illegal otherwise. And in fact most casts would be illegal. For instance:

    int a;
    long b = (long) a;


You reasoning says that the second line is a strict-aliasing violation, 
because it access the object in 'a' which is of type 'int' via a glvalue 
of type 'long'.

> Those other spec-quotes doesn't undo the strict-aliasing definitions;
> knowing how things are laid out in memory doesn't mean the compiler
> cannot assume two differently typed variables doesn't overlap.

The point of the quotes was to show that casting the 'struct exec_node 
*' to a 'struct exec_node **' does yield a pointer which points to the 
first member of the 'struct exec_node' that the original pointer pointed 
at (if indeed there it did point at one). It was not in regards to the 
aliasing issue.

Davin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150626/1f2fe5bf/attachment-0001.html>