Hi Jakub,
Please see comments inline.
And one more point: please remove links to mail threads from sources
(http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html).
Boris
12.12.2018 17:36, Jakub Vaněk пишет:
Hi Erik,
On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote:
Hi Jakub,
I do not understand why you use memcpy in softfloat_arm.cpp.
If type cast is the only reason why don't you use reinterpret_cast?
regards,
Boris
I'm using memcpy there because float32_t is a struct containing a
single uint32_t member. I think that the proper way of doing a byte-
level conversion between different types (type punning) is via memcpy.
Do not you expect performance penalty using type conversion this way?
If I used a casted pointer, this would violate the rule that I can
access a memory location through a pointer of only one type.
-fno-strict-aliasing gcc option is used to disable compiler complains on
this rule:
jdk-jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES +=
-fno-strict-aliasing
Using
union for this seems to be also undefined in C++, as then I would
access the value through a non-active member.
Thanks,
Jakub
On 10.12.2018 23:23, Jakub Vaněk wrote:
Hi Erik,
On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote:
The build changes look ok to me.
I do think --enable-softfloat is redundant as using any of the
other
parameters would imply it to be set, but it's ok to have it
there.
Thanks for the review. The motivation for this was that I was
closely
following how libffi is handled. The enable option was a workaround
for
the detection of softfloat in system paths. I don't think this is
how
the library is going to be used, so I removed this option.
New patch can be found here:
https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch
Regards,
Jakub
/Erik
< raw patch at
https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch
>
