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