* bug#16535: Compiler bug ?
@ 2014-01-24 15:03 Fabrice Popineau
2014-01-24 16:28 ` bug#16535: Optimization bug? Fabrice Popineau
2014-01-24 21:05 ` bug#16535: Compiler bug ? Paul Eggert
0 siblings, 2 replies; 5+ messages in thread
From: Fabrice Popineau @ 2014-01-24 15:03 UTC (permalink / raw)
To: 16535
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16535: Optimization bug?
2014-01-24 15:03 bug#16535: Compiler bug ? Fabrice Popineau
@ 2014-01-24 16:28 ` Fabrice Popineau
2014-01-24 21:05 ` bug#16535: Compiler bug ? Paul Eggert
1 sibling, 0 replies; 5+ messages in thread
From: Fabrice Popineau @ 2014-01-24 16:28 UTC (permalink / raw)
To: 16535
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16535: Compiler bug ?
2014-01-24 15:03 bug#16535: Compiler bug ? Fabrice Popineau
2014-01-24 16:28 ` bug#16535: Optimization bug? Fabrice Popineau
@ 2014-01-24 21:05 ` Paul Eggert
2014-01-24 23:06 ` Fabrice Popineau
1 sibling, 1 reply; 5+ messages in thread
From: Paul Eggert @ 2014-01-24 21:05 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: 16535
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16535: Compiler bug ?
2014-01-24 21:05 ` bug#16535: Compiler bug ? Paul Eggert
@ 2014-01-24 23:06 ` Fabrice Popineau
2014-01-24 23:35 ` Paul Eggert
0 siblings, 1 reply; 5+ messages in thread
From: Fabrice Popineau @ 2014-01-24 23:06 UTC (permalink / raw)
To: Paul Eggert; +Cc: 16535
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16535: Compiler bug ?
2014-01-24 23:06 ` Fabrice Popineau
@ 2014-01-24 23:35 ` Paul Eggert
0 siblings, 0 replies; 5+ messages in thread
From: Paul Eggert @ 2014-01-24 23:35 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: 16535-done
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-01-24 23:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-24 15:03 bug#16535: Compiler bug ? Fabrice Popineau
2014-01-24 16:28 ` bug#16535: Optimization bug? Fabrice Popineau
2014-01-24 21:05 ` bug#16535: Compiler bug ? Paul Eggert
2014-01-24 23:06 ` Fabrice Popineau
2014-01-24 23:35 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.