AST node attributes that are size_t overflow

In !80 (merged), after having ebased to 4722c4f3, I started having problems with the compiler; it crashes at the PFFUN traversal (which deals with setting up some constants for RT profiling). The crashes are caused by fields within the N_fundef attribute struct defaulting to some insane value. A closer look shows that the problematic field is FunNo, which has type size_t and should default to zero but doesn't.

Running through the debug for some trivial SaC program that makes use of Stdlib, we get this:

Breakpoint 1, PFfundef (arg_node=0x6bb500, arg_info=0x4a6f130) at sac2c/src/libsac2c/profile/annotate_fun_calls.c:251
251	    DBUG_ENTER ();
(gdb) display arg_node->attribs.N_fundef->Name
1: arg_node->attribs.N_fundef->Name = 0x6c4c70 "main"
(gdb) display arg_node->attribs.N_fundef->FunNo
2: arg_node->attribs.N_fundef->FunNo = 0
(gdb) c
Continuing.

Breakpoint 1, PFfundef (arg_node=0xa6af80, arg_info=0x4a6f130) at sac2c/src/libsac2c/profile/annotate_fun_calls.c:251
251	    DBUG_ENTER ();
2: arg_node->attribs.N_fundef->FunNo = 0
1: arg_node->attribs.N_fundef->Name = 0x636590 "init"
(gdb) 
Continuing.

Breakpoint 1, PFfundef (arg_node=0x86e060, arg_info=0x4a6f130) at sac2c/src/libsac2c/profile/annotate_fun_calls.c:251
251	    DBUG_ENTER ();
2: arg_node->attribs.N_fundef->FunNo = 46909632806912
1: arg_node->attribs.N_fundef->Name = 0x86dfc0 "init_TheWorld"

The last debug printout clearly shows that the FunNo attribute for the init_TheWorld function is greater than zero. A look through the sources shows that PFFUN traversal is the only place in the compiler where we read or write the FunNo attribute, so this isn't being caused by some code in a traversal doing something naughty.

I went through several ideas of how this can be happening - but nothing made much sense. One thing I did find was that size_t is not always defined to be an unsigned integer type, at least in GCC, as there is some backwards compatibility support where size_t can either be long unsigned int or long int (at least on my system and the cluster). However this consistent... there should be no problem with it being unsigned or not, so long as one uses it consistently. Another idea had to do with implicit type casting or even type promotion. I don't see though how this can be the causes as again we are not affecting is value at all beforehand.

Finally, in shear desperation, I decided to recompile World.sac in Stdlib with GCC 6.3 (so far I'd been using GCC 4.8). Here is what the debug output looks like:

Breakpoint 1, PFfundef (arg_node=0x6bb500, arg_info=0x4a6f130) at sac2c/src/libsac2c/profile/annotate_fun_calls.c:251
251	    DBUG_ENTER ();
(gdb) print arg_node->attribs.N_fundef->Name 
$1 = 0x6c4c70 "main"
(gdb) display arg_node->attribs.N_fundef->Name 
1: arg_node->attribs.N_fundef->Name = 0x6c4c70 "main"
(gdb) display arg_node->attribs.N_fundef->FunNo
2: arg_node->attribs.N_fundef->FunNo = 0
(gdb) c
Continuing.

Breakpoint 1, PFfundef (arg_node=0xa6af80, arg_info=0x4a6f130) at sac2c/src/libsac2c/profile/annotate_fun_calls.c:251
251	    DBUG_ENTER ();
2: arg_node->attribs.N_fundef->FunNo = 0
1: arg_node->attribs.N_fundef->Name = 0x636590 "init"
(gdb) 
Continuing.

Breakpoint 1, PFfundef (arg_node=0x86e060, arg_info=0x4a6f130) at sac2c/src/libsac2c/profile/annotate_fun_calls.c:251
251	    DBUG_ENTER ();
2: arg_node->attribs.N_fundef->FunNo = 0
1: arg_node->attribs.N_fundef->Name = 0x86dfc0 "init_TheWorld"

WTF?!?!

I decided to recompile a few more Stdlib modules that displayed the problem, just to be sure that this not an random, and using GCC 6.3 solves the problem.

I'm not sure if I've stumbled across a GCC bug (in version 4.8.5) or whether there is something about how we set the default node attribute value that is treated differently by the compilers. Further investigation is necessary. I leave this issue here in case other have similar problem.

Further details:

• strace shows that in all instances where the problem occurs, we are pulling in the Tree files.
• problems started with the change to size_t in the compiler, as part of MR !69 (merged).