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

On 18 January 2009 at 11:04 Jira commented:

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


On 3 February 2009 at 10:19 Jira commented:

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 = len
1.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;


On 3 February 2009 at 10:43 Jira commented:

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=841

A 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