DFG_OPERATIONs with double arguments generate incorrect code on ARM soft-fp

• Component: JavaScriptCore
• Status: RESOLVED DUPLICATE

[Roman Zhuykov]

I found that on ARMv7 Linux, with -mfloat-abi=softfp, v8-splay.js test crashes (segmentation fault). Also stanford-crypto-aes test from Kraken shows wrong results.

The problem happens when calling DFG_OPERATIONs operationArrayPushDouble, operationPutDoubleByValBeyondArrayBoundsStrict, operationPutDoubleByValBeyondArrayBoundsNonStrict. One of their arguments is double, and all of them receive wrong last argument from DFG assembly. I fixed the setupArgumentsWithExecState function to prepare arguments in a proper way (as expected by AAPCS and GCC).

There are two layout tests in the patch:
array-with-double-dfg-push checks push(double) operations,
array-with-double-dfg-assign checks assignment of double element beyond the array bounds.

[Roman Zhuykov]

Created attachment 202085 [details]
Proposed patch

[Mark Hahnenberg]

Comment on attachment 202085 [details]
Proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=202085&action=review

Sorry, could you rebase? It makes getting context for the review easier.

> Source/JavaScriptCore/dfg/DFGCCallHelpers.h:580
>  #endif // CPU(ARM_HARDFP)

I'm no expert, but is this the #define for ARM_HARDFP? Why are we assuming the softfp ABI inside of this #define?

[Csaba Osztrogonác]

Comment on attachment 202085 [details]
Proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=202085&action=review

>> Source/JavaScriptCore/dfg/DFGCCallHelpers.h:580
>>  #endif // CPU(ARM_HARDFP)
> 
> I'm no expert, but is this the #define for ARM_HARDFP? Why are we assuming the softfp ABI inside of this #define?

This #endif comment is very very misleading, because 
it is the end of the _else_ case of CPU(ARM_HARDFP). 

(Otherwise this file is moved to Source/JavaScriptCore/jit/CCallHelpers.h.)

[Roman Zhuykov]

(In reply to comment #2)
> Sorry, could you rebase? It makes getting context for the review easier.

This bug was already fixed here https://bugs.webkit.org/show_bug.cgi?id=117281

[Csaba Osztrogonác]

*** This bug has been marked as a duplicate of bug 117281 ***