GNU bug report logs - #36597
27.0.50; rehash hash tables eagerly in pdumper

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> gmail.com>

Date: Thu, 11 Jul 2019 14:07:02 UTC

Severity: normal

Tags: patch

Found in version 27.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: eggert <at> cs.ucla.edu
Cc: larsi <at> gnus.org, 36597 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
Date: Wed, 12 Aug 2020 17:46:17 +0300
> Date: Wed, 12 Aug 2020 17:10:34 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: larsi <at> gnus.org, 36597 <at> debbugs.gnu.org, pipcet <at> gmail.com
> 
> > 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.

Sorry, I wasn't paying attention: the warnings did not disappear.

I've now tried the proposed changes, but they don't affect the code
which is cited in the warning messages.  The offending code is here:

  dump_trace
    (("dump_queue_dequeue basis=%"PRIdDUMP_OFF" fancy=%"PRIdPTR
      " zero=%"PRIdPTR" normal=%"PRIdPTR" strong=%"PRIdPTR" hash=%td\n"),
     basis,
     dump_tailq_length (&dump_queue->fancy_weight_objects),
     dump_tailq_length (&dump_queue->zero_weight_objects),
     dump_tailq_length (&dump_queue->one_weight_normal_objects),
     dump_tailq_length (&dump_queue->one_weight_strong_objects),
     XHASH_TABLE (dump_queue->link_weights)->count);

And it triggers warnings because intptr_t is redefined to be 'long
int', whereas PRIdPTR is "d".  Here are the warnings again:

  pdumper.c: In function 'dump_queue_dequeue':
  pdumper.c:1214:6: warning: format '%d' expects argument of type 'int', but argument 3 has type 'gl_intptr_t' {aka 'long int'} [-Wformat=]
   1214 |     (("dump_queue_dequeue basis=%"PRIdDUMP_OFF" fancy=%"PRIdPTR
	|      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   1215 |       " zero=%"PRIdPTR" normal=%"PRIdPTR" strong=%"PRIdPTR" hash=%td\n"),
	|       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   1216 |      basis,
   1217 |      dump_tailq_length (&dump_queue->fancy_weight_objects),
	|      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	|      |
	|      gl_intptr_t {aka long int}
  pdumper.c:1214:6: warning: format '%d' expects argument of type 'int', but argument 4 has type 'gl_intptr_t' {aka 'long int'} [-Wformat=]
  pdumper.c:1214:6: warning: format '%d' expects argument of type 'int', but argument 5 has type 'gl_intptr_t' {aka 'long int'} [-Wformat=]
  pdumper.c:1214:6: warning: format '%d' expects argument of type 'int', but argument 6 has type 'gl_intptr_t' {aka 'long int'} [-Wformat=]




This bug report was last modified 4 years and 284 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.