#4059 TCL 8.5.2 test failures in x86_64 Interix

obsolete: 8.5.2
open
5
2008-07-21
2008-07-03
No

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).

Discussion

  • Jerker Bäck

    Jerker Bäck - 2008-07-03

    TCL 8.5.2 test shell output

     
  • Jerker Bäck

    Jerker Bäck - 2008-07-04

    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?

     
  • Donal K. Fellows

    • labels: --> 38. Init - Library - Autoload
    • milestone: --> obsolete: 8.5.2
    • assigned_to: nobody --> dgp
     
  • Don Porter

    Don Porter - 2008-07-07

    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.

     
  • Don Porter

    Don Porter - 2008-07-07

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

     
  • Jerker Bäck

    Jerker Bäck - 2008-07-08

    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?

     
  • Don Porter

    Don Porter - 2008-07-08

    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.

     
  • Jerker Bäck

    Jerker Bäck - 2008-07-09

    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

     
  • Jerker Bäck

    Jerker Bäck - 2008-07-09

    TCL 8.5.3 test shell output

     
  • Don Porter

    Don Porter - 2008-07-09

    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?

     
  • Jerker Bäck

    Jerker Bäck - 2008-07-09

    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

     
  • Don Porter

    Don Porter - 2008-07-10
    • assigned_to: dgp --> kennykb
     
  • Kevin B KENNY

    Kevin B KENNY - 2008-07-20
    • assigned_to: kennykb --> dgp
     
  • Kevin B KENNY

    Kevin B KENNY - 2008-07-20

    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.

     
  • Jerker Bäck

    Jerker Bäck - 2008-07-21

    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.

     
  • Don Porter

    Don Porter - 2008-07-21

    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.

     
  • Don Porter

    Don Porter - 2008-07-21
    • assigned_to: dgp --> kennykb
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks