Re^2: Inline::C producing an absurd result

syphilis, I see the same problem with strawberry perl 5.24.1 for MSWin32-x64 with gcc 4.9.2, so I added a function in the c to dump the bytes (I didn't want the bytes leaving the c-environment, just in case trying to follow BrowserUK's unpack advice introduced a translation error (as he said, "might change things"):

//////////////////////////////////////////////////////////////////////
+//////////////////////////////////////////////////////////
// https://perlmonks.org/?node_id=1189780
//////////////////////////////////////////////////////////////////////
+//////////////////////////////////////////////////////////
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void _dump64(char* varname, _Decimal64 d64) {
    int i;
    void*   ptr = (void*)(&d64);
    printf("%s = 0x", varname);
    for(i=0; i < sizeof(d64); i++) {
        printf("%02X ", 0xFF & *(char*)(ptr+i));
    }
    printf("\n");
}
#define dump64(v) _dump64(#v, v)

int foo(void) {
    _Decimal64 pz64 =  0.DD, nz64 = 0.DD, no64 = -1.DD;
    nz64 = pz64 * no64;
    dump64(pz64);
    dump64(nz64);
    dump64(no64);
    if(nz64 !=  0.DD) printf("!= +0\n"); else printf("== +0\n");
    if(nz64 != -0.DD) printf("!= -0\n"); else printf("== -0\n");
    return 0;
}

int main(int argc, char* argv) {
    foo();
}

-----------------------------------------
pz64 = 0x00 00 00 00 00 00 C0 31
nz64 = 0x00 00 00 00 00 00 C0 B1
no64 = 0x01 00 00 00 00 00 C0 B1
== +0
== -0
[download]

When I converted that to perl, and run using Inline::C 0.76, I get

pz64 = 0x00 00 00 00 00 00 C0 31
nz64 = 0x00 00 00 00 00 00 C0 B1
no64 = 0x01 00 00 00 00 00 C0 B1
!= +0
== -0
[download]

That's definitely a strange one: inside C, the bits are the same, but the comparison-behavior is different.

I see a lot of compiler options during the make- and make-install stages, and I'm wondering if one of them is messing up (intentionally modifying?) gcc behavior. What I would probably do next (if it were a problem I had to solve -- or if I had more time to spend on it today for my own education, but unfortunately, $work beckons for now): start making your pure-c compile look more like the Inline::C compile, adding more of the options, until such time as the pure-c failed...

  Starting "make" Stage
Running Mkbootstrap for pm1189780_pl_3d28 ()
"C:\usr\local\apps\strawberry\perl\bin\perl.exe" -MExtUtils::Command -
+e chmod -- 644 "pm1189780_pl_3d28.bs"
"C:\usr\local\apps\strawberry\perl\bin\perl.exe" -MExtUtils::Command::
+MM -e cp_nonempty -- pm1189780_pl_3d28.bs blib\arch\auto\pm1189780_pl
+_3d28\pm1189780_pl_3d28.bs 644
"C:\usr\local\apps\strawberry\perl\bin\perl.exe" "C:\usr\local\apps\st
+rawberry\perl\lib\ExtUtils\xsubpp"  -typemap "C:\usr\local\apps\straw
+berry\perl\lib\ExtUtils\typemap"  pm1189780_pl_3d28.xs > pm1189780_pl
+_3d28.xsc
"C:\usr\local\apps\strawberry\perl\bin\perl.exe" -MExtUtils::Command -
+e mv -- pm1189780_pl_3d28.xsc pm1189780_pl_3d28.c
gcc -c  -I"C:/usr/local/share/passthru/perl/perlmonks"  -s -O2 -DWIN32
+ -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTE
+XT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-aliasing -mms-bitfields -s
+ -O2     -DVERSION=\"0.00\"    -DXS_VERSION=\"0.00\"  "-IC:\usr\local
+\apps\strawberry\perl\lib\CORE"   pm1189780_pl_3d28.c
"C:\usr\local\apps\strawberry\perl\bin\perl.exe" -MExtUtils::Mksymlist
+s \
     -e "Mksymlists('NAME'=>\"pm1189780_pl_3d28\", 'DLBASE' => 'pm1189
+780_pl_3d28', 'DL_FUNCS' => {  }, 'FUNCLIST' => [], 'IMPORTS' => {  }
+, 'DL_VARS' => []);"
g++.exe pm1189780_pl_3d28.def -o blib\arch\auto\pm1189780_pl_3d28\pm11
+89780_pl_3d28.xs.dll -mdll -s -L"C:\usr\local\apps\strawberry\perl\li
+b\CORE" -L"C:\usr\local\apps\strawberry\c\lib" pm1189780_pl_3d28.o   
+"C:\usr\local\apps\strawberry\perl\lib\CORE\libperl524.a" -lmoldname 
+-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell3
+2 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversi
+on -lodbc32 -lodbccp32 -lcomctl32 -Wl,--enable-auto-image-base
"C:\usr\local\apps\strawberry\perl\bin\perl.exe" -MExtUtils::Command -
+e chmod -- 755 blib\arch\auto\pm1189780_pl_3d28\pm1189780_pl_3d28.xs.
+dll
  Finished "make" Stage

  Starting "make install" Stage
"C:\usr\local\apps\strawberry\perl\bin\perl.exe" -MExtUtils::Command::
+MM -e cp_nonempty -- pm1189780_pl_3d28.bs blib\arch\auto\pm1189780_pl
+_3d28\pm1189780_pl_3d28.bs 644
Files found in blib\arch: installing files in blib\lib into architectu
+re dependent library tree
Installing C:\usr\local\share\passthru\perl\perlmonks\_Inline\lib\auto
+\pm1189780_pl_3d28\pm1189780_pl_3d28.xs.dll
  Finished "make install" Stage
[download]

Let us know if you find anything more...

Comment on Re^2: Inline::C producing an absurd result Select or Download Code

Replies are listed 'Best First'.
Re^3: Inline::C producing an absurd result by syphilis (Archbishop) on May 09, 2017 at 02:46 UTC
I see a lot of compiler options during the make- and make-install stages, and I'm wondering if one of them is messing up (intentionally modifying?) gcc behaviour Yes, as Anonymous Monk has subsequently confirmed, that's precisely what's happening (in the form of the optimization option). Cheers, Rob	[reply]