X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
Subject: Re: gcc-8.1.0 packages for testing
To: djgpp-workers AT delorie DOT com
References: <0244cff9-6176-8aec-bbc2-6fc49602c295 AT iki DOT fi>
 <CAA-ihx_a2k3V4w5s=7EZG6pXEjnoTZaiKi-_13kV1txLwxcrig AT mail DOT gmail DOT com>
 <48be2fc5-3ecb-c324-87a9-bdb09d72b78a AT iki DOT fi>
From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp-workers AT delorie DOT com]" <djgpp-workers AT delorie DOT com>
Message-ID: <f6cd4e6d-3df6-6f7a-222b-c7266ba6009c@iki.fi>
Date: Mon, 14 May 2018 21:24:47 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <48be2fc5-3ecb-c324-87a9-bdb09d72b78a@iki.fi>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 05/13/2018 11:09 AM, Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp-workers AT delorie DOT com] wrote:
> On 05/11/2018 03:54 AM, Rugxulo (rugxulo AT gmail DOT com) [via djgpp-workers AT delorie DOT com] wrote:
>>
>> __DATE__ is still wrong (says 2106) but otherwise seems to work okay.
> Confirmed. Booth __DATE__ and __TIME__ correspond to time_t value 0xFFFFFFFF
>
> Only happens with native compiler not cross-compiler (only checked cross-compiler in ArchLinux).
> Unfortunately gdb-7.11 "likes" to run out of memory when trying to debug cc1.exe (not immediately 
> but
> soon enough to prevent getting any useful results)
Linux version of GDB also thinks for some time at the same place where DJGPP port ran out of 
memory. I guess much of resources are needed also on Linux. Not a problem of course with 64GB of 
available memory on 64 bit system.

>
> I guess I should debug cc1 under Linux to see why it works there. From the first impression it 
> should not:
> 1) environment variable SOURCE_DATE_EPOCH not defined
> 2) 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libcpp/macro.c;h=776af7bd00eae4f0571f61c36ceaa1a276c256d3;hb=af8bbdf198a7cd619efd7c9a7aef2f86d5590aae 
> (code beginning from line 500)
> 3) 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-common.c;h=7e6905e791e27a4035c389476862a76eb270fd0c;hb=af8bbdf198a7cd619efd7c9a7aef2f86d5590aae 
> (procedure cb_get_source_date_epoch) cb_get_source_date_epoch() returns (time_t)-1 due to 1). it 
> is after that converted to struct tm using gmtime()
It is GCC (not DJGPP!) bug as far as I understand:
- time_t is not required to be of signed type but it is for most systems. DJGPP is an exception as 
time_t is unsigned for DJGPP.
- all systems which use some of unsigned integer types for time_t should have the same breakage of 
__DATE__ and __TIME__ as DJGPP (I do not have any other available though for testing)
- all work OK when one of signed integer types are used for time_t (for compiler host not target, 
as result Linux to DJGPP cross-compiler do not have this problem)

It could be fixed rather easily. Fix for DJGPP is not a problem. I should however have to update 
employer disclaimer to FSF before trying to submit fix for GCC (I changed employer in March).

Andris