Bug in MinGW gcc 4.8.1 Ada runtime

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in MinGW gcc 4.8.1 Ada runtime

David Gressett
I have found a bug in the Ada runtime library which mangles time and date
information.
 
Most of my development projects use Ada, so the bug is forcing me
to do a downgrade to the previous compiler version.
 
The following program demonstrates the bug:

with Ada.Calendar,
     Ada.Text_IO;
     

use  Ada.Calendar,
     Ada.Text_IO;

procedure BugTest
is
  Date_Test_1: Time;
  Date_Test_2: Time;
 
  YN: Year_Number;
  MN: Month_Number;
  DN: Day_Number;
  SN: Day_Duration;
  ISN: Integer;
 
begin
  Date_Test_1 := Clock;
  Date_Test_2 := Time_Of(2013, 9, 6);
 
  Split(Date_Test_1, YN, MN, DN, SN);
  ISN := Integer(SN);
  Put_Line("Split of Clock date is   Year: " & Integer'Image(YN) &
   ", Month:" & Integer'Image(MN) & ", Day:" & Integer'Image(DN) &
   ", Seconds:" & Integer'Image(ISN));

  Split(Date_Test_2, YN, MN, DN, SN);
  ISN := Integer(SN);
  Put_Line("Split of Time_Of date is Year:" & Integer'Image(YN) &
  ", Month:" & Integer'Image(MN) & ", Day:" & Integer'Image(DN) &
  ", Seconds:" & Integer'Image(ISN));
 
end BugTest;

This program creates two variables of type Time and assigns a date
to them. The first one uses the Clock function to get the current
date and time; the second one gets a date from the Time_Of
function which creates a Time value whn given a year number, month
number, day number, and a numbber-of-seconds-since-midnight number,
which defaults to zero.

Both Time values are then split back into separate year, month, day
and seconds values using the Split procedure. For the second date
value, the results should be the same as the numbers that were
used to create the Time value in the first place.

When the program is compiled with the MinGW Ada 4.8.1 compiler,
the output produces an apparently reasonable set of numbers for the
current date, but fails for the Time value created with the static
date numbers for 9/6/2013; the output line for this is:

Split of Time_Of date is Year: 2013, Month: 9, Day: 2, seconds: 68327

The 4.7.2 compiler produces a program which produces the correct

Split of Time_Of date is Year: 2013, Month: 9, Day: 6, seconds: 0

I have no gcc 4.8.1 Ada compiler for Linux, or any non-MinGW 4.8.1
Windows compiler, so I don't know yet if this is a MinGW-specific
problem, or something from further upstream, but I do want to warn
any Ada users who read this list that they should not upgrade to
MinGW gcc 4.8.1

I will file a bug report in the appropriate place when I can
determine if the bug is a MinGW problem or not.
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

Earnie Boyd
On Sat, Sep 7, 2013 at 4:43 PM, David Gressett wrote:
> I have found a bug in the Ada runtime library which mangles time and date
> information.
>
> Most of my development projects use Ada, so the bug is forcing me
> to do a downgrade to the previous compiler version.

Does the downgrade of the version work correctly?  If so then I
suspect this is an GCC Ada issue.  If not, try downgrading mingwrt and
w32api to see if the regression is resolved.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

David Gressett
> From: Earnie Boyd [mailto:[hidden email]]
> Sent: Sunday, September 08, 2013 6:10 PM
> To: MinGW Users List
> Subject: Re: [Mingw-users] Bug in MinGW gcc 4.8.1 Ada runtime


> On Sat, Sep 7, 2013 at 4:43 PM, David Gressett wrote:
>> I have found a bug in the Ada runtime library which mangles time and date
>> information.
>>
>> Most of my development projects use Ada, so the bug is forcing me
>> to do a downgrade to the previous compiler version.

> Does the downgrade of the version work correctly? If so then I
> suspect this is an GCC Ada issue. If not, try downgrading mingwrt and
> w32api to see if the regression is resolved.

The downgraded 4.7.2 Ada compiler produces a program which works
correctly, with win32api 4.0.0-1 and mingwrt 4.0.0-1.

A 4.8.1 compiler downloaded from the MinGW-builds project also
produces a program which works correctly.

The MinGW 4.8.1 Ada compiler with  mingwrt 3.20-2 and w32api
4.0.0-1 produces a program which does not work correctly.

The MinGW 4.8.1 Ada compiler with  mingwrt 3.20-2 and w32api
3.17-2 produces a program which does not work correctly.

The libgnat version makes no difference at all; indeed, removing
it entirely produces no effect, the program runs without it and
still produces incorrect results with MinGW gcc ada 4.8.1.






------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

Earnie Boyd
On Sun, Sep 8, 2013 at 9:23 PM, David Gressett wrote:

>> From: Earnie Boyd [mailto:[hidden email]]
>> Sent: Sunday, September 08, 2013 6:10 PM
>> To: MinGW Users List
>> Subject: Re: [Mingw-users] Bug in MinGW gcc 4.8.1 Ada runtime
>
>
>> On Sat, Sep 7, 2013 at 4:43 PM, David Gressett wrote:
>>> I have found a bug in the Ada runtime library which mangles time and date
>>> information.
>>>
>>> Most of my development projects use Ada, so the bug is forcing me
>>> to do a downgrade to the previous compiler version.
>
>> Does the downgrade of the version work correctly? If so then I
>> suspect this is an GCC Ada issue. If not, try downgrading mingwrt and
>> w32api to see if the regression is resolved.
>
> The downgraded 4.7.2 Ada compiler produces a program which works
> correctly, with win32api 4.0.0-1 and mingwrt 4.0.0-1.
>
> A 4.8.1 compiler downloaded from the MinGW-builds project also
> produces a program which works correctly.
>
> The MinGW 4.8.1 Ada compiler with  mingwrt 3.20-2 and w32api
> 4.0.0-1 produces a program which does not work correctly.
>
> The MinGW 4.8.1 Ada compiler with  mingwrt 3.20-2 and w32api
> 3.17-2 produces a program which does not work correctly.
>
> The libgnat version makes no difference at all; indeed, removing
> it entirely produces no effect, the program runs without it and
> still produces incorrect results with MinGW gcc ada 4.8.1.

David, you should use the http://gcc.gnu.org/bugs.html database to
search and report the issue.  There is nothing we can do about the
issue from here.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

David Gressett

> From: Earnie Boyd [mailto:[hidden email]]
> Sent: Monday, September 09, 2013 5:47 PM
> To: MinGW Users List
> Subject: Re: [Mingw-users] Bug in MinGW gcc 4.8.1 Ada runtime

... snip ...

>>> On Sat, Sep 7, 2013 at 4:43 PM, David Gressett wrote:
>>>> I have found a bug in the Ada runtime library which mangles time and date
>>>> information.
>>>>
>>>> Most of my development projects use Ada, so the bug is forcing me
>>>> to do a downgrade to the previous compiler version.
>>
>>> Does the downgrade of the version work correctly? If so then I
>>> suspect this is an GCC Ada issue. If not, try downgrading mingwrt and
>>> w32api to see if the regression is resolved.
>>
>> The downgraded 4.7.2 Ada compiler produces a program which works
>> correctly, with win32api 4.0.0-1 and mingwrt 4.0.0-1.
>>
>> A 4.8.1 compiler downloaded from the MinGW-builds project also
>> produces a program which works correctly.
>>
>> The MinGW 4.8.1 Ada compiler with mingwrt 3.20-2 and w32api
>> 4.0.0-1 produces a program which does not work correctly.
>>
>> The MinGW 4.8.1 Ada compiler with mingwrt 3.20-2 and w32api
>> 3.17-2 produces a program which does not work correctly.
>>
>> The libgnat version makes no difference at all; indeed, removing
>> it entirely produces no effect, the program runs without it and
>> still produces incorrect results with MinGW gcc ada 4.8.1.

> David, you should use the http://gcc.gnu.org/bugs.html database to
> search and report the issue. There is nothing we can do about the
> issue from here.

I have now done further research on this problem, and I do not believe that
The problem is with the upstream gcc. I have constructed a test program
which does three tests:

1. It uses the Ada.Calendar package to create a time object using a static
date - Sep 16, 2013. The time object is then cast into a 64-bit integer and
displayed. The date is then split back into the component parts and the
parts are displayed. The parts should match the ones that were used to
create the time object. This part of the test uses the calendar package
that is part of the Ada runtime.

2. The second test is the same as the first, but the calendar package that
I used  is extracted from the 4.7.2 MinGW compiler source and renamed so
that I can use it in the same program as the original package used in Part
1. (This also solves other naming problems.) I also had to comment out an
export pragma to avoid a linking problem.

3. The third test is like the second, but it uses the calendar package from
the MinGW 4.8.1 compiler source, with similar changes.

The test program was built with my downgraded 4.7.2 compiler on my main
development computer, a Windows 7 system. With this compiler, all three tests
produce the same correct result:

Testing the Ada.Calendar package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4300974000000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 16, Seconds: 0

Testing the 4.7.2 Calendartest package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4300974000000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 16, Seconds: 0

Testing the 4.8.1 Calendartest package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4300974000000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 16, Seconds: 0

I have the 4.8.1 compiler installed on a Windows XP system. I have compiled
the test program with both the 4.8.1-2 and 4.8.1-3 compilers, with
interesting results.

On the XP computer, the 4.8.1-2-compiled program consistently produces this
result when run repeatedly:

Testing the Ada.Calendar package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4301251273000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 12, Seconds: 68327

Testing the 4.7.2 Calendartest package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4300974000000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 16, Seconds: 0

Testing the 4.8.1 Calendartest package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4300970400000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 19, Seconds: 21673

On the XP computer, the 4.8.1-3-compiled program consistently produces this
result when run repeatedly:

Testing the Ada.Calendar package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4301251273000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 12, Seconds: 68327

Testing the 4.7.2 Calendartest package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4300974000000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 16, Seconds: 0

Testing the 4.8.1 Calendartest package.
Calling Time_Of (2013, 9, 16)
Time (I64):-4301251273000000000
Split of Time_Of date is Year:  2013, Month: 9, Day: 16, Seconds: 0

Furthermore, the size of the binary executable produced by the 4.8.1-2
and the 4.8.1-3 compilers are not the same.

I also used another Windows gcc 4.8.1 compiler to build the test program on
the XP computer. This was the the 32-bit version of gcc 4.8.1 from the
mingw-builds Sourceforge project. The results were identical to the results
produced by the MinGW 4.7.2 compiler.

At this point, it seems clear to me that there is something wrong with the
MinGW 4.8.1 Ada compiler or runtime, or both, and that it is very unlikely
to be a problem with the upstream gcc.

(I also tested the Mingw 4.8.1-2 executable on the windows 7 development
computer an found that the results of the third test can vary from run to
run.)





------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

Earnie Boyd
On Thu, Sep 26, 2013 at 9:11 PM, David Gressett wrote:
>
> I have now done further research on this problem, and I do not believe that
> The problem is with the upstream gcc. I have constructed a test program
> which does three tests:
>

I've never attempted Ada so I have not idea of what the issue could
be.  However, try defining _USE_32BIT_TIME_T before including the
headers to see if it matters to the end result.  If it does, then help
debug the header code.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

David Gressett
> I've never attempted Ada so I have not idea of what the issue could
> be. However, try defining _USE_32BIT_TIME_T before including the
> headers to see if it matters to the end result. If it does, then help
> debug the header code.

> --
> Earnie

That seems to solve the problem. In the compiler source that I downloaded
the offender is the function __gnat_localtime_tzoff in the file  
gcc-4.8.1-2-mingw32-src\gcc-4.8.1\gcc\ada\sysdep.c

Here are two simple test programs that you can use to test a fix:

Put this one in a file named bugtest.adb - the file name without the extension
.adb must be a case-insensitive match for the procedure name. Build it with
the command line

gnatmake bugtest

It displays the current date and a static date which I have set to match
today's date. If you modify the static date to match the day thsat you
run the test, the only difference between the two displays will be
the number of seconds since midnight.
--------------------------------
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;
  Test_Date_2 := Time_Of(2013, 9, 27);

  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;

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

Here's another one which displays the current date in
finer detail.

-----------------------------------
with Ada.Calendar,
     Ada.Text_IO;

use  Ada.Calendar,
     Ada.Text_IO;

with GNAT.Calendar;

use  GNAT.Calendar;

procedure BugTest2
is

  Test_Date_1: Time;

  YN: Year_number;
  MN: Month_Number;
  DN: Day_Number;
  HN: Hour_Number;
  MiN: Minute_Number;
  SN: Second_Number;
  SSN: Second_Duration;


begin
  Test_Date_1 := Clock;
 
  Split(Test_Date_1, YN, MN, DN, HN, MiN, SN, SSN);
  Put("Year:" & Integer'Image(YN));
  Put(", Month:" & Integer'Image(MN));
  Put(", Day:" & Integer'Image(DN));
  Put(", Hour:" & Integer'Image(HN));
  Put(", Minute:" & Integer'Image(MiN));
  Put(", Seconds:" & Integer'Image(SN));
  Put_Line(", Milliseconds:" & Integer'Image(Integer(1000.0 * Float(SSN))));

end BugTest2;

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

David Gressett
>> I've never attempted Ada so I have not idea of what the issue could
>> be. However, try defining _USE_32BIT_TIME_T before including the
>> headers to see if it matters to the end result. If it does, then help
>> debug the header code.

>> --
>> Earnie

> That seems to solve the problem. In the compiler source that I downloaded
> the offender is the function __gnat_localtime_tzoff in the file
> gcc-4.8.1-2-mingw32-src\gcc-4.8.1\gcc\ada\sysdep.c

... sample program source snipped ...

Some additional comments:
My program that demonstrated that _USE_32BIT_TIME_T solved the problem
was a proof-of-principle demonstration; the headers involved here are used
when the Ada part of the gcc compiler is built; more specifically, when
the Ada runtime library is built. The offending C source code in sysdep.c
is baked into the runtime, and there is nothing that I can do to fix that
without a new compiler build that generates an Ada runtime library with
the fix in it.

This raises the question of where this should be fixed. I don't know
enough about how the MinGW compiler is built to know if it is easy to push
such a definition into the build.

So, my question is, should I do a bug report at the MinGW project level,
or should I try to kick it upstairs and file a bug report with the gcc GHQ?




------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

Earnie Boyd
On Wed, Oct 2, 2013 at 6:23 PM, David Gressett wrote:

>>> I've never attempted Ada so I have not idea of what the issue could
>>> be. However, try defining _USE_32BIT_TIME_T before including the
>>> headers to see if it matters to the end result. If it does, then help
>>> debug the header code.
>
>>> --
>>> Earnie
>
>> That seems to solve the problem. In the compiler source that I downloaded
>> the offender is the function __gnat_localtime_tzoff in the file
>> gcc-4.8.1-2-mingw32-src\gcc-4.8.1\gcc\ada\sysdep.c
>
> ... sample program source snipped ...
>
> Some additional comments:
> My program that demonstrated that _USE_32BIT_TIME_T solved the problem
> was a proof-of-principle demonstration; the headers involved here are used
> when the Ada part of the gcc compiler is built; more specifically, when
> the Ada runtime library is built. The offending C source code in sysdep.c
> is baked into the runtime, and there is nothing that I can do to fix that
> without a new compiler build that generates an Ada runtime library with
> the fix in it.
>
> This raises the question of where this should be fixed. I don't know
> enough about how the MinGW compiler is built to know if it is easy to push
> such a definition into the build.
>
> So, my question is, should I do a bug report at the MinGW project level,
> or should I try to kick it upstairs and file a bug report with the gcc GHQ?

For now, create it on the MinGW project and I'll try a new release by
defining the macro during the build process as well as add a -s to
LDFLAGS since people have been complaining about the executable sizes.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Bug in MinGW gcc 4.8.1 Ada runtime

David Gressett
... snip ...
>> So, my question is, should I do a bug report at the MinGW project level,
>> or should I try to kick it upstairs and file a bug report with the gcc GHQ?

> For now, create it on the MinGW project and I'll try a new release by
> defining the macro during the build process as well as add a -s to
> LDFLAGS since people have been complaining about the executable sizes.

The bug report is now done. I included a compilable and short program
which demonstrates the bug. I did not include a program which
demonstrates that the fix works because it contains two complete
copies of the Ada.Calendar runtime package, and is therefore rather
large.

The report does, however, identify the C file that needs to be patched
with _USE_32BIT_TIME_T, so it should be enough to get the job done.

I won't be surprised if other bugs appear after this one is fixed,
but I don't think that it is a productive use of time to look for
them until it is fixed.



------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe