I tried this again under VS.NET 2003. Again, building a project with lib\*.c and gsi\*.c, adding <gambit>\include to the include paths. I also suppressed a few warnings related to coercions.
Could you send me a list of the warnings? I have already fixed a bunch of coercion problems between beta 10 and beta 11.
Here are the error messages:
c:\Projects\Gambit\gambc40b11\lib\_num.c(52351): fatal error C1071: unexpected end of file found in comment
I believe the problem is expressed in line 44720 of _num.c. Here's that line:
___SET_F64(___F64V2,___F64DIV(___F64V1,___F64UNBOX(___GLO(53,___G__23__23_bignum_2e_inexact_2d_mdigit_2d_base))))
I think what's going on is the ___F64UNBOX() is returning a string that starts with '*' so the ___F64DIV expands to a string with '/*' in it.
Here's the definition of ___F64DIV:
#define ___F64DIV(x,y)(x/y)
Changing this to
#define ___F64DIV(x,y)(x/(y))
... eliminates the error. This same problem occurs in two other functions:
#define ___F64INV(x)1.0/x #define ___FIXINV(x)___FIX((___FIX(1)/x))
I added parens around the x's and it compiles now.
Great! I suspected something like this was going on and I'm glad you pinpointed the problem.
After running it, I got a console window and running some sort of command line program. I tried to define factorial and got this error when I typed the first ')':
Run-Time Check Failure #3 - The variable 'e' is being used without being defined. line 2690 of os_tty.c
That line is at the end of this function:
lineeditor_output_terminal_op_move_abs
I changed the declaration of e (the unbound variable to be this:
___SCMOBJ e = ___FIX(___NO_ERR);
and it successfully ran (fact 1000). I haven't played with it further yet.
Nice catch. Which version of MS VC are you using? Did you use any special options to get these error checks?
Is there a test suite?
Try "make check". You may have to install MinGW to get make. Otherwise look at tests/makefile and do the steps manually. Marc
Afficher les réponses par date
At 09:34 PM 10/25/2004, Marc Feeley wrote: Which version of MS VC are you using? Did you use any special options to get these error checks? I'm using Visual Studio.NET 2003, version 7.1.30088. I didn't use anything special to get the runtime check. (I'm not a VS.NET guru. I did look for something that would > I tried this again under VS.NET 2003. Again, building a project with > lib\*.c and gsi\*.c, > adding <gambit>\include to the include paths. I also suppressed a few > warnings related to coercions. Could you send me a list of the warnings? I have already fixed a bunch of coercion problems between beta 10 and beta 11. I put some of them at the end of this message. I stopped suppressing warnings and had 43K lines of messages before I gave up. (Visual Studio was getting slower and slower just trying to insert the warnings into one of its windows.) 8^) > Is there a test suite? Try "make check". You may have to install MinGW to get make. Otherwise look at tests/makefile and do the steps manually. I will when I get a chance later in the week. There are only 7 distinct kinds of warnings in the 1st 10K lines of compiler output. Here are the 1st lines of each type plus VS.NET's description of each. c:\Projects\Gambit\gambc40b11\gsi\_gsi.c(956) : warning C4101: '___temp' : unreferenced local variable Visual C++ Concepts: Building a C/C++ Program Compiler Warning (level 3) C4101'identifier' : unreferenced local variable The local variable is never used. This warning will occur in the obvious situation: // C4101a.cpp // compile with: /W3 int main() { int i; // C4101 } However, this warning will also occur when calling a static member function through an instance of the class: // C4101b.cpp // compile with: /W3 struct S { static int func() { return 1; } }; int main() { S si; // C4101, si is never used int y = si.func(); return y; } In this situation, the compiler uses information about si to access the static function, but the instance of the class is not needed to call the static function; hence the warning. To resolve this warning, you could: Add a constructor, in which the compiler would use the instance of si in the call to func. Remove the static keyword from the definition of func. Call the static function explicitly: int y = S::func();. -------------------------------------------------------------------------------- c:\Projects\Gambit\gambc40b11\gsi\_gsi.c(968) : warning C4102: '___L1__20___gsi' : unreferenced label Visual C++ Concepts: Building a C/C++ Program Compiler Warning (level 3) C4102'label' : unreferenced label The label is defined but never referenced. The compiler ignores the label. The following sample generates C4102: // C4102.cpp // compile with: /W3 int main() { int a; test: // C4102, remove the unreferenced label to resolve a = 1; } -------------------------------------------------------------------------------- c:\Projects\Gambit\gambc40b11\lib\os_tty.c(7249) : warning C4113: 'BOOL (__stdcall *)()' differs in parameter lists from 'PHANDLER_ROUTINE' Visual C++ Concepts: Building a C/C++ Program Compiler Warning (level 1) C4113'identifier1' differs in parameter lists from 'identifier2' A function pointer is assigned to another function pointer, but the formal parameter lists of the functions do not agree. The assignment is compiled without modification. -------------------------------------------------------------------------------- c:\Projects\Gambit\gambc40b11\lib\os_tty.c(7031) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data Visual C++ Concepts: Building a C/C++ Program Compiler Warning (level 1) C4244'variable' : conversion from 'type' to 'type', possible loss of data You assigned a value of type __int64 to a variable of type unsigned int. A possible loss of data may have occurred. C4244 can also fire at levels 3 and 4; see Compiler Warning (levels 3 and 4) C4244 for more information. -------------------------------------------------------------------------------- c:\Projects\Gambit\gambc40b11\lib\os_time.c(234) : warning C4307: '*' : integral constant overflow Visual C++ Concepts: Building a C/C++ Program Compiler Warning (level 2) C4307'operator' : integral constant overflow The operator is used in an expression that results in an integer constant overflowing the space allocated for it. You may need to use a larger type for the constant. A signed int holds a smaller value than an unsigned int because the signed int uses one bit to represent the sign. The following sample generates C4307: // C4307.cpp // compile with: /W2 int i = 2000000000 + 2000000000; // C4307 int j = (unsigned)2000000000 + 2000000000; // OK int main() { } -------------------------------------------------------------------------------- c:\Projects\Gambit\gambc40b11\gsi\_gsi.c(1111) : warning C4311: 'type cast' : pointer truncation from 'int *' to 'int' Visual C++ Concepts: Building a C/C++ Program Compiler Warning (level 1) C4311'variable' : pointer truncation from 'type' to 'type' A 64-bit pointer was truncated to a 32-bit int or 32-bit long. -------------------------------------------------------------------------------- c:\Projects\Gambit\gambc40b11\gsi\_gsi.c(1116) : warning C4312: 'type cast' : conversion from 'int' to '___label_struct *' of greater size Visual C++ Concepts: Building a C/C++ Program Compiler Warning (level 1) C4312'variable' : conversion from 'type' to 'type' of greater size You attempted to assign a 32-bit value to a 64-bit integer. For example, casting a 32-bit int or 32-bit long to a 64-bit pointer. -------------------------------------------------------------------------------- I'd prefer to look at representative samples since most of the warnings repeat *many* times, but having a fuller listing may help. I'll send you the 1st 10K warnings in a separate post (not to the whole group). - Mark
On Monday, October 25, 2004, at 11:34 PM, Marc Feeley wrote:
Here are the error messages:
c:\Projects\Gambit\gambc40b11\lib\_num.c(52351): fatal error C1071: unexpected end of file found in comment
I believe the problem is expressed in line 44720 of _num.c. Here's that line:
___SET_F64(___F64V2,___F64DIV(___F64V1,___F64UNBOX(___GLO(53,___G__23_ _23_bignum_2e_inexact_2d_mdigit_2d_base))))
I think what's going on is the ___F64UNBOX() is returning a string that starts with '*' so the ___F64DIV expands to a string with '/*' in it.
Here's the definition of ___F64DIV:
#define ___F64DIV(x,y)(x/y)
Changing this to
#define ___F64DIV(x,y)(x/(y))
... eliminates the error. This same problem occurs in two other functions:
#define ___F64INV(x)1.0/x #define ___FIXINV(x)___FIX((___FIX(1)/x))
I added parens around the x's and it compiles now.
Great! I suspected something like this was going on and I'm glad you pinpointed the problem.
Isn't the invariant supposed to be that each macro is supposed to return a fully parenthesized expression, so that you should change ___F64UNBOX rather than ___F64DIV? And what is ___FIXINV supposed to do? The only definition or use in the entire Gambit source tree of ___FIXINV is a definition in gambit.h, so I think it should just be removed from gambit.h. Brad
participants (3)
-
Bradley Lucier -
Marc Feeley -
Mark H. Shirley