Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0 0x000000010277d28f <+2116> movaps %xmm0,-0x40(%rbp) The documentation for 'movaps' states: "When the source or destination operand is a memory location, it must be aligned on a 16-byte boundary." The problem is that the address of the global variable loaded into AX is not necessarily aligned; as it isn't in our case, which leads to the crash. Here's is the code; it is loading the address of a global variable into AX, and tries to copy the data member, coming from the following class: MD5::FingerPrint cutDataCheckSum = ::gFloorPlanCutData.GetCutDataCheckSum (); memcpy (elemData->cutDataCheckSum, cutDataCheckSum.data, sizeof (elemData->cutDataCheckSum)); namespace MD5 { class GSROOT_DLL_EXPORT FingerPrint { public: FingerPrint (); virtual ~FingerPrint () {}; FingerPrint (unsigned char fp[16]); void Set (unsigned char fp[16]); virtual GSErrCode Write (GS::OChannel& oc) const; virtual GSErrCode Read (GS::IChannel& ic); virtual GSErrCode GetAsString (char* md5String) const; bool IsEmpty (void) const; void Clear (void); bool operator == (const FingerPrint& rhs) const; bool operator != (const FingerPrint& rhs) const; FingerPrint& operator= (const FingerPrint& source); public: unsigned char data[16]; }; } The type of gFloorPlanCutData is class FloorPlanCutData: public GS::Object, public GS::StateEventSource { DECLARE_CLASS_INFO private: double currCutLevel; double topCutLevel; double bottomCutLevel; short topCutBaseStoryRelativeIndex; short bottomCutBaseStoryRelativeIndex; double fixLevel2Absolute0; Int32 lock; // temporary data dependent from the current story double currCutLevelCalculated; double topCutLevelCalculated; double currentStoryLevel; double topBase2Current; double bottomBase2Current; short currentFloorIndex; bool relativeCalculated; MD5::FingerPrint cutDataCheckSum; ... } The optimization kicks in because 'data' is 16-bytes; but there's no alignment check… This seems to be a code generation error, but I couldn't reproduce it in a small application. Is this a known bug, or shall I adjust my build settings? Thanks, Ákos Somorjai Developer Support Manager GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai at graphisoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111020/3d388ea1/attachment.html>
This is http://llvm.org/pr10514 Unfortunately the fix did not make it into that version of clang. On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote:> Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) > > 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> > 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0 > 0x000000010277d28f <+2116> movaps %xmm0,-0x40(%rbp) > > > The documentation for 'movaps' states: "When the source or destination operand is a memory location, it must be aligned on a 16-byte boundary." The problem is that the address of the global variable loaded into AX is not necessarily aligned; as it isn't in our case, which leads to the crash. > > Here's is the code; it is loading the address of a global variable into AX, and tries to copy the data member, coming from the following class: > > MD5::FingerPrint > cutDataCheckSum = ::gFloorPlanCutData.GetCutDataCheckSum (); > memcpy (elemData->cutDataCheckSum, cutDataCheckSum.data, sizeof (elemData->cutDataCheckSum)); > > > namespace MD5 { > class GSROOT_DLL_EXPORT FingerPrint { > public: > FingerPrint (); > virtual ~FingerPrint () {}; > FingerPrint (unsigned char fp[16]); > > void Set (unsigned char fp[16]); > virtual > GSErrCode Write (GS::OChannel& oc) const; > virtual > GSErrCode Read (GS::IChannel& ic); > virtual > GSErrCode GetAsString (char* md5String) const; > bool > IsEmpty (void) const; > void > Clear (void); > bool operator == (const FingerPrint& > rhs) const; > bool operator != (const FingerPrint& > rhs) const; > FingerPrint& > operator= (const FingerPrint& source); > public: > unsigned char data[16]; > }; > } > > The type of gFloorPlanCutData is > > class FloorPlanCutData: public GS::Object, > public GS::StateEventSource { > > DECLARE_CLASS_INFO > > private: > double currCutLevel; > double topCutLevel; > double bottomCutLevel; > short topCutBaseStoryRelativeIndex; > short bottomCutBaseStoryRelativeIndex; > > double fixLevel2Absolute0; > > Int32 > lock; > > // temporary data dependent from the current story > double > currCutLevelCalculated; > double > topCutLevelCalculated; > double currentStoryLevel; > double topBase2Current; > double bottomBase2Current; > short currentFloorIndex; > bool > relativeCalculated; > MD5::FingerPrint > cutDataCheckSum; > > ... > } > > The optimization kicks in because 'data' is 16-bytes; but there's no alignment check… > > This seems to be a code generation error, but I couldn't reproduce it in a small application. Is this a known bug, or shall I adjust my build settings? > > Thanks, > > Ákos Somorjai > Developer Support Manager > > GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai at graphisoft.com > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111020/1467115b/attachment.html>
On Thu, Oct 20, 2011 at 8:46 AM, Bob Wilson <bob.wilson at apple.com> wrote:> This is http://llvm.org/pr10514 > Unfortunately the fix did not make it into that version of clang. > On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote:> The optimization kicks in because 'data' is 16-bytes; but there's no > alignment check… > This seems to be a code generation error, but I couldn't reproduce it in a > small application. Is this a known bug, or shall I adjust my build settings?Does Xcode 4.2 allow you to adjust the build settings for individual source files? I would check in 4.1myself but I've got a long job running in Ubuntu. -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com
Thanks, Bob! I guess we should be expecting a 4.2.1 update after clang 3.0 has been released, shouldn't we? Best, Akos From: Bob Wilson <bob.wilson at apple.com<mailto:bob.wilson at apple.com>> Date: Thu, 20 Oct 2011 08:46:38 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> Subject: Re: [LLVMdev] Crash with optimization for size This is http://llvm.org/pr10514 Unfortunately the fix did not make it into that version of clang. On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote: Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0 0x000000010277d28f <+2116> movaps %xmm0,-0x40(%rbp) The documentation for 'movaps' states: "When the source or destination operand is a memory location, it must be aligned on a 16-byte boundary." The problem is that the address of the global variable loaded into AX is not necessarily aligned; as it isn't in our case, which leads to the crash. Here's is the code; it is loading the address of a global variable into AX, and tries to copy the data member, coming from the following class: MD5::FingerPrintcutDataCheckSum = ::gFloorPlanCutData.GetCutDataCheckSum (); memcpy (elemData->cutDataCheckSum, cutDataCheckSum.data, sizeof (elemData->cutDataCheckSum)); namespace MD5 { class GSROOT_DLL_EXPORT FingerPrint { public: FingerPrint (); virtual ~FingerPrint () {}; FingerPrint (unsignedchar fp[16]); void Set (unsignedchar fp[16]); virtualGSErrCode Write (GS::OChannel& oc) const; virtualGSErrCode Read (GS::IChannel& ic); virtualGSErrCode GetAsString (char* md5String) const; boolIsEmpty (void) const; voidClear (void); bool operator == (const FingerPrint&rhs) const; bool operator != (const FingerPrint&rhs) const; FingerPrint&operator= (const FingerPrint& source); public: unsignedchar data[16]; }; } The type of gFloorPlanCutData is class FloorPlanCutData: public GS::Object, public GS::StateEventSource { DECLARE_CLASS_INFO private: double currCutLevel; double topCutLevel; double bottomCutLevel; short topCutBaseStoryRelativeIndex; short bottomCutBaseStoryRelativeIndex; double fixLevel2Absolute0; Int32lock; // temporary data dependent from the current story doublecurrCutLevelCalculated; doubletopCutLevelCalculated; double currentStoryLevel; double topBase2Current; double bottomBase2Current; short currentFloorIndex; boolrelativeCalculated; MD5::FingerPrintcutDataCheckSum; ... } The optimization kicks in because 'data' is 16-bytes; but there's no alignment check… This seems to be a code generation error, but I couldn't reproduce it in a small application. Is this a known bug, or shall I adjust my build settings? Thanks, Ákos Somorjai Developer Support Manager GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1 437-3000 | asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com> _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111021/61d34246/attachment.html>