With: #define __STDC_WANT_DEC_FP__ #include <stdio.h> int main (void) { double d = 0.1; _Decimal64 e = 0.1dd; printf ("%.20f\n", d); printf ("%Da\n", e); printf ("%De\n", e); printf ("%Df\n", e); printf ("%Dg\n", e); return 0; } $ gcc-snapshot -Wall tst.c tst.c: In function 'main': tst.c:9:3: warning: use of 'D' length modifier with 'a' type character while WG14/N1312 says: D Specifies that a following a, A, e, E, f, F, g, or G conversion specifier applies to a _Decimal64 argument.
This also warns with %Ha (_Decimal32) and %DDa (_Decimal128). I suspect that the correct way to deal with this is for the compiler to disable this warning (or enable this combination) when __STDC_DEC_FP__ is set, where __STDC_DEC_FP__ indicates BOTH the compiler and library conform to the DFP TR. Currently this define is unavailable due to the inability of the compiler to programmatically determine availability of libdfp at compile time. There is a proposed GLIBC/GCC patch to provide a facility to allow this introduced in the following email: http://sourceware.org/ml/libc-alpha/2009-04/msg00005.html
Confirmed, although for me it also prints an additional error about my target lacking support for decimal floating point: $ /usr/local/bin/gcc -Wall -c 43673.c 43673.c: In function ‘main’: 43673.c:7:2: error: decimal floating point not supported for this target _Decimal64 e = 0.1dd; ^~~~~~~~~~ 43673.c:9:13: warning: use of ‘D’ length modifier with ‘a’ type character has either no effect or undefined behavior [-Wformat=] printf ("%Da\n", e); ^
Hi
Hi, Joseph, recently, I summited a quick fix in https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01949.html for this issue. Actually this was introduced by the initial patch https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00330.html committed in 2005. All the decimal floating pointer print function are supported except the Da/DA even it has no much difference with De/Df/Dg/DE/DF/DG, all the value are filled with TEX_* instead of BADLEN for decimal printf table. From consistent view, this patch can fix the issue more easily. But there are questions like Ryan said, the dfp full support requires MACRO __STDC_DEC_FP__ set in DFP library and compiler check, still this mechanism is not implemented yet. Otherwise, it maybe fail on other platforms that don't support DFP. Also, this implementation may need a lot changes to the c front end and libdfp support. What's your suggestion about this? Thanks.
Ben's reply regarding to testing dfp on other targets: " > I suggest to test it on a platform where dfp is not supported as well, At this stage, the patches on the trunk don't identify any targets as supporting DFP, so powerpc64 is as good as any other. I will double check on x86, though, for good measure. Thanks, "
On Tue, 12 Mar 2019, luoxhu at cn dot ibm.com wrote: > Actually this was introduced by the initial patch > https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00330.html committed in 2005. All That means this is not a regression, and trunk is currently in regression-fixes mode in preparation for GCC 9 branching. So I suggest resubmitting / pinging the patch after the GCC 9 branch is created, likely next month.
Author: law Date: Fri May 31 18:46:02 2019 New Revision: 271820 URL: https://gcc.gnu.org/viewcvs?rev=271820&root=gcc&view=rev Log: PR c/43673 * c-format.c (print_char_table, scanf_char_table): Replace BADLEN with TEX_D32, TEX_D64 or TEX_D128. PR c/43673 * gcc.dg/format-dfp-printf-1.c: New test. * gcc.dg/format-dfp-scanf-1.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-format.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/format/dfp-printf-1.c trunk/gcc/testsuite/gcc.dg/format/dfp-scanf-1.c
Fixed on the trunk.