C++ Decimal Floating Point Erroneous Rounding - c++

Question

I am seeing some strange behavior when attempting to use libdfp in a C++ program. Specifically, it appears as if GCC is always rounding to 8 decimal places, even when I use the 64- and 128-bit decimal types.
To test this, I created an incredibly simple test program:
std::decimal::decimal64 testval = 0.044575289999999997DD;
printf("Decimal float test: expected=0.044575289999999997, actual=%.16Da\n", testval);
Which outputs:
Decimal float test: expected=0.044575289999999997, actual=0.04457529000000000
I am fairly certain that this is not a printing problem in libdfp as I was able to trace the source and found that the number is already rounded by the first line of the printf handler. Additionally, the printf handler will also round, however I have verified that this code is not being called.
For reference, I am building libdfp with:
./configure --with-backend=libdecnumber --enable-decimal-float=bid && make
I suspect the problem to either be in the underlying decimal float representation (BID, in my case) or the raw types being provided by GCC. It almost looks as if everything is being rounded to the size of a 32-bit decimal float. My host arch is x86_64 so this should all be supported natively. Furthermore, GCC does have the corresponding _Decimal[32|64|128] types and <decimal/decimal> can be found on the system. I am building on Fedora 25 for a native x86_64 CPU (Intel Xenon). AFAIK, this processor does not have native decimal float support so everything is being rendered in software.
The only clue I have is that GCC does not list the --enable-decimal-float build option in the configuration summary:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC)
$ g++ --version
g++ (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
That being said, my compiler does define the _Decimal[32|64|128] types and provides operator<< overloads for them. I wouldn't expect these to be available at all if such support were not enabled. I certainly shouldn't be able to compile a program using them and get almost valid output back.
Finally, I could see this being a problem with libdecnumber but I am just about at the limit of my current knowledge as to who manages assignment to these types.
Has anybody seen this issue before? Failing that, has anybody build and successfully used libdfp on a similar setup? Which piece of software controls rounding for the internal representation (as opposed to rounding for display)?
EDIT
I finally managed to get a disassembly. It appears that the full value is being loaded into rdx and the decimal64 constructor called. The value 0x2fafd619589efa00 works out to 3436200445056317952 in decimal, which I suspect is 0.044575289999999997 represented in BID format. I am not sure how GCC knows to used BID vs DPD as this is specified at libfdp build time, however I will leave that particular mystery for another post.
If my understanding is correct, it seems to imply that GCC is doing the rounding. Is there anything that can be done about this other than rebuilding the compiler (which I would really like to avoid)? I know IEEE-754 provides mechanisms to 'tune' the behavior of fp operations (including rounding mode), does GCC expose any of this to the user?
Disassembly
│0x401180 <main(int, char**)> push rbp │
│0x401181 <main(int, char**)+1> mov rbp,rsp │
│0x401184 <main(int, char**)+4> sub rsp,0x30 │
│0x401188 <main(int, char**)+8> mov DWORD PTR [rbp-0x14],edi │
│0x40118b <main(int, char**)+11> mov QWORD PTR [rbp-0x20],rsi │
b+ │0x40118f <main(int, char**)+15> movabs rdx,0x2fafd619589efa00 │
│0x401199 <main(int, char**)+25> lea rax,[rbp-0x10] │
│0x40119d <main(int, char**)+29> mov QWORD PTR [rbp-0x28],rdx │
│0x4011a1 <main(int, char**)+33> movq xmm0,QWORD PTR [rbp-0x28] │
│0x4011a6 <main(int, char**)+38> mov rdi,rax │
│0x4011a9 <main(int, char**)+41> call 0x4012e6 <std::decimal::decimal64::decimal64(decimal64)> │
│0x4011ae <main(int, char**)+46> mov rax,QWORD PTR [rbp-0x10] │
│0x4011b2 <main(int, char**)+50> mov QWORD PTR [rbp-0x28],rax │
│0x4011b6 <main(int, char**)+54> movq xmm0,QWORD PTR [rbp-0x28] │
│0x4011bb <main(int, char**)+59> mov edi,0x4018e8 │
│0x4011c0 <main(int, char**)+64> mov eax,0x1 │
│0x4011c5 <main(int, char**)+69> call 0x400a30 <printf#plt> │
│0x4011ca <main(int, char**)+74> mov eax,0x0 │
│0x4011cf <main(int, char**)+79> leave │
│0x4011d0 <main(int, char**)+80> ret │
│0x4011d1 <__static_initialization_and_destruction_0(int, int)> push rbp │
│0x4011d2 <__static_initialization_and_destruction_0(int, int)+1> mov rbp,rsp │
│0x4011d5 <__static_initialization_and_destruction_0(int, int)+4>────────sub rsp,0x10───────────────────────────────────────────────────────────│
│0x4011d9 <__static_initialization_and_destruction_0(int, int)+8> mov DWORD PTR [rbp-0x4],edi │
│0x4011dc <__static_initialization_and_destruction_0(int, int)+11> mov DWORD PTR [rbp-0x8],esi │
│0x4011df <__static_initialization_and_destruction_0(int, int)+14> cmp DWORD PTR [rbp-0x4],0x1 │
│0x4011e3 <__static_initialization_and_destruction_0(int, int)+18> jne 0x40120c <__static_initialization_and_destruction_0(int, int)+59> │
│0x4011e5 <__static_initialization_and_destruction_0(int, int)+20> cmp DWORD PTR [rbp-0x8],0xffff │
│0x4011ec <__static_initialization_and_destruction_0(int, int)+27> jne 0x40120c <__static_initialization_and_destruction_0(int, int)+59> │
│0x4011e5 <__static_initialization_and_destruction_0(int, int)+20> cmp DWORD PTR [rbp-0x8],0xffff │
│0x4011ec <__static_initialization_and_destruction_0(int, int)+27> jne 0x40120c <__static_initialization_and_destruction_0(int, int)+59> │
│0x4011ee <__static_initialization_and_destruction_0(int, int)+29> mov edi,0x60309d │
│0x4011f3 <__static_initialization_and_destruction_0(int, int)+34> call 0x400ae0 <_ZNSt8ios_base4InitC1Ev#plt> │
│0x4011f8 <__static_initialization_and_destruction_0(int, int)+39> mov edx,0x4018d8 │
│0x4011fd <__static_initialization_and_destruction_0(int, int)+44> mov esi,0x60309d │
│0x401202 <__static_initialization_and_destruction_0(int, int)+49> mov edi,0x400aa0 │
│0x401207 <__static_initialization_and_destruction_0(int, int)+54> call 0x400ac0 <__cxa_atexit#plt> │
Complete Test Source
#include <float.h>
#include <decimal/decimal>
#include <math.h>
#include <fenv.h>
#include <stdlib.h>
#include <wchar.h>
#include <cstdlib>
int main (int argc, char *argv[])
{
std::decimal::decimal64 testval = 0.044575289999999997DD;
printf("Decimal float test: expected=0.044575289999999997, actual=%.16Da\n", testval);
return EXIT_SUCCESS;
}