[cfe-commits] [PATCH] struct{bool} -> int function argument coercion emits an invalid store on ARM

Evgeniy Stepanov eugeni.stepanov at gmail.com
Wed Feb 8 01:38:25 PST 2012


Please review.

This change is blocking ASan for Chrome/Android.

On Tue, Feb 7, 2012 at 10:17 AM, Evgeniy Stepanov
<eugeni.stepanov at gmail.com> wrote:
> ping
>
> On Sun, Feb 5, 2012 at 8:08 PM, Evgeniy Stepanov
> <eugeni.stepanov at gmail.com> wrote:
>> Please consider the new patch.
>> This time, if the coerce-to type is larger than the real type, we
>> reconstruct a value of the coerce-to type in a stack allocation, then
>> bitcast & copy it into the destination.
>> This is roughly the same logic as in CreateCoercedStore, but with
>> multiple sources.
>>
>> On Sat, Feb 4, 2012 at 6:12 PM, Evgeniy Stepanov
>> <eugeni.stepanov at gmail.com> wrote:
>>> On Sat, Feb 4, 2012 at 1:07 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>> On Fri, Feb 3, 2012 at 4:05 AM, Evgeniy Stepanov
>>>> <eugeni.stepanov at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> this is a fix for PR11905.
>>>>>
>>>>> The current behaviour when generation a function prolog for arguments
>>>>> of coerced types is to allocate a stack temp of the real argument type
>>>>> and store the argument(s) there. This is wrong, because storage size
>>>>> of the coerce-to type can be larger than that of the real type.
>>>>>
>>>>> The new behaviour is to allocate a temp of the coerced type, copy it,
>>>>> and then reference through a bitcasted pointer of the real type.
>>>>>
>>>>> Please review.
>>>>
>>>> The real type is sometimes larger than the coerced type... switching
>>>> from one to the other only changes which cases are broken issues.
>>>
>>> Could you give an example of that?
>>> In that case, what would you think of allocating the largest of the two types?
>>>
>>>>
>>>> -Eli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arg.patch
Type: text/x-patch
Size: 3576 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120208/51ef607d/attachment.bin>


More information about the cfe-commits mailing list