Hi Timothy,
   The right thing to do is to report the bug to the FCC maintainers.  This is legal C and useful.  So it should not be causing problems right?

Eliot (phone)

On Mar 30, 2015, at 8:58 AM, gettimothy <gettimothy@zoho.com> wrote:

Just a heads up/progress report.

The "fix" of putting a 
#define NoDbgRegParms               "<--empty definition"
in config.h.in for autotools does NOT translate to CMake because CMake builds its own config.h based on some tests/probing in a config.cmake file.
This then creates its own config.h.in (cmake version) and then config.h

When it does so, it does NOT respect the "empty definition" and just leave things alone, but "helps" by placing a 
/* #undef NoDbgRegParms */ 
in config.h


There are 3 strategies I have in mind.

1. Have the user hand edit config.h (unacceptable, rejected)
2. Find a CMake workaround to generate the #define NoDbgRegParms 
3. Take this as a clue about how autotools expects things and make the logic in Cog/src/vm/cogit.h Cog/src/vm/cointerp.h etc logic so that it works with 

#if !PRODUCTION && defined(__GNUC__) && !defined(NoDbgRegParms)
# define NoDbgRegParms __attribute__ ((regparm (0)))
#endif

I will be focusing on approach 3 for a bit. "Maybe" its

a. something about a comparison between the !defines and the !PRODUCTION
b. a conflict created when autotools does its macro-expansion since the test is in multiple .h files.

cheers.

tty.