GNU bug report logs - #16535
Compiler bug ?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16535 in the body.
You can then email your comments to 16535 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Compiler bug ?
Date: Fri, 24 Jan 2014 16:03:17 +0100

[Message part 1 (text/plain, inline)]

I hit a bug while compiling Gnu Emacs trunk development.

The following test :
 passed    17/1152  bool-vector-count-population-1-nil
fails unless I apply the following patch :

 === modified file 'src/data.c'
--- src/data.c  2014-01-03 06:47:27 +0000
+++ src/data.c  2014-01-24 14:59:16 +0000
@@ -3012,8 +3012,10 @@
     {
       int i = 0, count = 0;
       while (count += count_one_bits_ll (w),
-            BITS_PER_BITS_WORD <= (i += BITS_PER_ULL))
+            BITS_PER_BITS_WORD <= i) {
+       i += BITS_PER_ULL;
        w = shift_right_ull (w);
+      }
       return count;
     }
 }

This is with :
$ gcc --version
gcc.exe (Rev6, Built by MSYS2 project) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Given the nature of the patch, I don't think it is specific of th MinGW64
gcc version.

Regards,

Fabrice Popineau

[Message part 2 (text/html, inline)]

Message #8 received at 16535 <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: 16535 <at> debbugs.gnu.org
Subject: Re: Optimization bug?
Date: Fri, 24 Jan 2014 17:28:53 +0100

[Message part 1 (text/plain, inline)]

I forgot to add that the previous report happens when compiling with '-O2
-g' or with '-O3 -g'.

If I use '-O0 -g' and no patch, then I get :

Test bool-vector-count-population-1-nil backtrace:
  (if (unwind-protect (setq value-67354 (apply fn-67352 args-67353)) (
  (let (form-description-67356) (if (unwind-protect (setq value-67354
  (let ((value-67354 (quote ert-form-evaluation-aborted-67355))) (let
  (let ((fn-67352 (function eql)) (args-67353 (list (bool-vector-count
  (let* ((bv (make-bool-vector 45 nil))) (aset bv 40 t) (aset bv 0 t)
  (lambda nil (let* ((bv (make-bool-vector 45 nil))) (aset bv 40 t) (a
  #[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\317\320%DC
  funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\31
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  #[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\316%DC\2
  funcall(#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\
  ert-run-test([cl-struct-ert-test bool-vector-count-population-1-nil
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
  ert-run-tests(t #[385 "\306\307\"\203D\211\211G\310U\203\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("-L" ";." "-l" "./add-log-tests.el" "-l" "./advice-t
  command-line()
  normal-top-level()

Which is not good either.

Fabrice

[Message part 2 (text/html, inline)]

Message #11 received at 16535 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 16535 <at> debbugs.gnu.org
Subject: Re: Compiler bug ?
Date: Fri, 24 Jan 2014 13:05:25 -0800

There's an obvious bug there: a negated-comparison typo, which I fixed 
in trunk bzr 116147.

This raises another point. The bug was triggered because BITS_PER_ULL < 
BITS_PER_BITS_WORD. The former should be the number of bits in 'unsigned 
long long' (or 'unsigned long' on platforms that lack that), the latter 
the number of bits in 'size_t'. I don't know of any platform where the 
former is less than the latter, so I worry that there's a 
misconfiguration problem here, which might cause some other subtle bugs 
on your platform. Can you please give more details about your platform, 
and how you built Emacs, and the values of BITS_PER_BITS_WORD, 
HAVE_UNSIGNED_LONG_LONG_INT, BITS_PER_ULL, BITS_WORD_MAX, and ULL_MAX on 
your platform? GDB should be able to tell you those values. Thanks.

Message #14 received at 16535 <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 16535 <at> debbugs.gnu.org
Subject: Re: Compiler bug ?
Date: Sat, 25 Jan 2014 00:06:38 +0100

[Message part 1 (text/plain, inline)]

Actually, afaik BITS_PER_ULL == BITS_PER_BITS_WORD

Starting program: C:\source\Gnu\emacs\mingw\src/emacs.exe -Q
[New Thread 25544.0x113f4]

Breakpoint 3, main (argc=2, argv=0xc04880) at emacs.c:702
702     {
(gdb) p /d BITS_PER_ULL
$1 = 64
(gdb) p /d BITS_PER_BITS_WORD
$2 = 64

$ grep HAVE_UNSIGNED config.h
#define HAVE_UNSIGNED_LONG_LONG_INT 1

I was at bzr116143.
With your change, all the bit vector related the tests pass.

Thanks,

Fabrice


2014/1/24 Paul Eggert <eggert <at> cs.ucla.edu>

> There's an obvious bug there: a negated-comparison typo, which I fixed in
> trunk bzr 116147.
>
> This raises another point. The bug was triggered because BITS_PER_ULL <
> BITS_PER_BITS_WORD. The former should be the number of bits in 'unsigned
> long long' (or 'unsigned long' on platforms that lack that), the latter the
> number of bits in 'size_t'. I don't know of any platform where the former
> is less than the latter, so I worry that there's a misconfiguration problem
> here, which might cause some other subtle bugs on your platform. Can you
> please give more details about your platform, and how you built Emacs, and
> the values of BITS_PER_BITS_WORD, HAVE_UNSIGNED_LONG_LONG_INT,
> BITS_PER_ULL, BITS_WORD_MAX, and ULL_MAX on your platform? GDB should be
> able to tell you those values. Thanks.
>

[Message part 2 (text/html, inline)]

Message #19 received at 16535-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 16535-done <at> debbugs.gnu.org
Subject: Re: Compiler bug ?
Date: Fri, 24 Jan 2014 15:35:21 -0800

On 01/24/2014 03:06 PM, Fabrice Popineau wrote:
> Actually, afaik BITS_PER_ULL == BITS_PER_BITS_WORD

Ah, OK, thanks for following up. It looks like the negated-comparison 
bug caused undefined behavior due to integer overflow in 
count_one_bits_word; once that happens it's anybody's guess what 
compilers will do; maybe you hit the jackpot. Anyway, the Emacs bug is 
fixed (and there doesn't seem to have been a compiler bug) so I'll close 
this report.

Previous Next

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