This has been discovered when analysing the test failures (CppunitTest_sc_addin_functions_test, specifically the DEC2BIN() check) in LibreOffice builds. Which is a huge codebase, thus there is no minimal reproducer (yet). It involves https://git.libreoffice.org/core/+/refs/heads/master/scaddins/source/analysis/analysis.cxx#711 OUString SAL_CALL AnalysisAddIn::getDec2Bin( const uno::Reference< beans::XPropertySet >& xOpt, sal_Int32 nNum, const uno::Any& rPlaces ) { printf("getDec2Bin: nNum=%i\n", nNum); sal_Int32 nPlaces = 0; bool bUsePlaces = aAnyConv.getInt32( nPlaces, xOpt, rPlaces ); return ConvertFromDec( nNum, SCA_MIN2, SCA_MAX2, 2, nPlaces, SCA_MAXPLACES, bUsePlaces ); } and https://git.libreoffice.org/core/+/refs/heads/master/scaddins/source/analysis/analysishelper.cxx#691 OUString ConvertFromDec( double fNum, double fMin, double fMax, sal_uInt16 nBase, sal_Int32 nPlaces, sal_Int32 nMaxPlaces, bool bUsePlaces ) { printf("ConvertFromDec: fNum=%lf fMin=%lf fMax=%lf nBase=%d nPlaces=%d nMaxPlaces=%d nUsePlaces=%c\n", fNum, fMin, fMax, nBase, nPlaces, nMaxPlaces, bUsePlaces ? 'Y' : 'N'); fNum = ::rtl::math::approxFloor( fNum ); fMin = ::rtl::math::approxFloor( fMin ); fMax = ::rtl::math::approxFloor( fMax ); if( fNum < fMin || fNum > fMax || ( bUsePlaces && ( nPlaces <= 0 || nPlaces > nMaxPlaces ) ) ) throw lang::IllegalArgumentException(); sal_Int64 nNum = static_cast< sal_Int64 >( fNum ); printf("ConvertFromDec: nNum=%ld \n", nNum); bool bNeg = nNum < 0; if( bNeg ) nNum = sal_Int64( pow( double( nBase ), double( nMaxPlaces ) ) ) + nNum; OUString aRet(OUString::number(nNum, nBase).toAsciiUpperCase()); if( bUsePlaces ) { sal_Int32 nLen = aRet.getLength(); if( !bNeg && nLen > nPlaces ) { throw lang::IllegalArgumentException(); } else if( ( bNeg && nLen < nMaxPlaces ) || ( !bNeg && nLen < nPlaces ) ) { sal_Int32 nLeft = nPlaces - nLen; std::unique_ptr<char[]> p( new char[ nLeft + 1 ] ); memset( p.get(), bNeg ? GetMaxChar( nBase ) : '0', nLeft ); p[ nLeft ] = 0x00; aRet = OUString( p.get(), nLeft, RTL_TEXTENCODING_MS_1252 ) + aRet; } } return aRet; } The printf()s are mine and the output is following ... getDec2Bin: nNum=9 ConvertFromDec: fNum=9.000000 fMin=-512.000000 fMax=511.000000 nBase=2 nPlaces=4 nMaxPlaces=10 nUsePlaces=Y ConvertFromDec: nNum=9 getDec2Bin: nNum=-100 ConvertFromDec: fNum=4294967196.000000 fMin=-512.000000 fMax=511.000000 nBase=2 nPlaces=0 nMaxPlaces=10 nUsePlaces=N ... As you can see, when nNum is negative, it is not sign-extended (int32->int64) before passed to ConvertFromDec(). Disassembly of getDec2Bin() confirms that (see bellow my gdb session), mtfprd expects a 64-bit value in r6, but only the lower 32 bits are valid. As a result we get 2^32-100 as a positive 64-bit value. ... Continuing. getDec2Bin: nNum=9 ConvertFromDec: fNum=9.000000 fMin=-512.000000 fMax=511.000000 nBase=2 nPlaces=8 nMaxPlaces=10 nUsePlaces=Y ConvertFromDec: nNum=9 Thread 1 "cppunittester" hit Breakpoint 2, 0x00007fffd75c2508 in AnalysisAddIn::getDec2Bin (this=0x11111da0, xOpt=uno::Reference to (ScModelObj *) 0x10f69750, nNum=9, rPlaces=uno::Any("double": 4)) at /home/sharkcz/projects/libreoffice/scaddins/source/analysis/analysis.cxx:713 713 { (gdb) Continuing. getDec2Bin: nNum=9 ConvertFromDec: fNum=9.000000 fMin=-512.000000 fMax=511.000000 nBase=2 nPlaces=4 nMaxPlaces=10 nUsePlaces=Y ConvertFromDec: nNum=9 Thread 1 "cppunittester" hit Breakpoint 2, 0x00007fffd75c2508 in AnalysisAddIn::getDec2Bin (this=0x11111da0, xOpt=uno::Reference to (ScModelObj *) 0x10f69750, nNum=-100, rPlaces=uno::Any(void)) at /home/sharkcz/projects/libreoffice/scaddins/source/analysis/analysis.cxx:713 713 { (gdb) disass Dump of assembler code for function _ZN13AnalysisAddIn10getDec2BinERKN3com3sun4star3uno9ReferenceINS2_5beans12XPropertySetEEEiRKNS3_3AnyE: 0x00007fffd75c2500 <+0>: addis r2,r12,7 0x00007fffd75c2504 <+4>: addi r2,r2,23040 => 0x00007fffd75c2508 <+8>: mflr r0 0x00007fffd75c250c <+12>: stfd f31,-8(r1) 0x00007fffd75c2510 <+16>: std r28,-40(r1) 0x00007fffd75c2514 <+20>: mtfprd f31,r6 0x00007fffd75c2518 <+24>: mr r28,r7 0x00007fffd75c251c <+28>: std r29,-32(r1) 0x00007fffd75c2520 <+32>: std r30,-24(r1) 0x00007fffd75c2524 <+36>: mr r30,r4 0x00007fffd75c2528 <+40>: mr r4,r6 0x00007fffd75c252c <+44>: std r31,-16(r1) 0x00007fffd75c2530 <+48>: mr r31,r3 0x00007fffd75c2534 <+52>: addis r3,r2,-3 0x00007fffd75c2538 <+56>: addi r3,r3,-32512 0x00007fffd75c253c <+60>: mr r29,r5 0x00007fffd75c2540 <+64>: std r0,16(r1) 0x00007fffd75c2544 <+68>: stdu r1,-160(r1) 0x00007fffd75c2548 <+72>: ld r9,-28688(r13) 0x00007fffd75c254c <+76>: std r9,104(r1) 0x00007fffd75c2550 <+80>: li r9,0 0x00007fffd75c2554 <+84>: bl 0x7fffd75c0980 <000000a7.plt_call.__printfieee128@@GLIBC_2.32> 0x00007fffd75c2558 <+88>: ld r2,24(r1) 0x00007fffd75c255c <+92>: li r9,0 0x00007fffd75c2560 <+96>: mr r6,r28 0x00007fffd75c2564 <+100>: mr r5,r29 0x00007fffd75c2568 <+104>: addi r4,r1,100 0x00007fffd75c256c <+108>: stw r9,100(r1) 0x00007fffd75c2570 <+112>: addi r3,r30,192 0x00007fffd75c2574 <+116>: bl 0x7fffd75ea9e8 <_ZN3sca8analysis15ScaAnyConverter8getInt32ERiRKN3com3sun4star3uno9ReferenceINS5_5beans12XPropertySetEEERKNS6_3AnyE+8> 0x00007fffd75c2578 <+120>: nop 0x00007fffd75c257c <+124>: addis r8,r2,-3 0x00007fffd75c2580 <+128>: li r9,10 0x00007fffd75c2584 <+132>: li r7,2 0x00007fffd75c2588 <+136>: fcfid f1,f31 0x00007fffd75c258c <+140>: lfd f3,-23480(r8) 0x00007fffd75c2590 <+144>: addis r8,r2,-3 0x00007fffd75c2594 <+148>: mr r10,r3 0x00007fffd75c2598 <+152>: mr r3,r31 0x00007fffd75c259c <+156>: lfd f2,-23472(r8) 0x00007fffd75c25a0 <+160>: lwa r8,100(r1) 0x00007fffd75c25a4 <+164>: bl 0x7fffd75eac08 <_ZN3sca8analysis14ConvertFromDecEdddtiib+8> 0x00007fffd75c25a8 <+168>: nop 0x00007fffd75c25ac <+172>: ld r10,104(r1) 0x00007fffd75c25b0 <+176>: ld r9,-28688(r13) 0x00007fffd75c25b4 <+180>: xor. r10,r10,r9 0x00007fffd75c25b8 <+184>: li r9,0 0x00007fffd75c25bc <+188>: bne 0x7fffd75c25e8 <_ZN13AnalysisAddIn10getDec2BinERKN3com3sun4star3uno9ReferenceINS2_5beans12XPropertySetEEEiRKNS3_3AnyE+232> 0x00007fffd75c25c0 <+192>: addi r1,r1,160 0x00007fffd75c25c4 <+196>: mr r3,r31 0x00007fffd75c25c8 <+200>: ld r0,16(r1) 0x00007fffd75c25cc <+204>: lfd f31,-8(r1) 0x00007fffd75c25d0 <+208>: ld r28,-40(r1) 0x00007fffd75c25d4 <+212>: ld r29,-32(r1) 0x00007fffd75c25d8 <+216>: ld r30,-24(r1) 0x00007fffd75c25dc <+220>: ld r31,-16(r1) 0x00007fffd75c25e0 <+224>: mtlr r0 0x00007fffd75c25e4 <+228>: blr 0x00007fffd75c25e8 <+232>: bl 0x7fffd75c0220 <000000a7.plt_call.__stack_chk_fail@@GLIBC_2.17> 0x00007fffd75c25ec <+236>: ld r2,24(r1) 0x00007fffd75c25f0 <+240>: .long 0x0 0x00007fffd75c25f4 <+244>: .long 0x1020900 0x00007fffd75c25f8 <+248>: .long 0x481 End of assembler dump. (gdb) n 714 printf("getDec2Bin: nNum=%i\n", nNum); (gdb) getDec2Bin: nNum=-100 715 sal_Int32 nPlaces = 0; (gdb) 716 bool bUsePlaces = aAnyConv.getInt32( nPlaces, xOpt, rPlaces ); (gdb) 717 return ConvertFromDec( nNum, SCA_MIN2, SCA_MAX2, 2, nPlaces, SCA_MAXPLACES, bUsePlaces ); (gdb) info all-registers r0 0x7fffd75c2578 140736806528376 r1 0x7fffffff2940 140737488300352 r2 0x7fffd7637f00 140736807010048 r3 0x0 0 r4 0x7fffffff28f8 140737488300280 r5 0x7fffffff2b20 140737488300832 r6 0x8 8 r7 0x2 2 r8 0x7fffd7607f00 140736806813440 r9 0xa 10 r10 0x0 0 r11 0x4000 16384 r12 0x7ffff7399d80 140737341136256 r13 0x7ffff7ffdea0 140737354129056 r14 0x1011e080 269607040 r15 0x3 3 r16 0x114a2c98 290073752 r17 0x7fffd74c2ed0 140736805482192 r18 0x114a3760 290076512 r19 0x7fffffff31f0 140737488302576 r20 0x7fffffff31d0 140737488302544 r21 0x0 0 r22 0x3 3 r23 0x7fffffff2ef0 140737488301808 r24 0x1114b480 286569600 r25 0x114a2cb0 290073776 r26 0x3 3 r27 0x111223a0 286401440 r28 0x7fffffff2b20 140737488300832 r29 0x7fffffff2b40 140737488300864 r30 0x11111da0 286334368 r31 0x7fffffff2f20 140737488301856 f0 0 (raw 0x0000000000000000) f1 4294967196 (raw 0x41effffff3800000) f2 6.9533558051702119e-310 (raw 0x00007fffffff2d50) f3 511 (raw 0x407ff00000000000) f4 1.4332241230514119e-315 (raw 0x00000000114a6370) f5 6.9533247401022234e-310 (raw 0x00007fffda850008) f6 6.9533489380300625e-310 (raw 0x00007ffff7b65200) f7 6.9533487140708958e-310 (raw 0x00007ffff7712708) f8 -1.5656907205677511e+206 (raw 0xeabf3609f29d4900) f9 6.9533558051749549e-310 (raw 0x00007fffffff2db0) f10 6.9533558050848373e-310 (raw 0x00007fffffff2690) f11 1.3320357634094679e-315 (raw 0x000000001011e080) f12 2147483648 (raw 0x41e0000000000000) f13 1.4158419450246769e-315 (raw 0x000000001114b480) f14 0 (raw 0x0000000000000000) f15 0 (raw 0x0000000000000000) f16 0 (raw 0x0000000000000000) f17 0 (raw 0x0000000000000000) f18 0 (raw 0x0000000000000000) f19 0 (raw 0x0000000000000000) f20 0 (raw 0x0000000000000000) f21 0 (raw 0x0000000000000000) f22 0 (raw 0x0000000000000000) f23 0 (raw 0x0000000000000000) f24 0 (raw 0x0000000000000000) f25 0 (raw 0x0000000000000000) f26 0 (raw 0x0000000000000000) f27 0 (raw 0x0000000000000000) f28 0 (raw 0x0000000000000000) f29 0 (raw 0x0000000000000000) f30 0.067000000000000004 (raw 0x3fb126e978d4fdf4) f31 2.1219957415587077e-314 (raw 0x00000000ffffff9c) pc 0x7fffd75c2598 0x7fffd75c2598 <AnalysisAddIn::getDec2Bin(com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, int, com::sun::star::uno::Any const&)+152> msr 0x900000004000d033 10376293542535417907 cr 0x24444842 608454722 lr 0x7fffd75c2578 0x7fffd75c2578 <AnalysisAddIn::getDec2Bin(com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, int, com::sun::star::uno::Any const&)+120> ctr 0x7ffff7399d80 140737341136256 xer 0x4 4 fpscr 0x82004000 2181054464 For compiler options used, see bellow ... [CXX] scaddins/source/analysis/analysis.cxx S=/home/sharkcz/projects/libreoffice && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/scaddins/source/analysis/ $W/Dep/CxxObject/scaddins/source/analysis/ && cd /home/sharkcz/projects/libreoffice && g++ -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DLINUX -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DPOWERPC64 -DPPC -DUNIX -DUNX -D_PTHREADS -D_REENTRANT -fvisibility=hidden -Wall -Wno-missing-braces -Wendif-labels -Wextra -Wundef -Wunreachable-code -Wshadow -Wunused-macros -finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe -fstack-protector-strong -Wdeprecated-copy-dtor -Wduplicated-cond -Wlogical-op -Wshift-overflow=2 -Wunused-const-variable=1 -Wno-cast-function-type -fvisibility-inlines-hidden -fPIC -Wshadow -Woverloaded-virtual -std=c++17 -pthread -O2 -ggdb2 -fexceptions -fno-enforce-eh-specs -DLIBO_INTERNAL_ONLY -c $S/scaddins/source/analysis/analysis.cxx -o $W/CxxObject/scaddins/source/analysis/analysis.o -MMD -MT $W/CxxObject/scaddins/source/analysis/analysis.o -MP -MF $W/Dep/CxxObject/scaddins/source/analysis/analysis.d_ -I$S/include -I/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.ppc64le/include -I/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.ppc64le/include/linux -I$S/config_host -I$S/scaddins/inc -I/usr/include -I$W/UnoApiHeadersTarget/offapi/comprehensive -I$W/UnoApiHeadersTarget/scaddins/comprehensive -I$W/UnoApiHeadersTarget/udkapi/comprehensive && mv $W/Dep/CxxObject/scaddins/source/analysis/analysis.d_ $W/Dep/CxxObject/scaddins/source/analysis/analysis.d And this is with gcc-13.2.1-1.fc38.ppc64le Reproducible: Always The CppunitTest_sc_addin_functions_test fails also on aarch64 and s390x, so it might not be ppc64le specific issue, but I haven't got to the details on the other platforms yet.
Just a wild guess, the PowerPC64 ELFv2 ABI says that integral arguments shorter than doubleword (aka 64-bit) should be passed sign or zero extended to 64-bit. So, if one has void bar (double); void foo (int a) { bar (a); } which I think roughly matches what getDec2Bin -> ConvertFromDec does, GCC will not perform any sign-extension because the argument is required by the psABI to be already sign-extended and will just use fcfid to convert that to double. Now, if whatever calls foo in this shorter testcase or GetDec2Bin in LibreOffice case actually for whatever reason doesn't sign-extend the argument, then such behavior would be expected. Unfortunately the info regs you've shown doesn't contain any GPR with the -100 value, sign or zero extended nor with garbage in upper bits, only f31 at that point zero extended. Could you print $r4 at the very beginning of GetDec2Bin?
Compare that to x86-64, where the psABI doesn't say anything about the upper 32 bits of int arguments passed in GPRs, so there the compiler has to sign-extend in GetDec2Bin before converting to double.
for the record, this is really ppc64le specific, after rechecking on s390x and aarch64 they both passed the test, although they had a problem with the test in the past
yes, the previous regs were printed before calling ConvertFromDec(), but there is -100 in r6 when entering getDec2Bin() (gdb) Continuing. getDec2Bin: nNum=9 ConvertFromDec: fNum=9.000000 fMin=-512.000000 fMax=511.000000 nBase=2 nPlaces=4 nMaxPlaces=10 nUsePlaces=Y ConvertFromDec: nNum=9 Thread 1 "cppunittester" hit Breakpoint 1, 0x00007fffd75c2508 in AnalysisAddIn::getDec2Bin (this=0x11111bb0, xOpt=uno::Reference to (ScModelObj *) 0x10f69560, nNum=-100, rPlaces=uno::Any(void)) at /home/sharkcz/projects/libreoffice/scaddins/source/analysis/analysis.cxx:713 713 { (gdb) info registers r0 0x7fffffff2d10 140737488301328 r1 0x7fffffff2990 140737488300432 r2 0x7fffd7637f00 140736807010048 r3 0x7fffffff2ed0 140737488301776 r4 0x11111bb0 286333872 r5 0x7fffffff2af0 140737488300784 r6 0xffffff9c 4294967196 r7 0x7fffffff2ad0 140737488300752 r8 0x7fffda887f00 140736859766528 r9 0x7fffffff2d10 140737488301328 r10 0x11118110 286359824 r11 0x7fffd75c2600 140736806528512 r12 0x7fffd75c2600 140736806528512 r13 0x7ffff7ffdea0 140737354129056 r14 0x1011e080 269607040 r15 0x3 3 r16 0x114a69b8 290089400 r17 0x7fffd74c2ed0 140736805482192 r18 0x112b1ea0 288038560 r19 0x7fffffff31a0 140737488302496 r20 0x7fffffff3180 140737488302464 r21 0x0 0 r22 0x3 3 r23 0x7fffffff2ea0 140737488301728 r24 0x1114b290 286569104 r25 0x114a69d0 290089424 r26 0x3 3 r27 0x111221b0 286400944 r28 0x1011da20 269605408 r29 0x7fffffff2e60 140737488301664 r30 0x7fffffff2ad0 140737488300752 r31 0x7fffffff2990 140737488300432 pc 0x7fffd75c2508 0x7fffd75c2508 <AnalysisAddIn::getDec2Bin(com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, int, com::sun::star::uno::Any const&)+8> msr 0x900000000002d033 10376293541461807155 cr 0x88444880 2286176384 lr 0x7fffda848b4c 0x7fffda848b4c <(anonymous namespace)::callVirtualMethod(void*, sal_uInt32, void*, typelib_TypeDescription*, sal_uInt64*, sal_uInt32, sal_uInt64*, sal_uInt32, double*, sal_uInt32)+480> ctr 0x7fffd75c2600 140736806528512 xer 0x4 4 fpscr 0x82000000 2181038080 vscr 0x0 0
And 0xffffff9c is zero-extended -100 rather than sign-extended. So, next question is what are the callers (bt) and why it happened. Could be using incorrect prototype somewhere (with unsigned argument rather than signed, or say 64-bit signed or unsigned), some assembly layer, or gcc bug (or whatever compiled that caller).
If I read the ABI specs (https://files.openpower.foundation/s/cfA2oFPXbbZwEBK) right, then it requires sign/zero extension for parameters passed in memory (parameter save area) and for the return value passed in register. But I will look also further in the LO code.
But there might be an ABI issue in LO itself as well, because they do some "weird" stuff using a "bridge" (gdb) where #0 0x00007fffd75c2508 in AnalysisAddIn::getDec2Bin(com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, int, com::sun::star::uno::Any const&) (this=0x11111bb0, xOpt=uno::Reference to (ScModelObj *) 0x10f69560, nNum=-100, rPlaces=uno::Any(void)) at /home/sharkcz/projects/libreoffice/scaddins/source/analysis/analysis.cxx:713 #1 0x00007fffda848b4c in (anonymous namespace)::callVirtualMethod(void*, sal_uInt32, void*, typelib_TypeDescription*, sal_uInt64*, sal_uInt32, sal_uInt64*, sal_uInt32, double*, sal_uInt32) (pThis=0x11111c10, nVtableIndex=29, pRegisterReturn=0x7fffffff2ed0, pReturnTypeDescr=0x1011dab0, pStack=0x7fffffff2b50, nStack=0, pGPR=0x7fffffff2cb0, nGPR=5, pFPR=0x7fffffff2cf0, nFPR=0) at /home/sharkcz/projects/libreoffice/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx:218 #2 0x00007fffda8496c0 in (anonymous namespace)::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**) (pThis=0x112b1ea0, aVtableSlot=..., pReturnTypeRef=0x1011dab0, nParams=3, pParams=0x11122160, pUnoReturn=0x7fffffff2ed0, pUnoArgs=0x7fffffff2ea0, ppUnoExc=0x7fffffff2f70) at /home/sharkcz/projects/libreoffice/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx:464 #3 0x00007fffda84a250 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) (pUnoI=0x112b1ea0, pMemberDescr=0x11122080, pReturn=0x7fffffff2ed0, pArgs=0x7fffffff2ea0, ppException=0x7fffffff2f70) at /home/sharkcz/projects/libreoffice/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx:638 #4 0x00007fffd74e62b0 in stoc_corefl::(anonymous namespace)::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) (this=0x1114b290, rObj=uno::Any("com.sun.star.sheet.XAddIn": ...), rArgs=<optimized out>) at /home/sharkcz/projects/libreoffice/stoc/source/corereflection/criface.cxx:590 ...
https://git.libreoffice.org/core/+/refs/heads/master/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
So, for ABIs which require sign extension of signed char, signed short, signed int arguments to wordsize, it needs to differentiate between e.g. INSERT_INT32 (which does always zero extend) and something different which will sign extend. typelib_TypeClass_LONG vs. typelib_TypeClass_UNSIGNED_LONG, similarly for SHORT. Dunno whether others are signed or unsigned (e.g. enum could very well be signed in some cases and unsigned in others).
I believe you are right. If I understand it right, then gcc omits the sign/zero-extension step as part of optimizations, because with "-O0" it is present when preparing the args (checked both with the simple test case from comment #1 and with the actual getDec2Bin()). So it's a LibreOffice ABI compliance issue :-)
E.g. look how gcc3_linux_aarch64/uno2cpp.cxx differentiates the sign vs. unsigned cases. typelib_TypeClass_BYTE is treated there as signed, and ENUM as well. Or gcc3_linux_riscv64/uno2cpp.cxx, though there it has INSERT_INT16 vs. INSERT_UINT16 macros but just INSERT_INT32. Or gcc3_linux_mips64 from which probably risv64 copied it; note, no idea about what those ABIs require. One can have a look e.g. at libffi sources...
Sure, the compiler is not required to avoid the extension, it is purely an optimization on the callee side on arches which require sign or zero extension; but it is a requirement on the caller side. On arches which have the upper bits undefined, whether caller extends or not is purely an optimization choice and extension on the callee side is required if the argument is then cast to wider integer type etc.
(In reply to Jakub Jelinek from comment #11) > E.g. look how gcc3_linux_aarch64/uno2cpp.cxx differentiates the sign vs. > unsigned cases. typelib_TypeClass_BYTE is treated there as signed, and ENUM > as well. seems you are just a little step ahead of me, I have just found gcc3_linux_aarch64/uno2cpp.cxx as a possible good example as well :-) > Or gcc3_linux_riscv64/uno2cpp.cxx, though there it has INSERT_INT16 vs. > INSERT_UINT16 macros but just INSERT_INT32. Or gcc3_linux_mips64 from which > probably risv64 > copied it; note, no idea about what those ABIs require. One can have a look > e.g. at libffi sources...
Up to you/LibreOffice upstream, but I think the INSERT_INTNN vs. INSERT_UINTNN differentiation (but you'll need one also for 32 and 8) looks nicer to me for the way this bridge is written. But aarch64 can help understand which case is which.
(In reply to Jakub Jelinek from comment #14) > Up to you/LibreOffice upstream, but I think the INSERT_INTNN vs. > INSERT_UINTNN differentiation (but you'll need one also for 32 and 8) looks > nicer to me for the way this bridge is written. > But aarch64 can help understand which case is which. ack moving the bug to LO from gcc ...
and it should be fixed with https://gerrit.libreoffice.org/c/core/+/156846 https://gerrit.libreoffice.org/c/core/+/156847