From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11502 invoked by alias); 28 Apr 2016 18:31:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 10961 invoked by uid 89); 28 Apr 2016 18:31:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=welcome!, buy, tips, learn X-HELO: smtp19.openmailbox.org Received: from smtp19.openmailbox.org (HELO smtp19.openmailbox.org) (62.4.1.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 28 Apr 2016 18:31:14 +0000 Received: by mail2.openmailbox.org (Postfix, from userid 1002) id BC5127C7D2B; Thu, 28 Apr 2016 20:31:11 +0200 (CEST) Date: Thu, 28 Apr 2016 18:31:00 -0000 From: Dhole To: Jakub Jelinek Cc: Bernd Schmidt , Matthias Klose , gcc-patches@gcc.gnu.org Subject: Re: Allow embedded timestamps by C/C++ macros to be set externally (3) Message-ID: <20160428182956.GG21574@panther> References: <571DEE56.6090406@redhat.com> <20160426212803.GB11894@panther> <571FFADB.3080209@redhat.com> <20160427155633.GA21574@panther> <5721D5DC.7060004@ubuntu.com> <20160428100815.GL26501@tucnak.zalov.cz> <5721E68C.20208@redhat.com> <20160428103506.GM26501@tucnak.zalov.cz> <57220BC2.7080901@redhat.com> <20160428131420.GO26501@tucnak.zalov.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LQ77YLfPrO/qF/pM" Content-Disposition: inline In-Reply-To: <20160428131420.GO26501@tucnak.zalov.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg01886.txt.bz2 --LQ77YLfPrO/qF/pM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2642 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 t= ime > > >>sink, so I'm not that worried about it. I think it's likely to be bur= ied way > > >>down in the noise. > > > > > >True, but the noise sums up, and the result is terrible speed of compi= ling > > >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 ha= s the > > >delayed initialization anyway. > >=20 > > Well, it does buy us early (and reliable) error checks against the > > environment variable. >=20 > 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, --=20 Dhole --LQ77YLfPrO/qF/pM Content-Type: application/pgp-signature; name="signature.asc" Content-length: 801 -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJXIlagAAoJEE+kV6GFFMxjcVkQAI7vmf0xUP9v74QNUVayomPt ZpoiuZ7XSEBM6w1bCIayPdS5X8+T6jMcebxUT5kHPbbR4USwkQgkrRIJc+eRRPG5 KM9L1f54/0+liJS/ovi6Kj7k6FfTLfextxjPsLQ7nGyNMc0kM2Dotg9FZSJuS8ww Zv8pTxbEb3WWedAxJ2XD2X00atydTBRDnp59rfnuAZnb0Ar1jj/EyTGaW27eAjpe pjDDRh2g01+14dZ6GLZ80MUZSRlXyoRyOhKVGhEyc+htYX+LJr+2bhRaUE2/+/c6 ChMguc6tf2tDAL05mvVLVJVEHUtWV/F3n4IzEU+AFr8u00czXonBeNmdVLbv/qkA po0yDBdCpZVddyiSpRovmDaeE865gjPJBNEaYErwUxES37Tom/5R582XCqwRmRQI joEkklAHIRZDMEy3wXkHO+3WkVmsefxlXCKPdbBGuebe3MnOdPNhaGbvjDGX3vV8 RmwyMBY7E6ACfnfEqZCfhpAqEmpVWT0jN/m5J9vH+A2qNbJLX8LYIB7DqUd2z+6H SZ9/VHzdf5EaxursR6Qu0CLjmoXqNUgu6in/4HADaDPYVimZsnttfv7QbuN5atUp +foek9T/uJlK1xmeNN1mCQjwPsiPKDZopD0DfrV9MzdF8eS7mb5foT35L5x405gT 69h6dxbrwXgWMFt2n3du =vIE5 -----END PGP SIGNATURE----- --LQ77YLfPrO/qF/pM--