On 16-04-28 15:14:20, Jakub Jelinek wrote: > On Thu, Apr 28, 2016 at 03:10:26PM +0200, Bernd Schmidt wrote: > > On 04/28/2016 12:35 PM, Jakub Jelinek wrote: > > >On Thu, Apr 28, 2016 at 12:31:40PM +0200, Bernd Schmidt wrote: > > >>I really don't see anything in that function that looks like a huge time > > >>sink, so I'm not that worried about it. I think it's likely to be buried > > >>way > > >>down in the noise. > > > > > >True, but the noise sums up, and the result is terrible speed of compiling > > >empty source files, something that e.g. Linux kernel or other packages > > >that have lots of small source files, care about a lot. > > >If initializing it early would buy us anything on code clarity etc., it > > >could be justified, but IMHO it doesn't, the code in libcpp already has the > > >delayed initialization anyway. > > > > Well, it does buy us early (and reliable) error checks against the > > environment variable. > > I'm not sure we really care about the env var unless it actually needs to be > used. If we error only if it is used, people could e.g. use it in another > way, to verify their code doesn't contain any __TIME__ uses, compile with > the env var set to some invalid string and just compile everything with > that, it would diagnose any uses of __TIME__.
There is the Wdate-time flag, that warns on using __DATE__, __TIME__ and __TIMESTAMP__. Although that alone will not make the compilation fail unless it's used with Werror. The reason behind using fatal_error (rather than a warning) when SOURCE_DATE_EPOCH contains an invalid value is due to the SOURCE_DATE_EPOCH specification [1]: SOURCE_DATE_EPOCH (...) If the value is malformed, the build process SHOULD exit with a non-zero error code. And the reason for reading and parsing the env var in gcc/ rather than when the macro is expanded for the first time (in libcpp/) is from a comment by Joseph Myers made the first time I submited this patch [2]. The most clean way to read the env var from gcc/ I found was to do it during the initialization. But if you think this should be done different I'm open to change the implementation. Bernd: I'll see if I can prepare a testcase; first I need to get familiar with the testing framework and learn how to set environment variables in tests. Any tips on that will be really welcome! Also, I'll take a look at the -fcompare-debug, see what's the best way to get the same __TIME__ and __DATE__ with the help of SOURCE_DATE_EPOCH. [1] https://reproducible-builds.org/specs/source-date-epoch/ [2] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02270.html Cheers, -- Dhole
signature.asc
Description: PGP signature
