[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

jasmin at revisionfx dot com gcc-bugzilla@gcc.gnu.org
Mon Aug 9 01:56:00 GMT 2010



------- Comment #78 from jasmin at revisionfx dot com  2010-08-09 01:56 -------

I am not exactly sure how to report a bug here - but it seems highly related to
this thread (I am pierre@revisionfx.com, since I am not sure if I am
auto-subscribed to this thread, and so will get email back about this)

It appears (whatever the version) that this construct in 32b linux (below) does
not work after -shared (ld...) - does not work means is not aligned anymore to
16 bytes/128 bits boundary. If I compile a library with such code, and link it
as in an executable, it seems to work but if I do it as shared object the
alignment is not guaranteed anymore. Anyone has an idea about what to do, if
this will be addressed... or GNU just assumes 32b will go away? Or the problem
is different.  All this works fine with Mac OSX gcc -m32 compile by the way.

Also, if I compile with Intel CC does that fix the problem for an host that is
Intel CC compiled? (As in is it possible that mixed compiler context - host
versus dynamic library further cause complications).

#define MAX_CONV_KERNEL_SIZE                    4096
class ConvKernel4f  
{
        public:

                ConvKernel4f ( );
                ~ConvKernel4f( );
                DATA_ALIGN(float4       mFilterPtr[MAX_CONV_KERNEL_SIZE]);

};


-- 

jasmin at revisionfx dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jasmin at revisionfx dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838



More information about the Gcc-bugs mailing list