STR-765: sglr enters endless (probably -- didnt wait forever to check) loop when aterm is compiled with gcc 4.3
When compiling aterm (our 0.17 release drop), then sdf (also 0.17 release) drop using the above gcc 4.3.2, it’s not possible to compile strategoxt-head. An endless loop is encountered when sglr tries to parse Stratego.def:
/home/karltk/apps/sxt-bugs/763/sdf-bundle-2.4/bin/sglr -s SDF -p /home/karltk/apps/sxt-bugs/763/sdf-bundle-2.4/share/pgen/Sdf2.baf -i Stratego.def -o /var/tmp/Stratego.23298.asfix
However, if aterm is compiled with gcc 4.1 or gcc 4.2, the problem disappears. These work:
gcc-4.2 (GCC) 4.2.4 (Ubuntu 4.2.4-3ubuntu4)
gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)Probably it’s a compiler “feature” in gcc 4.3, and probably we’ve discovered it already:)
Submitted on 17 January 2009 at 23:43
Issue Log
STR-765, vincent.ordy:
Did you try to compile ATerm without -O2?I had a similar problem a short time ago because of new optimizations in gcc (I had to set the try_long_max variable volatile in aterm/hash.c, calc_long_max(); it seems like an optimization assume there are no long overflow).
STR-765, karltk:
diff -x _inst -x _build -x .svn -ur aterm/bafio.c aterm-2.5/aterm/bafio.c
— aterm/bafio.c 2008-11-28 19:04:17.000000000 +0100
+++ aterm-2.5/aterm/bafio.c 2008-04-11 22:54:16.000000000 +0200
@@ -406,7 +406,7 @@
/* Assure buffer can hold the string /
if (text_buffer_size < (len+1))
{
- text_buffer_size = len1.5;
+ text_buffer_size = len*1.5 + 1;
text_buffer = (char ) realloc(text_buffer, text_buffer_size);
if(!text_buffer)
ATerror("out of memory in readString (%d)
", text_buffer_size);
diff -x _inst -x _build -x .svn -ur aterm/hash.c aterm-2.5/aterm/hash.c
— aterm/hash.c 2008-11-28 22:23:53.000000000 +0100
+++ aterm-2.5/aterm/hash.c 2008-04-11 22:54:16.000000000 +0200
@@ -99,7 +99,7 @@
/{{{ static long calc_long_max() */
static long calc_long_max()
{
- long try_long_max;
+ volatile long try_long_max;
long long_max;
long delta;
STR-765, eelco:
Regarding the ATerm calc_long_max() issue, that’s a known bug: http://bugzilla.sen.cwi.nl:8080/show_bug.cgi?id=841A better solution than using volatile is to drop calc_long_max() altogether and replace it with LONG_MAX. Patch is here: https://svn.nixos.org/repos/nix/nixpkgs/branches/stdenv-updates/pkgs/development/libraries/aterm/max-long.patch
Log in to post comments