Re: [Chicken-users] A question on C_reclaim

[Jörg F . Wittenberger]

This turns out to be a very gcc related issue.
Optimisation flags that is.

So far I have this only on
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
for sure.

The standard DEBUGBUILD=1 will omit the -Os from the compile.

For me this gives working code and no valgrind complaints.

When I add -Os to the debug build I harvest valgrind complaints
pertaining to source lines for which I've seen gcc warnings.

The attached diff against current git master works around these
warnings and coincidentally those valgrind warnings will disappear too.

I'm afraid it's really gcc who is to blame here:
I do assume so, because we've just seen the same thing wrt. the exactf.
To me it looks as if gcc would reorder instructions like this

  if(gc_mode == GC_MAJOR && C_enable_gcweak && weakn)
     C_dbg("GC", C_text("%d recoverable weakly held items found\n"), 
weakn);

to actually access "weakn" while "C_enable_gcweak = 0".

The attached diff rewrites the code (besides some less relevant spots)
a litte more messy:

   if(gc_mode == GC_MAJOR && C_enable_gcweak)
     if(weakn) C_dbg("GC", C_text("%d recoverable weakly held items 
found\n"), weakn);

Wile I don't think this would be the better C code, it has the effect that

A) gcc will still warn about about
  'weakn' may be used uninitialized in this function

B) valgrind will no longer warn that the resulting code will access
  uninilialized memory at that very line of code.


The moral of the story: if your C compiler warns about valid C, don't
trust it to compile valid code anyway.

Best Regards

/Jörg

PS: The other spots are 1:1 warning from gcc:valgrind.

gccwarn.diff
Description: gccwarn.diff