Gambit no longer compiles with Clang >= 3.7
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/
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, -- -alex http://unendli.ch/
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, -- -alex http://unendli.ch/
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, -- -alex http://unendli.ch/
participants (2)
-
Alex Silva -
Marc Feeley