This patch includes all marshalling and proxy handling code on the
.NET side as well as the native side needed for a fully functional
UNO bridge.
It also includes some changes and corrections to net_basetypes and
netmaker needed for the bridge to work properly.
It also includes the FirstUnoContact example in C# as demonstration.
Change-Id: I406932938a4415d24408fb41ddfa7d8eeb5d1f94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170916
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
/uno2cpp.cxx: In function ‘void {anonymous}::callVirtualMethod(void*, sal_Int32, void*, typelib_TypeDescriptionReference*, sal_uInt32*, sal_uInt32, sal_uInt32*, sal_uInt32, double*)’:
/<<PKGBUILDDIR>>/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:278:5: error: ‘asm’ operand has impossible constraints or there are not enough registers
278 | __asm__ __volatile__ (
| ^~~~~~~
make[2]: *** [/<<PKGBUILDDIR>>/solenv/gbuild/LinkTarget.mk:338: /<<PKGBUILDDIR>>/workdir/CxxObject/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.o] Error 1
Just removing them makes it work, they are mentioned before anyway, too
(thanks Caolan)
Change-Id: Ibb9118b268a587ebdcfce343e2ee2605ac979915
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171650
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
...to acknowledge the tools' more general role since
74829f2a64 "Fully implement the Wasm UNO bridge
cpp2uno direction"
Change-Id: Ie89255579774035f7b726d1d4b029dc536893ca0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170382
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...after 875997c896 "Properly implement
cppu::throwException for Emscripten" had implemented only those parts that were
absolutely necessary for that exception throwing. As detailed in the commit
message there, wasmcallgen has been extended to additionally generate all the
required vtable slot call trampoline code (which cannot be generated on the fly
for Wasm, as would be done for other platforms). Consequently, some of the
"callvirtualfunction"-centric file names have been changed to "generated" as the
output of wasmcallgen is now more general. (And wasmcallgen itself should also
be renamed, in a follow-up commit. And when adding to the wasmcallgen code
here, some existing parts of its implementation have been cleaned up, too.)
There is no direct way to test this half of the Wasm UNO bridge directly from
unotest/source/embindtest/embindtest.js, so a new
org.libreoffice.embindtest.BridgeTest singleton has been added, which triggers
new test code in unotest/source/embindtest/embindtest.cxx that tests the bridge
in a way similar to testtools' bridgetest machinery.
Change-Id: I521a1d6c2160aedc814f7603b0b99861e5fbd1eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170374
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...by implementing (for now) just enough of the cpp2uno half of the Wasm UNO
bridge to make it work. In general, that half suffers from the same issue as
the already-implemented uno2cpp half, namely that Wasm doesn't allow to generate
code on the fly (which, in this case, would be needed to implement the vtable
slot trampoline functions). So, for now just hard-code the few
vtableSlotFunction_* that are needed by the UNO interfaces for
cppuhelper/source/exc_thrower.cxx. (A proper fix would probably use the same
approach as for the uno2cpp half, and use something like wasmcallgen to generate
at least all the vtableSlotFunction_* needed for udkapi/offapi upfront.)
The RTTI for the exceptions needs to be unique across the executable for
exception catching to actually work (as it compares exception types by RTTI
address rather than by name). We thus need to export all the relevant RTTI
symbols (which I hacked into the existing wasmcallgen for now, even if that
makes that executable's name a slight misnomer now), and access them with a new
jsGetExportedSymbol. (This exporting would also be needed by the "classical"
approach of using dlsym on the main module, cf.
<https://gerrit.libreoffice.org/c/core/+/167187> "WIP: Emscripten: Set up
support for dlsym from main module". And while that dlsym approach would work,
it is much simpler to just use that jsGetExportedSymbol than to use a dlsym
detour, and thereby avoid all the hassle of -sMAIN_MODULE detailed in the commit
message of that Gerrit change.)
It also turned out that including Emscripten's <cxxabi.h> needs
__USING_WASM_EXCEPTIONS__ to be defined, because it uses that in its declaration
of __cxa_throw. (The source for setting that define internally in Emscripten is
get_cflags in the emsdk's upstream/emscripten/tools/system_libs.py, which
defines __USING_EMSCRIPTEN_EXCEPTIONS__ for the non-Wasm, Emscripten JS
exception mode, and defines __USING_WASM_EXCEPTIONS__ for
--enable-wasm-exceptions, which we use. The commit message of
f4ec967599 "Fix redefinion of Emscripten
__cxxabiv1::__cxa_exception" documents my prior confusion of when one or the
other would be defined.)
Change-Id: Id08765ab5b4ce1553dc3a61648324526185cb64c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170246
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...with a new Module.catchUnoException JS function that can be used in a JS
catch block to provide the thrown UNO exception as an Any. (For a non-C++
exception, it rethrows the exception, and for a non-UNO C++ exception it maps it
to css.uno.RuntimeException.)
The implementation reuses parts of bridges/source/cpp_uno/gcc3_wasm/, which have
been moved to a new StaticLibrary_emscriptencxxabi.
Change-Id: I708fe6121c43a1b9736de5dff449f6c4f32a45f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169325
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
<https://github.com/emscripten-core/emscripten/>
system/lib/libcxxabi/src/cxa_exception.h has two different definitions of that
struct, a short one for when __USING_EMSCRIPTEN_EXCEPTIONS__ is defined, and a
long one for the other case. In 7175431a4b
"Implement exception catching", I had naively copied the short version, assuming
that __USING_EMSCRIPTEN_EXCEPTIONS__ was something that sounded like it would be
defined with --enable-wasm-exceptions. But some debugging of actual exception
handling now showed that the assumption had apparently been wrong (though I
still have no idea about the semantics of that __USING_EMSCRIPTEN_EXCEPTIONS__
define, and when it would or would not be defined), and that I had copied the
wrong version.
The relevant test code
> try {
> const ret = invoke.invoke('throwRuntimeException', params, outparamindex, outparam);
> console.assert(false);
> ret.delete();
> } catch (e) {
> const [type, message] = getExceptionMessage(e);
> console.assert(type === 'com::sun:⭐:reflection::InvocationTargetException');
> console.assert(message === undefined); //TODO
> //TODO: inspect wrapped css.uno.RuntimeException
> decrementExceptionRefcount(e);
> }
in unotest/source/embindtest/embindtest.js had apparently happened to not cause a
crash with the wrong version of __cxxabiv1::__cxa_exception, but had also
happened to not detect the mistake due to the relevant parts being commented out
with TODO (because, in turn, proper UNO exception catching is still lacking in
our Embind-based JS binding).
Change-Id: I718087c7ed2c17808696267ece17237d5cdf2f54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169305
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
There appears to be no good reason that cpp2uno.cxx and uno2cpp.cxx are noopt
(presumably that was just cargo-culted from another platform?), and except.cxx
appears to be completely unused anyway.
Change-Id: Ic5f4142308a56b798dad61e9ec589046cad2ae13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168182
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
(Without 22ce8ed05b "Emscripten: Unconditional
--enable-wasm-exceptions", this would have failed to link due to missing
__cxa_current_exception_type and __cxa_get_globals.)
Change-Id: If89a3c62e4d2ac24d68f867b2fd7a4cd813d5a39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168176
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...so that it can be reused in the future for attribute getters/setters
Change-Id: I3dde796eb0c2f3812b7aee1a2c000bad31b33158
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167345
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...by making the general UNO -> C++ function call case work (modulo handling
exceptions, which I'll look into later).
Wasm call_indirect unfortunately needs to statically know the call target's
signature, so we statically need to know all possible signatures. So introduce
wasmcallgen helper to scan the existing UNOIDL API upfront and generate the
relevant callvirtualfunction-wrapper.cxx and callvirtualfunction-inst.s code.
(The good thing is that the number of different signatures is somewhat limited,
each parameter can only be one of i32, i64, f32, or f64. So even if 3rd-party
extensions bring along new UNOIDL interface methods, chances are relatively high
that the signatures needed for them would already be covered by the existing
ones.)
Testing this can nicely be done in unotest/source/embindtest/embindtest.js via
css.script.Invocation (which internally exercises the relevant code). (Instead
of adding individual org.libreoffice.embindtest.StructLong/String etc., it would
be nicer to introduce some polymorphic StructOne<T>, but the Emind UNO binding
does not support polymorphic structs, so the embindtest.js code would not work.)
Change-Id: If829c9e3772bfd27561f3ad743d38a71d11545b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167308
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...where the function's argument is in x2, not x1 (see commit message of
ae6ee262d7 "Some fixing of msvc_win32_arm64 UNO
bridge" for details)
Change-Id: I00ef5df1ebad4609918c0c6845ebdcfe810f6152
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...that ae6ee262d7 "Some fixing of
msvc_win32_arm64 UNO bridge" had removed, assuming it wasn't actually necessary.
But looks like Windows exception handling stack unwinding somehow needs it after
all. Getting past the CustomTarget_testtools/uno_test getRaiseAttr1() call now
(but still failing at some later place).
Change-Id: I1e84345f2f355ab1e480c779da6b221b744132b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166616
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
For one, the Windows ABI deviates from the generic aarch64 ABI regarding
returning class instances by value from non-static member functions, see
<https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values>:
"The caller shall reserve a block of memory of sufficient size and alignment to
hold the result. The address of the memory block shall be passed as an
additional argument to the function in x0, or x1 if $this is passed in x0. The
callee may modify the result memory block at any point during the execution of
the subroutine. The callee returns the address of the memory block in x0."
That means RETURN_KIND_HFA_FLOAT and RETURN_KIND_HFA_DOUBLE are not needed, and
can be cleaned up in a follow-up commit.
And for another, setting up a call stack frame in call() in uno2cpp.cxx for
callVirtualFunction() didn't actually work, so go with a slightly less ambitious
aproach (as also used by the gcc_linux_aarch64 bridge) and explicitly copy the
arguments that end up on the stack around in callVirtualFunction().
This allows CustomTarget_testtools/uno_test to proceed at least as far as the
call of getRaiseAttr1(), which still leads to an uncaught
css::uno::RuntimeException.
Change-Id: I4a8ec09c270864ac4de246d7e8d1f923198236b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166585
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
since
commit f93ae0455c
Date: Sat Feb 3 18:03:45 2024 +0100
Check bridges with IWYU
presumably not using the _LIBCPPABI_VERSION branch
move the _GLIBCXX_CDTOR_CALLABI fallback define to where
its used while I'm at it, that too seems to be from cxxabi.h
Change-Id: I2ead7207e3bcf24d3b120d22ae7f80e8f0a3216a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163672
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Only the parts tha build on x64 arch
See tdf#42949 for motivation
Change-Id: Ifa3c5107887f5ab7837beee83d9603e8c883a7a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162961
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
* Refactor the code related to struct processing. Fix Java bridge-
test failure. Fixed test list:
* bridgetest-javaserver
* [CUT] smoketest
* [JUT] forms_unoapi_1
* [JUT] forms_unoapi_2
* [JUT] forms_unoapi_3
* [JUT] forms_unoapi_4
* Clean higher bit to prevent compiler generate wrong code when
pyuno calls functions through UNO environment. This fixes some
weired uitest failure.
* Reorder the datatype list. Optimize the inserting args section in
uno2cpp.cxx.
* Remove some unused code.
Change-Id: I74330126d31d847485b1d81fc34376b1d020f886
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160970
Tested-by: Jenkins
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x2e4597d in TreatDoubleError /src/libreoffice/sc/source/core/inc/interpre.hxx:1146:10
#1 0x2e4597d in ScInterpreter::PushDouble(double) /src/libreoffice/sc/source/core/tool/interpr4.cxx:1806:5
#2 0x2e83755 in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3126:17
#3 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43
#4 0x27296ad in ScFormulaCell::InterpretTail(ScInterpreterContext&, ScFormulaCell::ScInterpretTailParameter) /src/libreoffice/sc/source/core/data/formulacell.cxx:1946:23
#5 0x2722f87 in ScFormulaCell::Interpret(int, int) /src/libreoffice/sc/source/core/data/formulacell.cxx:1619:13
#6 0x1e1c80f in operator() /src/libreoffice/sc/source/core/data/column.cxx:2808:16
#7 0x1e1c80f in EachElem<mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell, mdds::mtv::delayed_delete_vector>, std::__1::__wrap_iter<ScFormulaCell **>, mdds::detail::mtv::iterator_value_node<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>, unsigned long>, (anonymous namespace)::CalcAllHandler> /src/libreoffice/sc/inc/mtvfunctions.hxx:130:9
#8 0x1e1c80f in ProcessElements1<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell, mdds::mtv::delayed_delete_vector>, (anonymous namespace)::CalcAllHandler, sc::FuncElseNoOp<unsigned long, bool> > /src/libreoffice/sc/inc/mtvfunctions.hxx:330:9
Uninitialized value was stored to memory at
#0 0x2fdee53 in operator>>=<double> /src/libreoffice/sc/source/core/tool/rangeseq.cxx:0:14
#1 0x2fdee53 in ScApiTypeConversion::ConvertAnyToDouble(double&, com::sun:⭐:uno::TypeClass&, com::sun:⭐:uno::Any const&) /src/libreoffice/sc/source/core/tool/rangeseq.cxx:347:18
#2 0x2b1e9d4 in ScUnoAddInCall::SetResult(com::sun:⭐:uno::Any const&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1583:17
#3 0x2b1d84f in ScUnoAddInCall::ExecuteCallWithArgs(com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1541:9
#4 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9
#5 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19
#6 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43
Uninitialized value was stored to memory at
#0 0x2b1daec in swap<void *> /usr/local/include/c++/v1/__utility/swap.h:37:7
#1 0x2b1daec in operator= /src/libreoffice/include/com/sun/star/uno/Any.hxx:153:5
#2 0x2b1daec in ScUnoAddInCall::ExecuteCallWithArgs(com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1518:14
#3 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9
#4 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19
#5 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43
Uninitialized value was stored to memory at
#0 0xc49bb64 in cppu::_copyConstructAnyFromData(_uno_Any*, void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), _uno_Mapping*) /src/libreoffice/cppu/source/uno/copy.hxx:178:49
#1 0xc497abd in cppu::_copyConstructAny(_uno_Any*, void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), _uno_Mapping*) /src/libreoffice/cppu/source/uno/copy.hxx:288:13
#2 0xc499443 in uno_any_constructAndConvert /src/libreoffice/cppu/source/uno/any.cxx:120:9
#3 0x174d263f in stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun:⭐:uno::Any const&, com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:633:13
#4 0x174d5935 in non-virtual thunk to stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun:⭐:uno::Any const&, com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:0
#5 0x2b1d5ce in ScUnoAddInCall::ExecuteCallWithArgs(com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1518:27
#6 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9
#7 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19
#8 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43
Uninitialized value was stored to memory at
#0 0xcd10714 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:157:51
#1 0xcd0cd78 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233:13
#2 0xcd0a9fa in unoInterfaceProxyDispatch /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:0
#3 0x174d1f01 in stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun:⭐:uno::Any const&, com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:590:9
#4 0x174d5935 in non-virtual thunk to stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun:⭐:uno::Any const&, com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/stoc/source/corereflection/criface.cxx:0
#5 0x2b1d5ce in ScUnoAddInCall::ExecuteCallWithArgs(com::sun:⭐:uno::Sequence<com::sun:⭐:uno::Any>&) /src/libreoffice/sc/source/core/tool/addincol.cxx:1518:27
#6 0x2b1c2ee in ScUnoAddInCall::ExecuteCall() /src/libreoffice/sc/source/core/tool/addincol.cxx:1495:9
#7 0x2e81a4b in ScInterpreter::ScExternal() /src/libreoffice/sc/source/core/tool/interpr4.cxx:3065:19
#8 0x2e94a38 in ScInterpreter::Interpret() /src/libreoffice/sc/source/core/tool/interpr4.cxx:4487:43
Uninitialized value was created by an allocation of 'data' in the stack frame of function '_ZN4gcc317callVirtualMethodEPvjS0_P33_typelib_TypeDescriptionReferencebPmjS3_Pd'
#0 0xcd0f1d0 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) /src/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:50
The double really comes from AnalysisAddIn::getConvert and when adding
code to switch off it there and msan is happy before it returns that it
is initialized, the problem arises when extracting that return value in
the bridge code. Its curious that this only appears now when we've been
running msan for years and only for double (so far) and not the other
types.
Change-Id: I8f381a9faf4fe9d4a02b77b241ab33de8eb3bce2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162348
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
presumably we need the same fix there as done with:
commit 3bcc14b4e2
Author: Stephan Bergmann <sbergman@redhat.com>
Date: Thu Aug 3 13:21:44 2023 +0200
Fix handling of float vs. double values
Change-Id: I7d6420dc954cdc320c9478172878e2a272ab2745
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162193
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
and annotate where necessary, mostly just suppressing the warnings
Change-Id: I8e39d797cde6c7c3f4e3e1bd93a128965ecec81d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159205
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The ABI document for PowerPC64 specifies that integer values shorter than
a doubleword are sign or zero extended as necessary. Until now the smaller
values were treated as unsigned values and only zero-extended. Handling of
signed values was incorrect.
Change-Id: Icbbe8fc8d4facfa6d1b3252c99ec2d8c2552d9f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156847
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Use correct types and also typecasts to avoid compiler warnings.
Change-Id: I3b58ec6a4be54ecd8bc07a7febbaf721eba9b945
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156846
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
