unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Robert Pluim <rpluim@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Correct byte compiler error/warning positions.  The solution!
Date: Mon, 29 Nov 2021 19:16:26 +0000	[thread overview]
Message-ID: <YaUnCn+mFLym5GAP@ACM> (raw)
In-Reply-To: <87v90b5c2o.fsf@gmail.com>

Hello, Robert.

On Mon, Nov 29, 2021 at 14:24:47 +0100, Robert Pluim wrote:
> >>>>> On Mon, 29 Nov 2021 11:50:19 +0000, Alan Mackenzie <acm@muc.de> said:
>     Alan> Anyhow, I've committed the current state in the new branch
>     Alan> scratch/correct-warning-pos.  It should build and run OK, although I
>     Alan> haven't tried it out with native compilation, yet.  It is marginally
>     Alan> slower than master.  Maybe we can merge it into master some time for
>     Alan> Emacs 29.

> "Thou shalt listen to Eli's warnings about '==', else your branch
> shall not compile"

:-)

> ./configure --enable-check-lisp-object-type --enable-checking

> make[1]: Entering directory '/home/rpluim/repos/emacs-pos/src'
>   CC       dispnew.o
> In file included from dispnew.c:27:
> lisp.h: In function ‘EQ’:
> lisp.h:385:40: error: invalid operands to binary == (have ‘Lisp_Object’ and ‘Lisp_Object’)
>   385 |         ? (XSYMBOL_WITH_POS((x)))->sym == (y)          \
>       |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~
>       |                                  |
>       |                                  Lisp_Object
> lisp.h:1329:10: note: in expansion of macro ‘lisp_h_EQ’
>  1329 |   return lisp_h_EQ (x, y);
>       |          ^~~~~~~~~
> lisp.h:388:15: error: invalid operands to binary == (have ‘Lisp_Object’ and ‘Lisp_Object’)
>   387 |           && ((XSYMBOL_WITH_POS((x)))->sym                   \
>       |               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                      |
>       |                                      Lisp_Object
>   388 |               == (XSYMBOL_WITH_POS((y)))->sym)               \
>       |               ^~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                         |
>       |                                         Lisp_Object
> lisp.h:1329:10: note: in expansion of macro ‘lisp_h_EQ’
>  1329 |   return lisp_h_EQ (x, y);
>       |          ^~~~~~~~~
> lisp.h:391:18: error: invalid operands to binary == (have ‘Lisp_Object’ and ‘Lisp_Object’)
>   391 |          && ((x) == ((XSYMBOL_WITH_POS ((y)))->sym))))))
>       |                  ^~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                              |
>       |                                              Lisp_Object
> lisp.h:1329:10: note: in expansion of macro ‘lisp_h_EQ’
>  1329 |   return lisp_h_EQ (x, y);
>       |          ^~~~~~~~~
> In file included from dispnew.c:27:
> lisp.h:1330:1: warning: control reaches end of non-void function [-Wreturn-type]
>  1330 | }
>       | ^
> make[1]: *** [Makefile:406: dispnew.o] Error 1

Yes.  I think the patch below will fix this.

I must admit, I didn't know about --enable-check-lisp-object-type.  When
I tried it out with the fixed lisp_h_EQ, I got lots of other warnings.


But this option generates slower code.  On a 20 second benchmark, the
code was ~0.5s slower than when compiled without the option.  This
probably shouldn't happen, and I don't know why it does.

I need to tidy up the backslashes too.

Anyhow, here's the patch which at least keeps the compiler messages as
warnings:



