On Wed, 18 Oct 2017, Janne Grunau wrote:
On 2017-10-16 22:38:19 +0300, Martin Storsjö wrote:
The operand shouldn't be stored as is, but stored as 64-scale, in
the opcode, but armasm64 misses to do this.
This might be a big enough bug to report and try to get fixed, but
that requires removing this workaround at that point.
Please report this as bug.
I've reported it at
https://connect.microsoft.com/VisualStudio/feedback/details/3142655/armasm64-encodes-incorrect-scale-for-fcvtzs-and-scvtf
(seems to require sign-in to see) but apparently they are switching to
some other system so I have to re-report it elsewhere.
I'd propose a environment variable or version check for this fixup.
Yeah, I thought about that. At this point within gas-preprocessor, we
don't really know the version of armasm (and executing it to find out
would be pretty expensive). One possible solution is to enclose the
hook-up of the affected functions in x264 with something like this:
#if !defined(_MSC_FULL_VER) || _MSC_FULL_VER >= FIXED_VERSION
That assumes that the assembler is updated in sync with the compiler,
which I guess is reasonable.
Alternatively we'd use something like the existing GASPP_FIX_XCODE5 env
var, requiring setting GASPP_FIX_ARMASM_FP_SCALE or something such. If the
bug report progress shows that it might not ever be fixed, we could remove
the need for the env variable of course.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
