[LLVMdev] Crash with optimization for size

[Jim Grosbach]

Apple release schedules and LLVM release schedules are completely unrelated.

-Jim

On Oct 21, 2011, at 12:30 AM, Somorjai, Akos wrote:

> 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>
> Date: Thu, 20 Oct 2011 08:46:38 -0700
> To: Ákos Somorjai <asomorjai at graphisoft.com>
> Cc: "llvmdev at cs.uiuc.edu" <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
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> 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/20111021/4d4652f3/attachment.html>