Re: Strict aliasing problem in gcc 4.4.4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/21/2010 05:24 PM, Andy Gibbs wrote:
> On Wednesday, July 21, 2010 4:55 PM, Andrew Haley wrote:
> 
>> This is going to be hard.  Your library is based on the assumption that
>>
>> struct point
>> {
>> double x, y;
>> };
>>
>> and
>>
>> double pts[2];
>>
>> have exactly the same memory layout, and that there is no padding, and
>> that pointers to them can be aliased.  Your question is more or less
>> equivalent to asking how to disable strict aliasing without
>> -fno-strict-aliasing.  I can't think of any way to solve this other
>> than fixing the code.  There's no legal way that you can cast a
>> pointer to a scalar to a pointer to some struct type.

> 
> Thank you for your response and explanation of the problem.  I think you
> are most likely right: the only (best) way is to fix the code. 
> Unfortunately, this was just one example of many throughout the
> library.  It seems this was a favourite trick in its development!
> 
> I have found that changing ...
> 
>  double pts[8];
>  point* points = (point*)pts;
>  points[0] = function1(points+1, 3);
>  function2(pts, 8);
> 
> ... to ...
> 
>  char pts[8 * sizeof(double)] __attribute__ ((aligned (sizeof(double))));
>  point* points = (point*)pts;
>  points[0] = function1(points+1, 3);
>  function2((double*)pts, 8);
> 
> ... while almost certainly worse than the current situation, does at
> least silence the error in this instance.  I can then run tests on the
> library to demonstrate its correct operation.  This may not be the
> preferred way of dealing with this, but the shear quantity of code that
> may become broken, causes me to hesitate!
> 
> Or, do you think I'm heading for bigger trouble down this route?

Maybe.  A problem may occur in any function that can see both an
array of doubles and an instance of point.  The compiler "knows" that
these can never alias, so is free to re-order code as it sees fit.
So, a write to a memory location X may be moved after that same location
is read.

While this may not happen in anything you can see, inlining will
expose problems like this.  And they're a pig to track down, believe
me.

Andrew.


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux