Bug#823937: gcc -E has __DATE__/__TIME__ as Jan 1 1970 00:00:00
On Tue, May 10, 2016 at 04:32:58PM +0100, James Clarke wrote:
> Package: gcc-5
> Version: 5.3.1-17
> Severity: normal
> Tags: upstream patch
> Control: clone -1 -2
> Control: reassign -2 gcc-6 6.1.1-1
>
> Hi,
> With the SOURCE_DATE_EPOCH patch from upstream, the __DATE__ and
> __TIME__ macros always give Jan 1 1970 00:00:00 when running the
> preprocessor on its own with gcc -E[1]. I believe this is because
> c_lex_with_flags is not called when just preprocessing (no C code needs
> to be lexed), so pfile->source_date_epoch stays initialised to 0, and
> subsequent __DATE__/__TIME__ expansions believe that the timestamp has
> been set to epoch 0. I have attached an alternative implementation of
> gcc-SOURCE_DATE_EPOCH.diff which fixes this, by initialising
> pfile->source_date_epoch inside libcpp when pfile is initially created.
>
> [1] https://paste.debian.net/683081/
Hi,
I notice 5.4.0-1 included a backport of r237001 to fix this, but the
upstream commit introduced a regression fixed in r237408 which *wasn't*
backported to this. Could you please bundle that into the next upload? I
guess it's not especially important now gcc-5 is out of testing, but it
would still be nice to have this fixed.
(The regression introduced is that SOURCE_DATE_EPOCH isn't used when
rnning just the preprocessor [previously it would always act as if it
was 0, but now it always uses the current time] so if you do:
echo __DATE__ | SOURCE_DATE_EPOCH=86400 gcc-5 -E -
you get the current date, not "Jan 2 1970").
Regards,
James
Reply to: