This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Allow embedded timestamps by C/C++ macros to be set externally (3)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: Matthias Klose <doko at ubuntu dot com>, Dhole <dhole at openmailbox dot org>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 28 Apr 2016 12:35:06 +0200
- Subject: Re: Allow embedded timestamps by C/C++ macros to be set externally (3)
- Authentication-results: sourceware.org; auth=none
- References: <20160418122636 dot GR3248 at panther> <571DEE56 dot 6090406 at redhat dot com> <20160426212803 dot GB11894 at panther> <571FFADB dot 3080209 at redhat dot com> <20160427155633 dot GA21574 at panther> <5721D5DC dot 7060004 at ubuntu dot com> <20160428100815 dot GL26501 at tucnak dot zalov dot cz> <5721E68C dot 20208 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Apr 28, 2016 at 12:31:40PM +0200, Bernd Schmidt wrote:
> 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.
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.
Jakub