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 15:14:20 +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> <20160428103506 dot GM26501 at tucnak dot zalov dot cz> <57220BC2 dot 7080901 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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__.
Jakub