From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15416 invoked by alias); 15 Nov 2013 23:20:23 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 15389 invoked by uid 89); 15 Nov 2013 23:20:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.0 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,RDNS_NONE autolearn=no version=3.3.2 X-HELO: asp.reflexion.net Received: from Unknown (HELO asp.reflexion.net) (69.84.129.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 15 Nov 2013 23:19:17 +0000 Received: (qmail 10075 invoked from network); 15 Nov 2013 23:19:09 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 15 Nov 2013 23:19:09 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.10.2) with SMTP; Fri, 15 Nov 2013 18:19:09 -0500 (EST) Received: (qmail 19921 invoked from network); 15 Nov 2013 23:19:09 -0000 Received: from unknown (HELO exchange.amli-denton.COM) (68.191.223.106) by 0 (rfx-qmail) with (AES128-SHA encrypted) SMTP; 15 Nov 2013 23:19:09 -0000 Received: from APPA-MAIL-S02.appa.com ([fe80::4d83:1136:c054:f8af]) by APPA-MAIL-S02.appa.com ([fe80::4d83:1136:c054:f8af%12]) with mapi; Fri, 15 Nov 2013 17:16:52 -0600 From: David Gressett To: "gcc-help@gcc.gnu.org" Date: Fri, 15 Nov 2013 23:20:00 -0000 Subject: A problem with the Ada.Calendar runtime package as implemented by the MinGW project Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg00108.txt.bz2 I have identified a problem with the GCC Ada runtime Ada.Calendar=20 package as implemented by the MinGW project in its binary=20 distribution, which is a 32-bit compiler suite for the Microsoft=20 Windows platform. I have identified a solution to the problem, but I need some information so that I can build a patch for the problem=20 that will be suitable for submission to the GCC developers. =20 The problem is that the time functions in the Ada.Calendar package,=20 such as Clock and Time_Of return incorrect results. The problem=20 starts with a procedure call in the Ada source code of the Ada.Calendar package. =20 This is the definition of that procedure in Ada source code: =20 type time_t is range -(2 ** (Standard'Address_Size - Integer'(1))) .. +(2 ** (Standard'Address_Size - Integer'(1)) - 1); type time_t_Pointer is access all time_t; procedure localtime_tzoff (timer : time_t_Pointer; is_historic : int_Pointer; off : long_Pointer); pragma Import (C, localtime_tzoff, "__gnat_localtime_tzoff"); __gnat_localtime_tzoff is implemented in a C file named sysdep.c and starts like this: void __gnat_localtime_tzoff (const time_t *timer, const int *is_historic, long *= off) There is an implicit assumption here that the time_t type=20 defined in the Ada source code and the C time_t are the same size. The latest version of the MinGW C runtime breaks that assumption -=20 it has both 32- and 64-bit time_t types; the 64-bit time_t=20 is the default, but the 32-bit version can be selected by using a=20 #define _USE_32BIT_TIME_T directive. The result of the default is that the Ada procedure call feeds a 32-bit value to the C routine which expects a 64-bit value, with predictably disastrous consequences. There ate two possible quick-and-dirty patches that would fix the problem for the MinGW binary distribution. 1. use #define _USE_32BIT_TIME_T 2. change "const time t *timer" to "const int *timer", with the=20 appropriate patches in the body of the procedure to convert the int value to a time_t value where needed. Neither of these are appropriate for a patch to be submitted to the GCC maintainers - they are not 64-bit clean. I need a bit of information about the philosophy governing=20 patches to the GCC Ada runtime source code. It appears to me that the idea is to confine system-dependent code and patches to the C side in sysdep.c and leave the Ada source code identical=20 for all platforms, so that a proposed patch that modifies the Ada code would be rejected.=20 A confirmation of this philosophy will be useful to me when=20 discussing this issue with the MinGW developers. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21313 invoked by alias); 15 Nov 2013 23:25:58 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 21304 invoked by uid 89); 15 Nov 2013 23:25:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,RDNS_NONE autolearn=no version=3.3.2 X-HELO: asp.reflexion.net Received: from Unknown (HELO asp.reflexion.net) (69.84.129.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 15 Nov 2013 23:25:57 +0000 Received: (qmail 10075 invoked from network); 15 Nov 2013 23:19:09 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 15 Nov 2013 23:19:09 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.10.2) with SMTP; Fri, 15 Nov 2013 18:19:09 -0500 (EST) Received: (qmail 19921 invoked from network); 15 Nov 2013 23:19:09 -0000 Received: from unknown (HELO exchange.amli-denton.COM) (68.191.223.106) by 0 (rfx-qmail) with (AES128-SHA encrypted) SMTP; 15 Nov 2013 23:19:09 -0000 Received: from APPA-MAIL-S02.appa.com ([fe80::4d83:1136:c054:f8af]) by APPA-MAIL-S02.appa.com ([fe80::4d83:1136:c054:f8af%12]) with mapi; Fri, 15 Nov 2013 17:16:52 -0600 From: David Gressett To: "gcc-help@gcc.gnu.org" Date: Sat, 16 Nov 2013 00:16:00 -0000 Subject: A problem with the Ada.Calendar runtime package as implemented by the MinGW project Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg00109.txt.bz2 Message-ID: <20131116001600.bwhj001q57IKLAbdLYVOYAi29e_iNOBAKYW1PKWmXE8@z> I have identified a problem with the GCC Ada runtime Ada.Calendar=20 package as implemented by the MinGW project in its binary=20 distribution, which is a 32-bit compiler suite for the Microsoft=20 Windows platform. I have identified a solution to the problem, but I need some information so that I can build a patch for the problem=20 that will be suitable for submission to the GCC developers. =20 The problem is that the time functions in the Ada.Calendar package,=20 such as Clock and Time_Of return incorrect results. The problem=20 starts with a procedure call in the Ada source code of the Ada.Calendar package. =20 This is the definition of that procedure in Ada source code: =20 type time_t is range -(2 ** (Standard'Address_Size - Integer'(1))) .. +(2 ** (Standard'Address_Size - Integer'(1)) - 1); type time_t_Pointer is access all time_t; procedure localtime_tzoff (timer : time_t_Pointer; is_historic : int_Pointer; off : long_Pointer); pragma Import (C, localtime_tzoff, "__gnat_localtime_tzoff"); __gnat_localtime_tzoff is implemented in a C file named sysdep.c and starts like this: void __gnat_localtime_tzoff (const time_t *timer, const int *is_historic, long *= off) There is an implicit assumption here that the time_t type=20 defined in the Ada source code and the C time_t are the same size. The latest version of the MinGW C runtime breaks that assumption -=20 it has both 32- and 64-bit time_t types; the 64-bit time_t=20 is the default, but the 32-bit version can be selected by using a=20 #define _USE_32BIT_TIME_T directive. The result of the default is that the Ada procedure call feeds a 32-bit value to the C routine which expects a 64-bit value, with predictably disastrous consequences. There ate two possible quick-and-dirty patches that would fix the problem for the MinGW binary distribution. 1. use #define _USE_32BIT_TIME_T 2. change "const time t *timer" to "const int *timer", with the=20 appropriate patches in the body of the procedure to convert the int value to a time_t value where needed. Neither of these are appropriate for a patch to be submitted to the GCC maintainers - they are not 64-bit clean. I need a bit of information about the philosophy governing=20 patches to the GCC Ada runtime source code. It appears to me that the idea is to confine system-dependent code and patches to the C side in sysdep.c and leave the Ada source code identical=20 for all platforms, so that a proposed patch that modifies the Ada code would be rejected.=20 A confirmation of this philosophy will be useful to me when=20 discussing this issue with the MinGW developers.