Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2083 Bug in gcc 4.8.1 Ada run-time library

WSL
assigned
Earnie Boyd
ada runtime (1)
Bug
none
Unknown
False
2013-10-05
2013-10-03
David Gressett
No

There is a bug in the Ada.Calendar package of the gcc 4.8.1 MinGW Ada release. it is demonstrated by the following Ada program:

with Ada.Calendar,
Ada.Text_IO;

use Ada.Calendar,
Ada.Text_IO;

procedure BugTest
is
Test_Date_1: Time;
Test_Date_2: Time;
YN: Year_number;
MN: Month_Number;
DN: Day_Number;
SN: Day_Duration;
ISN: Integer;

begin
Test_Date_1 := Clock;

-- Change this to current date in order to
-- compare with Clock-produced date.
Test_Date_2 := Time_Of(2013, 10, 3);

Split(Test_Date_1, YN, MN, DN, SN);
ISN := Integer(SN);
Put("Year:" & Integer'Image(YN));
Put(", Month:" & Integer'Image(MN));
Put(", Day:" & Integer'Image(DN));
Put_Line(", Seconds:" & Integer'Image(ISN));

Split(Test_Date_2, YN, MN, DN, SN);
ISN := Integer(SN);
Put("Year:" & Integer'Image(YN));
Put(", Month:" & Integer'Image(MN));
Put(", Day:" & Integer'Image(DN));
Put_Line(", Seconds:" & Integer'Image(ISN));

end BugTest;

This program can be built with this command line:

gnatmake bugtest

I built this on Windows 7 with the older MinGW gcc 4.7.2 compiler, and then renamed
the executable binary to bugtest-472.exe, then repeated the build on Windows XP
using the newer MinGW gcc 4.8.1 compiler, then renamed the executable binary to bugtest-481.exe. I then copied bugtest-4.8.1.exe to the Windows 7 system and created bugdemo.cmd, with this content:

bugtest-472
bugtest-481

executing this file causes the two executables to run with less than one second of time elapsed between the two executions, so that the display of the two programs should be identical if both are working correctly.

This is the output of a test run on Windows 7:

E:\Ada_Projects\bugdemo>bugtest-472
Year: 2013, Month: 10, Day: 3, Seconds: 50254
Year: 2013, Month: 10, Day: 3, Seconds: 0

E:\Ada_Projects\bugdemo>bugtest-481
Year: 2013, Month: 10, Day: 3, Seconds: 50254
Year: 2013, Month: 9, Day: 29, Seconds: 68327

In this particular case, the first line (which displays the current date and the number of seconds since midnight) is identical for both executables. The date and time data for this line is produced by the Clock function in the Ada.Calendar Ada runtime package, and therefore changes every time the program is run.

The second line of output is produced by the data produced by the Time_OF function. This function is called with constant arguments and should always produce the same results. The 4.7.2-compiled version produces the correct results. The 4.8.1 version does not.

Other possibly relevant information:
The offending bugtest-481.exe was created on a Windows XP SP 3 computer running MinGW gcc 4.8.1:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32
--build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld
--enable-lto --enable-libssp --disable-multilib
--enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions
--with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runtime-libs
--with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld
--with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr=
--with-system-zlib --with-gnu-as --enable-decimal-float=yes
--enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32
--with-libintl-prefix=/mingw
Thread model: win32
gcc version 4.8.1 (GCC)

The binutils version is:

GNU ld (GNU Binutils) 2.23.2

The mingw-w32api version is 4.0.3-1

A much larger test program was used to trace at least part of the problem to a change in the MinGW C runtime. As a result of a request by Earnie Boyd, I tried defining _USE_32BIT_TIME_T in a C routine that I had extracted from the source code from the Ada 4.8.1 runtime library.

In order to test the routine, I had to make a modified version of the Ada.Calendar Ada runtime package which called the modified C routine. The test program used three versions of the Ada Calendar package:

  1. The original package, Ada.Calendar.
  2. A renamed copy, named Calendartest481B, which calls the original, unmodified C function.
  3. A renamed copy, named Calendartest481G, which called the modified C function which was patched with the inclusion of _USE_32BIT_TIME_T

When compiled with the 4.8.1 Ada compiler, the routines in the #1 and #2 packages failed, but
the ones in the #3 packages succeeded. This strongly suggests that the lack of _USE_32BIT_TIME_T when compiling C source in the Ada runtime library is at least part of the problem.

In the compiler source that I downloaded (the 4.8.1-2 version), the offending C routine is __gnat_localtime_tzoff in the file gcc-4.8.1-2-mingw32-src\gcc-4.8.1\gcc\ada\sysdep.c

The Windows-specific time and date routines are in sysdep.c, and that is where _USE_32BIT_TIME_T should be defined.

1 Attachments

Discussion

  • Earnie Boyd
    Earnie Boyd
    2013-10-04

    • status: unread --> assigned
    • assigned_to: Earnie Boyd
     
  • Earnie Boyd
    Earnie Boyd
    2013-10-04

    Interesting conversation regarding 64bit time_t here. I know it is an old one but may have some source pointers.

     
  • Earnie Boyd
    Earnie Boyd
    2013-10-04

    I'm not having any luck with getting the expected result regardless of _USE_32BIT_TIME_T. I even added CFLAGS=-D_USE_32BIT_TIME_T to the configure step of GCC. I still get the incorrect value. I decided to play with the YEAR, MONTH, DAY values passed to Time_Of function and find that it is about 4 days off.

     
  • Earnie Boyd
    Earnie Boyd
    2013-10-04

    looking at gcc/ada/s-win32.ads as compared to the documented declaration for GetSystemTimeAsFileTime(), it has declared the access as Long_Long_Integer and it should be FILETIME which is a record of DWORD dwLowDateTime, DWORD dwHighDateTime and a DWORD is an unsigned long while Long_Long_Integer is a long long data type; which is not the same thing.

     
  • Earnie Boyd
    Earnie Boyd
    2013-10-05

    I also see a lot of changes to s-osprim-mingw.adb related to the Clock. Maybe something there went astray.