bug#16535: Compiler bug ?

bug#16535: Compiler bug ?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1437 bytes --]

bug#16535: Optimization bug?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1853 bytes --]

bug#16535: Compiler bug ?

[Paul Eggert]

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.

bug#16535: Compiler bug ?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

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@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.
>

[-- Attachment #2: Type: text/html, Size: 1897 bytes --]

bug#16535: Compiler bug ?

[Paul Eggert]

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.