On 5/23/19 4:26 PM, Joseph Myers wrote: > On Tue, 21 May 2019, Jeff Law wrote: > >> On 5/20/19 6:56 PM, luoxhu wrote: >>> Ping for GCC-10. >> I thought this was a NAK in its current form. >> >> See Ryan's c#1 in the BZ. > > I don't see that as relevant to this bug report. > > That comment is about the question of how GCC can know whether libc's > printf supports this feature at all (since in principle the warnings are > meant to relate to the features libc actually supports, unless you make a > particular format language explicit by specifying gnu_printf rather than > printf in the format attribute - though in practice it's only for MinGW > that GCC actually knows about a different set of formats supported by > default). That comment suggests a possible answer (testing predefined > macros after the implicit preinclusion of any implicitly preincluded > header; note that the macro in question is now __STDC_IEC_60559_DFP__, in > TS 18661-2 and C2X) - although, while glibc has supported stdc-predef.h > for some time, current libdfp does not provide such a header. > > This bug report is about an issue that, in the case where GCC is accepting > DFP printf formats, the set of such formats accepted is incomplete. A fix > for it should be independent of any fix for the other (harder) issue. (If > there is a printf implementation that does in fact support the same subset > of DFP formats supported by GCC's printf checking, but not the ones that > are the subject of this bug report, that would complicate things.) > So your position is that runtime support isn't a factor in whether or not we issue diagnostics for this stuff?
I guess that makes sense. While we do have some checks for what the runtime& target support, they're geared more type compatibility & promotions. Targets can add additional things via TARGET_FORMAT_TYPES and friends. Jeff
