[Tcl-bugs] [ tcl-Bugs-2010028 ] TCL 8.5.2 test failures in x86_64 Interix

[SourceForge.net <no...@so...>]

Bugs item #2010028, was opened at 2008-07-03 16:01
Message generated for change (Settings changed) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2010028&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 38. Init - Library - Autoload
Group: obsolete: 8.5.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jerker Bck (jerker_back)
>Assigned to: Kevin B KENNY (kennykb)
Summary: TCL 8.5.2 test failures in x86_64 Interix

Initial Comment:
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).



----------------------------------------------------------------------

Comment By: Jerker Bck (jerker_back)
Date: 2008-07-09 17:00

Message:
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




----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2008-07-09 16:09

Message:
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?

----------------------------------------------------------------------

Comment By: Jerker Bck (jerker_back)
Date: 2008-07-09 08:42

Message:
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

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2008-07-07 22:23

Message:
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.

----------------------------------------------------------------------

Comment By: Jerker Bck (jerker_back)
Date: 2008-07-07 21:02

Message:
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? 



----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2008-07-07 17:38

Message:
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) ?


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2008-07-07 16:37

Message:
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.


----------------------------------------------------------------------

Comment By: Jerker Bck (jerker_back)
Date: 2008-07-04 07:25

Message:
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?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2010028&group_id=10894