Hallo,
Just a heads up: While compiling Gambit, Clang displays the following warning (thousands of times):
```
_gambitgsc.c:27730:1: warning: shifting a negative signed value is undefined [-Wshift-negative-value] ___DEF_NEW_SYM_GLO(___S_xmm5,___S_xmm6,___X3334,376674065,___G_xmm6) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/gambit.h:5487:35: note: expanded from macro '___DEF_NEW_SYM_GLO' ___EXP_DATA(___glo_struct,glo) = {___UNB1, ___FIX(hash), 0}; \ ^~~~~~~ ../include/gambit.h:2098:38: note: expanded from macro '___UNB1' #define ___UNB1 ((___CAST(___WORD,-7)<<___TB)+___tSPECIAL) ~~~~~~~~~~~~~~~~~~~^
```
This is indeed undefined behaviour according to the C standard[1]. The resulting `gsi` gets stuck when started and must be killed with SIGKILL.
[1] http://stackoverflow.com/a/22883850/341446
Cheers,
Afficher les réponses par date
Strange that this is undefined behavior in C. Is it only when left shifting a constant or any signed integer expression? In general I can understand it is undefined because it depends on the size of the integer type, but here ___TB is 3 so -7<<___TB will fit in any integer type including 8 bit integers!
Also, I don’t understand why gsi gets stuck. After all you only got warnings.
Can you give more details, such as OS and Gambit versions? I use the latest clang from Xcode and don’t have this problem.
Marc
On Jan 19, 2016, at 3:35 AM, Alex Silva asandroq@gmail.com wrote:
Hallo,
Just a heads up: While compiling Gambit, Clang displays the following warning (thousands of times):
_gambitgsc.c:27730:1: warning: shifting a negative signed value is undefined [-Wshift-negative-value] ___DEF_NEW_SYM_GLO(___S_xmm5,___S_xmm6,___X3334,376674065,___G_xmm6) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/gambit.h:5487:35: note: expanded from macro '___DEF_NEW_SYM_GLO' ___EXP_DATA(___glo_struct,glo) = {___UNB1, ___FIX(hash), 0}; \ ^~~~~~~ ../include/gambit.h:2098:38: note: expanded from macro '___UNB1' #define ___UNB1 ((___CAST(___WORD,-7)<<___TB)+___tSPECIAL) ~~~~~~~~~~~~~~~~~~~^
This is indeed undefined behaviour according to the C standard[1]. The resulting `gsi` gets stuck when started and must be killed with SIGKILL.
[1] http://stackoverflow.com/a/22883850/341446
Cheers,
-alex http://unendli.ch/ _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hallo,
On 19/01/16 14:39, Marc Feeley wrote:
Strange that this is undefined behavior in C. Is it only when left shifting a constant or any signed integer expression? In general I can understand it is undefined because it depends on the size of the integer type, but here ___TB is 3 so -7<<___TB will fit in any integer type including 8 bit integers!
The standard call those "expressions", so it shouldn't be limited to constants only. But those get caught during compile time. Interestingly, for right shifts the result is implementation-defined instead of undefined.
Also, I don’t understand why gsi gets stuck. After all you only got warnings.
Given the undefined behaviour the compiler can do whatever it wants, including optimizing those expressions away, but I am just guessing.
Can you give more details, such as OS and Gambit versions? I use the latest clang from Xcode and don’t have this problem.
This is Ubuntu 14.04 with Clang 3.7.1. I downloaded the LLVM binary distribution from http://www.llvm.org/. Gambit version 4.8.3.
Cheers,
OK, my latest commit fixes this issue (tested on OS X). Could you try on Ubuntu and let me know if issues persist?
Marc
On Jan 19, 2016, at 8:51 AM, Alex Silva asandroq@gmail.com wrote:
Hallo,
On 19/01/16 14:39, Marc Feeley wrote:
Strange that this is undefined behavior in C. Is it only when left shifting a constant or any signed integer expression? In general I can understand it is undefined because it depends on the size of the integer type, but here ___TB is 3 so -7<<___TB will fit in any integer type including 8 bit integers!
The standard call those "expressions", so it shouldn't be limited to constants only. But those get caught during compile time. Interestingly, for right shifts the result is implementation-defined instead of undefined.
Also, I don’t understand why gsi gets stuck. After all you only got warnings.
Given the undefined behaviour the compiler can do whatever it wants, including optimizing those expressions away, but I am just guessing.
Can you give more details, such as OS and Gambit versions? I use the latest clang from Xcode and don’t have this problem.
This is Ubuntu 14.04 with Clang 3.7.1. I downloaded the LLVM binary distribution from http://www.llvm.org/. Gambit version 4.8.3.
Cheers,
-alex http://unendli.ch/
Hallo,
On 19/01/16 20:28, Marc Feeley wrote:
OK, my latest commit fixes this issue (tested on OS X). Could you try on Ubuntu and let me know if issues persist?
Thanks for the quick fix. I still see the problem, but it seems to be actually a bug in Clang. If I build stock 4.8.3 without "--enable-single-host", "gsi" runs fine despite the warnings. With "--enable-single-host", both 4.8.3 and latest master get stuck.
Cheers,
Good! (for Gambit but bad for clang!) Gambit has a long history in triggering bugs in C compilers…
I will check on my end too.
Marc
On Jan 20, 2016, at 9:28 AM, Alex Silva asandroq@gmail.com wrote:
Hallo,
On 19/01/16 20:28, Marc Feeley wrote:
OK, my latest commit fixes this issue (tested on OS X). Could you try on Ubuntu and let me know if issues persist?
Thanks for the quick fix. I still see the problem, but it seems to be actually a bug in Clang. If I build stock 4.8.3 without "--enable-single-host", "gsi" runs fine despite the warnings. With "--enable-single-host", both 4.8.3 and latest master get stuck.
Cheers,
-alex http://unendli.ch/
I can confirm that, on OS X with clang 3.7.1 (installed using brew), gsi goes into an infinite loop when configured with ./configure --enable-single-host CC="clang-3.7" . Gdb says it is stuck somewhere in _num.scm .
I also tried debugging this issue with ./configure --enable-single-host --enable-debug CC="clang-3.7" … of course now that it is compiled for debug clang compiles gsi fine and the problem goes away... Hate heisenbugs!
clang has given me quite a few problems in the past (see the end of file INSTALL.txt).
Are you going to file a bug report with LLVM? I’ve lost patience in the past filing bug reports for C compilers that never get processed…
Marc
On Jan 20, 2016, at 9:30 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
Good! (for Gambit but bad for clang!) Gambit has a long history in triggering bugs in C compilers…
I will check on my end too.
Marc
On Jan 20, 2016, at 9:28 AM, Alex Silva asandroq@gmail.com wrote:
Hallo,
On 19/01/16 20:28, Marc Feeley wrote:
OK, my latest commit fixes this issue (tested on OS X). Could you try on Ubuntu and let me know if issues persist?
Thanks for the quick fix. I still see the problem, but it seems to be actually a bug in Clang. If I build stock 4.8.3 without "--enable-single-host", "gsi" runs fine despite the warnings. With "--enable-single-host", both 4.8.3 and latest master get stuck.
Cheers,
-alex http://unendli.ch/
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hallo,
On 20/01/16 20:53, Marc Feeley wrote:
I can confirm that, on OS X with clang 3.7.1 (installed using brew), gsi goes into an infinite loop when configured with ./configure --enable-single-host CC="clang-3.7" . Gdb says it is stuck somewhere in _num.scm .
I also tried debugging this issue with ./configure --enable-single-host --enable-debug CC="clang-3.7" … of course now that it is compiled for debug clang compiles gsi fine and the problem goes away... Hate heisenbugs!
I have compiled it without `--enable-debug` but with C debugging symbols. For me it always gets stuck in _io.scm. I have attached a short GDB session as a text file.
clang has given me quite a few problems in the past (see the end of file INSTALL.txt).
Are you going to file a bug report with LLVM? I’ve lost patience in the past filing bug reports for C compilers that never get processed…
I intend to but it will not be easy to isolate a test case.
Cheers,