diff --git a/src/lisp.h b/src/lisp.h
index 08013e94d1..00d9843d6a 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -366,7 +366,7 @@ #define LISP_WORDS_ARE_POINTERS (EMACS_INT_MAX == INTPTR_MAX)
 
 #define lisp_h_PSEUDOVECTORP(a,code)                            \
   (lisp_h_VECTORLIKEP((a)) &&                                   \
-   ((XUNTAG ((a), Lisp_Vectorlike, union vectorlike_header)->size       \
+   ((XUNTAG ((a), Lisp_Vectorlike, union vectorlike_header)->size     \
      & (PSEUDOVECTOR_FLAG | PVEC_TYPE_MASK))                    \
     == (PSEUDOVECTOR_FLAG | ((code) << PSEUDOVECTOR_AREA_BITS))))
 
@@ -382,13 +382,13 @@ #define lisp_h_EQ(x, y) ((XLI ((x)) == XLI ((y)))       \
   || (symbols_with_pos_enabled    \
   && (SYMBOL_WITH_POS_P ((x))                        \
       ? BARE_SYMBOL_P ((y))                               \
-        ? (XSYMBOL_WITH_POS((x)))->sym == (y)          \
+        ? XLI (XSYMBOL_WITH_POS((x))->sym) == XLI (y)           \
         : SYMBOL_WITH_POS_P((y))                       \
-          && ((XSYMBOL_WITH_POS((x)))->sym                   \
-              == (XSYMBOL_WITH_POS((y)))->sym)               \
+          && (XLI (XSYMBOL_WITH_POS((x))->sym)                   \
+              == XLI (XSYMBOL_WITH_POS((y))->sym))               \
       : (SYMBOL_WITH_POS_P ((y))                     \
          && BARE_SYMBOL_P ((x))                           \
-         && ((x) == ((XSYMBOL_WITH_POS ((y)))->sym))))))
+         && (XLI (x) == XLI ((XSYMBOL_WITH_POS ((y)))->sym))))))
 
 #define lisp_h_FIXNUMP(x) \
    (! (((unsigned) (XLI (x) >> (USE_LSB_TAG ? 0 : FIXNUM_BITS)) \

> Robert
> -- 

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2021-11-29 19:16 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 19:56 Correct byte compiler error/warning positions. The solution! Alan Mackenzie
2021-11-27  5:53 ` Eli Zaretskii
2021-11-27  9:31   ` Alan Mackenzie
2021-11-27 10:07     ` Eli Zaretskii
2021-11-27 10:33       ` Alan Mackenzie
2021-11-27 10:51         ` Eli Zaretskii
2021-11-27 23:05           ` Alan Mackenzie
2021-11-28  7:25             ` Eli Zaretskii
2021-11-29 11:50               ` Alan Mackenzie
2021-11-29 12:45                 ` Eli Zaretskii
2021-11-29 19:39                   ` Alan Mackenzie
2021-12-01 15:58                     ` Alan Mackenzie
2021-12-01 16:49                       ` Eli Zaretskii
2021-12-01 16:58                         ` Alan Mackenzie
2021-12-01 17:04                           ` Lars Ingebrigtsen
2021-12-01 17:21                             ` Alan Mackenzie
2021-12-01 17:38                               ` Lars Ingebrigtsen
2021-12-01 20:28                                 ` Alan Mackenzie
2021-12-01 17:08                           ` Eli Zaretskii
2021-12-01 17:12                             ` Alan Mackenzie
2021-12-01 17:53                             ` Andrea Corallo
2021-12-01 17:57                               ` Eli Zaretskii
2021-12-02 11:21                               ` Alan Mackenzie
2021-12-02 16:31                                 ` Andrea Corallo
2021-12-02 20:35                                   ` Alan Mackenzie
2021-12-03 21:05                                     ` Alan Mackenzie
2021-12-04 19:22                                       ` Andrea Corallo
2021-12-04 19:39                                         ` Eli Zaretskii
2021-12-04 19:55                                           ` Andrea Corallo
2021-12-04 19:58                                             ` Eli Zaretskii
2021-12-04 20:06                                               ` Andrea Corallo
2021-12-14 14:29                                         ` Alan Mackenzie
2021-12-15  9:33                                           ` Andrea Corallo
2021-12-17 11:54                                             ` Alan Mackenzie
2021-12-20  8:24                                               ` Andrea Corallo
2021-12-21 17:48                                                 ` Alan Mackenzie
2021-11-29 13:24                 ` Robert Pluim
2021-11-29 19:16                   ` Alan Mackenzie [this message]
2021-11-30  9:52                     ` Robert Pluim
2021-11-28 20:15             ` Andrea Corallo
2021-12-01 16:18               ` Andrea Corallo
2021-12-01 16:46                 ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YaUnCn+mFLym5GAP@ACM \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rpluim@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).