From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper Date: Wed, 12 Aug 2020 17:10:34 +0300 Message-ID: <83pn7wneed.fsf@gnu.org> References: <74235afc-7043-1da7-7c71-07f0ca23b9fd@cs.ucla.edu> <83r26mv53z.fsf@gnu.org> <87ft8vbow1.fsf@gnus.org> <87v9hq4ppp.fsf@gnus.org> <83k0y544lf.fsf@gnu.org> <8bf60d70-6b0d-0e07-fef9-9baad9d7749c@cs.ucla.edu> <837du5p17p.fsf@gnu.org> <63d00359-f7cc-5564-ecf0-d374dea979ff@cs.ucla.edu> <83zh71ni7r.fsf@gnu.org> <80399aee-a2ef-5d24-a19e-5ea615190cf9@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21531"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 36597@debbugs.gnu.org, pipcet@gmail.com To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 12 16:11:09 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k5rTB-0005VO-FH for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Aug 2020 16:11:09 +0200 Original-Received: from localhost ([::1]:58206 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k5rTA-0008Eq-Hi for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Aug 2020 10:11:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k5rT4-0008Ee-BK for bug-gnu-emacs@gnu.org; Wed, 12 Aug 2020 10:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33509) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k5rT4-00010Z-19 for bug-gnu-emacs@gnu.org; Wed, 12 Aug 2020 10:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k5rT3-0000AM-SI for bug-gnu-emacs@gnu.org; Wed, 12 Aug 2020 10:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Aug 2020 14:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36597 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 36597-submit@debbugs.gnu.org id=B36597.1597241453620 (code B ref 36597); Wed, 12 Aug 2020 14:11:01 +0000 Original-Received: (at 36597) by debbugs.gnu.org; 12 Aug 2020 14:10:53 +0000 Original-Received: from localhost ([127.0.0.1]:45055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k5rSv-00009w-6l for submit@debbugs.gnu.org; Wed, 12 Aug 2020 10:10:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k5rSs-00009i-Oc for 36597@debbugs.gnu.org; Wed, 12 Aug 2020 10:10:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34507) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k5rSn-0000u1-Fl; Wed, 12 Aug 2020 10:10:45 -0400 Original-Received: from [176.228.60.248] (port=4034 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k5rSm-0004RJ-4N; Wed, 12 Aug 2020 10:10:44 -0400 In-Reply-To: <80399aee-a2ef-5d24-a19e-5ea615190cf9@cs.ucla.edu> (message from Paul Eggert on Tue, 11 Aug 2020 16:43:16 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:184803 Archived-At: > Cc: larsi@gnus.org, pipcet@gmail.com, 36597@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 11 Aug 2020 16:43:16 -0700 > > [1:text/plain Hide] > > On 8/11/20 11:35 AM, Eli Zaretskii wrote: > > It doesn't, because we avoid the Gnulib inttypes module on MinGW. > > In that case perhaps I should revert the change that added the Gnulib inttypes > module, as MS-Windows is the only currently-active platform with PRIdPTR etc. > problems that I've heard of. If that module is in our repository only because of MS-Windows, then it indeed isn't needed. > > I don't understand why it's needed; there's nothing wrong with MinGW's > > inttypes.h header. > > I don't know what the problems with MS-Windows are or were. Perhaps they're > fixed on all development environments we know about. That would suggest > reverting the inttypes change too. I see no problems in MinGW headers with PRIdPTR nor with intptr_t. > Does the attached simplification pacify GCC on MinGW? If so, that could be > combined with reverting the inttypes change. The warnings disappeared because you installed a change that no longer uses the GCC warning options which triggered them. So I'm unsure how you'd like me to test the patch, please elaborate. > Does the following standalone program compile OK with 'gcc -Wall' on MinGW? If > so, why does the same thing not work when compiling Emacs? The error message you > quoted in Bug#36597#67 suggests that PRIdPTR is "d" whereas intptr_t is 'long' > which means the following program should run afoul of MinGW. The problem is not with MinGW's definition of intptr_t: it is typedef'ed as 'int' in 32-bit builds in the MinGW headers. The problem is not with intptr_t, it's with its Gnulib equivalent: pdumper.c:1229:6: warning: format '%d' expects argument of type 'int', but argument 4 has type 'gl_intptr_t' {aka 'long int'} [-Wformat=] It complains about gl_intptr_t, not intptr_t. That's because Gnulib's stdint.h does this: # ifdef _WIN64 typedef long long int gl_intptr_t; typedef unsigned long long int gl_uintptr_t; # else typedef long int gl_intptr_t; typedef unsigned long int gl_uintptr_t; # endif # define intptr_t gl_intptr_t # define uintptr_t gl_uintptr_t I don't understand why it uses 'long int' 32-bit platforms, it looks gratuitous, especially since MinGW itself uses just 'int'. (Another question is why Gnulib thinks it needs to redefine intptr_t, but if the redefinition was correct, this would not be especially important.)