From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by sourceware.org (Postfix) with ESMTPS id 05793389367C for ; Wed, 6 May 2020 10:48:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 05793389367C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=martin.st Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=martin@martin.st Received: from mail7.parnet.fi (mail7.parnet.fi [77.234.108.28]) by mail8.parnet.fi with ESMTP id 046AmgED019480-046AmgEF019480 (version=TLSv1.0 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 6 May 2020 13:48:43 +0300 Received: from foo.martin.st (host-96-177.parnet.fi [77.234.96.177]) by mail7.parnet.fi (8.13.8/8.13.8) with ESMTP id 046AmgTL011868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2020 13:48:42 +0300 Date: Wed, 6 May 2020 13:48:42 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: "mingw-w64-public@lists.sourceforge.net" cc: "gcc-help@gcc.gnu.org" Subject: Re: [Mingw-w64-public] mingw-w64 and __attribute__((format(printf))) issue In-Reply-To: <84f2a94f-0d73-fe05-78c6-bd64c1f8ee76@126.com> Message-ID: References: <84f2a94f-0d73-fe05-78c6-bd64c1f8ee76@126.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 10:48:48 -0000 On Wed, 6 May 2020, Liu Hao wrote: > Due to a recent change in mingw-w64 master [1], libgomp ceases to build: > > ``` > ../../../gcc-git/libgomp/target.c:936:21: error: unknown conversion type > character 'l' in format [-Werror=format=] > 936 | gomp_fatal ("present clause: !acc_is_present (%p, " > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ``` > > > On line 29 of 'libgomp/libgomp.h' from GCC 9 branch I found this declaration > > ``` > extern void gomp_fatal (const char *, ...) > __attribute__ ((noreturn, format (printf, 1, 2))); > ``` > > , which uses the `printf` attribute, but the `PRIu64` macro from > expands to `%llu` because now GCC has `-std=gnu11` by > default, which is only valid with `gnu_printf`. > > AFAICS there are three solutions: > > 1. Revert bfd33f6c0ec5e652cc9911857dd1492ece8d8383 in mingw-w64, or This is generally the risk of this kind of commit - regardless of how right/wrong the status quo is, there's _a lot_ of code that relies on it behaving in a specific way, and changing that will certainly run into minor issues in a lot of places. > 2. Make GCC treat `format(printf)` as `format(gnu_printf)` if C11 or > C++11 is selected, or I'm not very keen on that. The compiler should ideally not assume to much about what the platform headers do in detail, because it limits what we can change. (If we'd make that change in the compiler, and then for another reason end up reverting the commit, we'd have the same issue in reverse.) > 3. Replace `format(printf)` with `format(gnu_printf)` in libgomp source. This also kind of hardcodes too much; libgomp in general can't and shouldn't assume too much about which format kind it uses, unless libgomp itself hardcodes __USE_MINGW_ANSI_STDIO. Also, the whole gnu_printf format is something that only GCC supports, not Clang, but I guess libgomp is rather GCC specific anyway. However we do have a define that should expand to the right thing - just like inttypes.h PRIu64 follows __USE_MINGW_ANSI_STDIO - we have __MINGW_PRINTF_FORMAT. So something like this should work: #ifdef __MINGW32__ #define PRINTF_FORMAT __MINGW_PRINTF_FORMAT #else #define PRINTF_FORMAT printf #endif __attribute__((format(PRINTF_FORMAT))) Not very pretty, but should work without hardcoding any assumptions about which format actually is used. // Martin