On 04/28/2016 12:08 PM, Jakub Jelinek wrote:
BTW, I think fatal_error doesn't make sense, it isn't something that is not recoverable, normal error or just a warning would be IMHO more than sufficient. The fallback would be just using current time, i.e. ignoring the env var.
I thought about this, but we also error out for invalid arguments to options, and IMO this case is analogous.
Additionally, I think it is a very bad idea to slow down the initialization for something so rarely used - instead of initializing this always, IMNSHO it should be only initialized when the first __TIME__ macro is expanded, similarly how it only calls time/localtime etc. when the macro is expanded for the first time.
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.
Also, as a follow-up, guess the driver should set this env var for the -fcompare-debug case if not already set, to something that matches the current date, so that __TIME__ macros expands the same in between both compilations, even when they don't compile both in the same second.
This sounds like a good idea. Maybe we could even have the bootstrap include an instance of __TIME__, with the env var set, and use the stage comparison as a test for this feature.
Bernd
