Re: Allow embedded timestamps by C/C++ macros to be set externally (3)

[Bernd Schmidt <bschmidt@redhat.com>]

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