Tcl Source Code

Hello all,
I'm not sure this is a bug, but I was advised to post here.

Some tests fails in x64 Interix, see shell output in attached file. There is one tests which core dumps, a few fails due to missing encodings and some tests fails integer conversion.

I think the integer conversion failures are the most important at first. 

Note that type long is 64bit in my system.

Thanks
Jerker

---------------------
My machine:
$ uname -a
Interix max2008 6.0 10.0.6030.0 genuineintel Intel64_Family_15_Model_6_Stepping_5
Which means NT POSIX subsystem (SUA) with Interix SDK 6.0 on a x64 Windows 2008 machine.
This system has LP64 (long type is 64bit)

Tools used:
GNU make, GNU m4, Interix Korn shell and cc script as compiler (wraps MS x64 Compiler 15.00.21022.08).

Logged In: YES 
user_id=80530
Originator: NO


I claimed this report when it appeared 
there were errors in integer representations.

Later followups seems to have moved to a
completely different topic of platform
configurations for build, which I'm not
well-suited to help with.

If there are still integer representation
bugs that require my attention, please open
a new report, assign to me, and stay on
that topic there, please.

Logged In: YES 
user_id=1499688
Originator: YES

The problem here is that the compiler define is used to 
determine specific MSVCRT LIBC issues. It would be the 
same situation if the GCC define was used for GLIBC issues.
Pelles C have its own LIBC with a C99 math library, so
have also the Intel compiler. And Interix have a BSD LIBC
but is using MSVC and so on ...

> The problem with the "fix it in the configurator" approach
> is that most people who build Tcl with MSVC more recent 
> than VC6 don't *use* the configurator.  It appears to be 
> inordinately difficult to make an autoconf-based toolchain
> work with VC7 or later (not to mention the deployment 
> nightmares that the use of 'mt' brings).

I agree, autoconf with dependence of m4 and a unix shell is
not something you want to deal with in a Windows compile.
A config.h would be easy to solve things, but TCL do not 
have one. I don't know how to solve this.

One possible solution could be to create a config.h 
for MSVCRT and use the force include option -FI"config.h".
For a Visual Studio compile there are probably a lot of
things you want to add to this file, e.g. warning pragmas.

Logged In: YES 
user_id=99768
Originator: NO

If it is true that compilers other than MSVC assert _MSC_VER,
but fail to support a Microsoft-style _isnan and _finite,
then the patch included with the comments from 2008-07-09 08:42
is indeed correct.

Does the code in question indeed fail to compile on the Intel
or Pelles C compilers, or get an _isnan or _finite implementation
that doesn't work?  If not, the fact that those compilers
also support the ANSI calls is largely irrelevant; calling
the Microsoft special stuff is perhaps undesirable from the
"100% ANSI cleanliness" standpoint but should work.

The problem with the "fix it in the configurator" approach is
that most people who build Tcl with MSVC more recent than VC6
don't *use* the configurator.  It appears to be inordinately
difficult to make an autoconf-based toolchain work with
VC7 or later (not to mention the deployment nightmares that
the use of 'mt' brings). 

If nothing is failing for the original submitter, I'm inclined
to say "don't fix what ain't broken."  If there is a failure
that can be traced to this particular "#ifdef", the proposed
fix looks Mostly Harmless - Windows tests pass with it, on
both gcc and VC2k5.

Logged In: YES 
user_id=1499688
Originator: YES

No, the correction I made had nothing to do with the conversion errors.
I just wanted to point out that the package compiled almost out of the box.

Obviously I edited my 8.5.2 compile and probably made a mistake somewhere (sorry for that). That was why I wanted to track down the function responsible. If I may guess, it could have been the mp_digit type, which is somewhat ambiguous defined in the headers. But I have nothing to back it up. To be sure, I need to debug the failing tests and debugging is rather complicated to setup in Interix. If you want, I could setup a debug session to find out. I could also apply the changes to the 8.5.3 source and run the test again.

About the correction:
Basically, it's not a good idea to make system or LIBC assumptions of the _MSC_VER define. This will only tell the version of the compiler. In fact, you cannot even be sure of that, because it's also defined by the Intel compiler and by Pelles C compiler. But it's common in open source. The normally undefined MSC __STC__ define have special meaning as a basic fallback option to disable C extensions, quite different from gcc. I would say, don't apply my correction - move all target specific defines to configure.

cheers
Jerker

Logged In: YES 
user_id=80530
Originator: NO


Thanks for following up.

Can you explain, or point to an
explanation of why that difference
makes a difference?

File Added - 284105: tcl_tests.txt

Logged In: YES 
user_id=1499688
Originator: YES

I compiled and run tests for tcl 8.5.3
The new shell output is uploaded.
Only 1 correction made:
tclInt.h(3770)
- #ifdef _MSC_VER
+ #if defined(_MSC_VER) && !defined(__STDC__)

_MSC_VER is defined but is using undecorated functions (POSIX).
Shouldn't this be moved to target specifics/configure instead?

Now the integer conversion errors are gone. 
As they were my biggest concern, I'm quite happy with current compile as is.

Thanks Jerker


File Added: tcl_tests.txt

Logged In: YES 
user_id=80530
Originator: NO


I suspect something is wrong with
the TclFormatInt() macro #define-d
on line 3633 of tclInt.h:

#define TclFormatInt(buf, n)            sprintf((buf), "%ld", (long)(n))

but your testing indicates that
sprintf() is ok.

Logged In: YES 
user_id=1499688
Originator: YES

$ cc -o tcl_check.cc tcl_check.c
$ ./tcl_check.cc
Result is -559038737
$ icc -o tcl_check.icc tcl_check.c
$ ./tcl_check.icc
Result is -559038737
$ gcc -o tcl_check.gcc tcl_check.c
$ ./tcl_check.gcc
Result is -559038737
$

Comment:
cc and icc are 64bit, gcc is 32bit (no 64bit currently available).
Since both 64bit compilers (MS and Intel compiler) are built for LLP64, a tool l2ll is run during compilation on preprocessed source files and convert long types to long long. These preprocessed files are the ones that are actually compiled. So, this behaviour could be a system specific feature that is different.

sizeof(int) is 4

Which C-function is doing the work?

Logged In: YES 
user_id=80530
Originator: NO


I suppose the symptoms are also
consistent with a complier that
uses a 64-bit int type.  Can you
check and report the value of
sizeof(int) ?

Logged In: YES 
user_id=80530
Originator: NO


Please compile and run this test program
in the same environment:

#include <stdio.h>
int main (int argc, char **argv) {
    int x = 0xdeadbeef;
    char buf[100];
    sprintf(buf, "%ld", (long)x);
    fprintf(stdout, "Result is %s\n", buf);
}

The correct output ought to be:
Result is -559038737

If you see this output instead:
Result is 3735928559

...then something is, um, surprising
about your C library's conception of
casting from int to long, or its
sprintf(), or both.

Logged In: YES 
user_id=1499688
Originator: YES

It may be good to add:
Interix default stack size: 0x400000

The stack is automatically checked if more then 0x4000 is used - _chkstk().
MS GS support is compiled in.

Was the patch 746378 never applied, or has the code changed since then?

File Added - 283570: test_result.txt