Re: Confusion with labels as values
On Wed, Jun 19, 2019 at 11:37:52AM -0600, Jeff Law wrote: > On 6/19/19 11:09 AM, Segher Boessenkool wrote: > > On Wed, Jun 19, 2019 at 09:39:01AM -0600, Jeff Law wrote: > >> A label used as a value, but which is not a jump target will have an > >> indeterminate value -- it'll end up somewhere in its containing > >> function, that's all we guarantee in that case. > > > > In gimple it was fine and expected, and expand *did* make a code_label, > > it was just immediately optimised away: > Yea, because it wasn't used as a jump target. That's why it gets turned > into a NOTE_INSN_DELETED_LABEL rather than just deleted. My point was, we could change that. But the more I look at it the worse plan that looks -- it's not as simple as it appears, and for what? :-) Segher
Re: [RFC] zstd as a compression algorithm for LTO
Hello.
As mentioned by Honza, it's using cmake and to be honest I prefer to use a
shared
library than a statically build library. Moreover, it's an optional requirement
and
so that we don't have to include that to contrib/download_prerequisites.
I like the idea of marking of compression algorithm in 'LTO_header'. However,
we do compress the header as well. Proper solution would be to make a new
section .gnu.lto_.header where we'll put:
struct lto_header
{
int16_t major_version;
int16_t minor_version;
};
I don't see a reason why why should have that information in each LTO ELF
section?
In the time being, I've written the code so that I fallback in decompression to
zlib
if ZSTD detects that LTO bytecode was compressed with zlib. On the contrary,
decompression
of zstd with zlib will end with:
lto1: internal compiler error: compressed stream: data error
I'm sending updated version of the patch that can properly detect zstd.
Martin
>From 869b630139676fb740fb5296d68086a8ef7f03ae Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 19 Jun 2019 09:40:35 +0200
Subject: [PATCH 2/2] Add optional support for zstd.
---
gcc/common.opt | 4 +-
gcc/lto-compress.c | 139 ++---
gcc/timevar.def| 4 +-
3 files changed, 122 insertions(+), 25 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index a1544d06824..3b71a36552b 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1888,8 +1888,8 @@ Specify the algorithm to partition symbols and vars at linktime.
; The initial value of -1 comes from Z_DEFAULT_COMPRESSION in zlib.h.
flto-compression-level=
-Common Joined RejectNegative UInteger Var(flag_lto_compression_level) Init(-1) IntegerRange(0, 9)
--flto-compression-level= Use zlib compression level for IL.
+Common Joined RejectNegative UInteger Var(flag_lto_compression_level) Init(-1) IntegerRange(0, 19)
+-flto-compression-level= Use zlib/zstd compression level for IL.
flto-odr-type-merging
Common Ignore
diff --git a/gcc/lto-compress.c b/gcc/lto-compress.c
index 3287178f257..327ff9e07b7 100644
--- a/gcc/lto-compress.c
+++ b/gcc/lto-compress.c
@@ -35,6 +35,10 @@ along with GCC; see the file COPYING3. If not see
#include "lto-compress.h"
#include "timevar.h"
+#ifdef HAVE_ZSTD_H
+#include
+#endif
+
/* Compression stream structure, holds the flush callback and opaque token,
the buffered data, and a note of whether compressing or uncompressing. */
@@ -92,6 +96,95 @@ lto_normalized_zlib_level (void)
return level;
}
+/* Free the buffer and memory associated with STREAM. */
+
+static void
+lto_destroy_compression_stream (struct lto_compression_stream *stream)
+{
+ free (stream->buffer);
+ free (stream);
+}
+
+#ifdef HAVE_ZSTD_H
+/* Return a zstd compression level that zstd will not reject. Normalizes
+ the compression level from the command line flag, clamping non-default
+ values to the appropriate end of their valid range. */
+
+static int
+lto_normalized_zstd_level (void)
+{
+ int level = flag_lto_compression_level;
+
+ if (level != ZSTD_CLEVEL_DEFAULT)
+{
+ if (level < 1)
+ level = 1;
+ else if (level > ZSTD_maxCLevel ())
+ level = ZSTD_maxCLevel ();
+}
+
+ return level;
+}
+
+/* Compress STREAM using ZSTD algorithm. */
+
+static void
+lto_compression_zstd (struct lto_compression_stream *stream)
+{
+ unsigned char *cursor = (unsigned char *) stream->buffer;
+ size_t size = stream->bytes;
+
+ timevar_push (TV_IPA_LTO_COMPRESS);
+ size_t const outbuf_length = ZSTD_compressBound (size);
+ char *outbuf = (char *) xmalloc (outbuf_length);
+
+ size_t const csize = ZSTD_compress (outbuf, outbuf_length, cursor, size,
+ lto_normalized_zstd_level ());
+
+ if (ZSTD_isError (csize))
+internal_error ("compressed stream: %s", ZSTD_getErrorName (csize));
+
+ stream->callback (outbuf, csize, NULL);
+
+ lto_destroy_compression_stream (stream);
+ free (outbuf);
+ timevar_pop (TV_IPA_LTO_COMPRESS);
+}
+
+/* Uncompress STREAM using ZSTD algorithm. */
+
+static bool
+lto_uncompression_zstd (struct lto_compression_stream *stream)
+{
+ unsigned char *cursor = (unsigned char *) stream->buffer;
+ size_t size = stream->bytes;
+
+ timevar_push (TV_IPA_LTO_DECOMPRESS);
+ unsigned long long const rsize = ZSTD_getFrameContentSize (cursor, size);
+ if (rsize == ZSTD_CONTENTSIZE_ERROR)
+{
+ /* The content is probably using zlib. */
+ return false;
+}
+ else if (rsize == ZSTD_CONTENTSIZE_UNKNOWN)
+internal_error ("original size unknown");
+
+ char *outbuf = (char *) xmalloc (rsize);
+ size_t const dsize = ZSTD_decompress (outbuf, rsize, cursor, size);
+
+ if (ZSTD_isError (dsize))
+internal_error ("decompressed stream: %s", ZSTD_getErrorName (dsize));
+
+ stream->callback (outbuf, dsize, stream->opaque);
+
+ lto_destroy_compression_stream (stream);
+ free (outbuf);
+ timevar_pop (TV_IPA_LTO_DECOMPRESS);
+ return true;
+}
+
+#endif
+
/* Create a new compression
Re: gcc: -ftest-coverage and -auxbase
On 6/19/19 7:11 PM, david.tay...@dell.com wrote: > Thanks for the patch. Standalone it is not sufficient. Combined > with the other two changes that have been discussed -- Why is that not sufficient? If you build from top-level and you have .o files that overwrite each other, then you can set -fprofile-note-dir=/tmp/my-unique-folder And you'll not overwrite .gcno files. Martin
Re: [RFC] zstd as a compression algorithm for LTO
On Wed, Jun 19, 2019 at 09:29:54PM +0200, Jan Hubicka wrote: > > > > At least allow it to be built as part of the normal build like GMP, > > etc. are done. > > And include it in downloading using contrib/download_prerequisites > > like the libraries are done. > > Anoying detail is that zstd builds with cmake, not autotools It looks like it would be pretty trivial to integrate into a real build system though. OTOH, how well has this been tested, then? On different platforms, etc.? Segher
Re: [RFC] zstd as a compression algorithm for LTO
Am 20.06.19 um 11:07 schrieb Martin Liška: On the contrary, decompression of zstd with zlib will end with: lto1: internal compiler error: compressed stream: data error Sogenerating object files on one system and trying to read them on another system which does not happen to have a particular library installed would lead to failure? If that's the case, I am not sure that this is a good way of handling things.
Re: [RFC] zstd as a compression algorithm for LTO
On 6/20/19 12:58 PM, Thomas Koenig wrote: > Am 20.06.19 um 11:07 schrieb Martin Liška: >> On the contrary, decompression >> of zstd with zlib will end with: >> lto1: internal compiler error: compressed stream: data error > > Sogenerating object files on one system and trying to read them > on another system which does not happen to have a particular > library installed would lead to failure? If that's the case, > I am not sure that this is a good way of handling things. Yes, but LTO bytecode is not supposed to be a distributable format. Martin
Re: [RFC] zstd as a compression algorithm for LTO
On 6/20/19 12:46 PM, Segher Boessenkool wrote: > OTOH, how well has this been tested, then? On different platforms, etc.? Dunno. The algorithm is quite new (4 years), but as it's becoming more popular. So I would expect coverage would be quite good. Maybe Nathan can comment on this? Martin
Re: [RFC] zstd as a compression algorithm for LTO
> On 6/20/19 12:58 PM, Thomas Koenig wrote: > > Am 20.06.19 um 11:07 schrieb Martin Liška: > >> On the contrary, decompression > >> of zstd with zlib will end with: > >> lto1: internal compiler error: compressed stream: data error > > > > Sogenerating object files on one system and trying to read them > > on another system which does not happen to have a particular > > library installed would lead to failure? If that's the case, > > I am not sure that this is a good way of handling things. > > Yes, but LTO bytecode is not supposed to be a distributable format. In longer term it should be. We ought to make it host independent and stable at least within major releases. I guess it is still OK to make zstd enabled host build require zstd enabled gcc elsewhere. Just the error message should be more informative which I think is not hard to do - both zstd and zlip should have recognizable header. Other option is to put this into some common place per file. Honza > > Martin
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge wrote: > > Hi! > > On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely > wrote: > > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely wrote: > > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge > > > wrote: > > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely > > > > wrote: > > > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge > > > > > wrote: > > > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't > > > > > > correspond to > > > > > > the actual GCC 9.1 release. The GCC 9.1 release (as per > > > > > > 'gcc-9.1.0.tar' > > > > > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > > > > > > r272156) > > > > > > > > (Eh, at the end of that 'svn co [...]', it printed that it "Checked out > > > > revision 272156", but the GCC 9.1 release actually is r270840, and > > > > r272156 is GCC trunk from a moment ago.) > > > > > > > > > > would correspond to Git commit > > > > > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and > > > > > > version > > > > > > files for release", but the Git 'gcc-9_1_0-release' tag points one > > > > > > commit > > > > > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a > > > > > > "BASE-VER: > > > > > > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is > > > > > > indeed the only difference.) > > > > > > > > > > That's probably my fault, I think I created the tag. > > > > > > > > > > > The Git tag can't be corrected now (would it make sense to push a > > > > > > Git > > > > > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to > > > > > > get it > > > > > > into the mighty Internet archives; may this note help others who > > > > > > stumble > > > > > > over the same thing. > > > > > > > > > > Can't we just delete the tag and add it at the right commit? > > > > > > > > I don't think that'll be useful: as far as I remember (but please > > > > correct > > > > me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so > > Right, see the "DISCUSSION" "On Re-tagging" in 'git tag --help'. > > > > I think that's right, but 'git fetch --tags' would update it. > > Sure, but who's running that? ;-) > > (We shall see if the GitHub etc. mirrors will pick up the updated tag > automatically.) > > > > > different clones might then have different 'gcc-9_1_0-release' tags. > > > > > > Which doesn't seem like a problem to me. > > > > > > I could create a local tag with that name for any arbitrary revision. > > > It wouldn't match what's in everybody else's clone, but that's fine. > > > > It seems to me that having the master repo have the correct tag is > > more valuable than everybody having the same tag. > > > > And because, as you say, the difference is just one commit, it's not > > like doing diffs or other commands using the old value of the tag > > would look at a completely wrong branch or completely different > > histories. > > Note that I'm not objecting to re-tagging. (I had just proposed > 'gcc-9_1_0-release-corrected' to make obvious what's going on.) > > Is there sufficient consensus, or who's going to make a decision? After some more discussion on IRC, and with Jakub's approval, I fixed the tag by running this on the server: git update-ref refs/tags/gcc-9_1_0-release 3defceaa1a2987fa90296abfbcc85d7e9ad59684 1f54d412a517f3a4b82f3dd77517842fb4de099a The same command can be run in a clone to update local tags. Running 'git fetch --tags' will give an error if you already have that tag: ! [rejected]gcc-9_1_0-release -> gcc-9_1_0-release (would clobber existing tag)
Re: [RFC] zstd as a compression algorithm for LTO
Hi Martin, LTO bytecode is not supposed to be a distributable format. One of my dreams is to make libgfortran LTO-clean. There is a lot of performance to be gained both in I/O (where a huge number of special cases could be shortcut by LTO, because hardly any program uses them all) and in array intrinsics, where seeing through the array descriptors can also lead to large benefits. This is PR 77278. Once this is achieved, it would make sense to distribute libgfortran.a as a library of fat object files. Regards Thomas
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
Jonathan Wakely writes: > On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge wrote: >> >> Hi! >> >> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely >> wrote: >> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely >> > wrote: >> > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge >> > > wrote: >> > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely >> > > > wrote: >> > > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge >> > > > > wrote: >> > > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't >> > > > > > correspond to >> > > > > > the actual GCC 9.1 release. The GCC 9.1 release (as per >> > > > > > 'gcc-9.1.0.tar' >> > > > > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', >> > > > > > r272156) >> > > > >> > > > (Eh, at the end of that 'svn co [...]', it printed that it "Checked out >> > > > revision 272156", but the GCC 9.1 release actually is r270840, and >> > > > r272156 is GCC trunk from a moment ago.) >> > > > >> > > > > > would correspond to Git commit >> > > > > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and >> > > > > > version >> > > > > > files for release", but the Git 'gcc-9_1_0-release' tag points one >> > > > > > commit >> > > > > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a >> > > > > > "BASE-VER: >> > > > > > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update is >> > > > > > indeed the only difference.) >> > > > > >> > > > > That's probably my fault, I think I created the tag. >> > > > > >> > > > > > The Git tag can't be corrected now (would it make sense to push a >> > > > > > Git >> > > > > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to >> > > > > > get it >> > > > > > into the mighty Internet archives; may this note help others who >> > > > > > stumble >> > > > > > over the same thing. >> > > > > >> > > > > Can't we just delete the tag and add it at the right commit? >> > > > >> > > > I don't think that'll be useful: as far as I remember (but please >> > > > correct >> > > > me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so >> >> Right, see the "DISCUSSION" "On Re-tagging" in 'git tag --help'. >> >> > > I think that's right, but 'git fetch --tags' would update it. >> >> Sure, but who's running that? ;-) >> >> (We shall see if the GitHub etc. mirrors will pick up the updated tag >> automatically.) >> >> > > > different clones might then have different 'gcc-9_1_0-release' tags. >> > > >> > > Which doesn't seem like a problem to me. >> > > >> > > I could create a local tag with that name for any arbitrary revision. >> > > It wouldn't match what's in everybody else's clone, but that's fine. >> > >> > It seems to me that having the master repo have the correct tag is >> > more valuable than everybody having the same tag. >> > >> > And because, as you say, the difference is just one commit, it's not >> > like doing diffs or other commands using the old value of the tag >> > would look at a completely wrong branch or completely different >> > histories. >> >> Note that I'm not objecting to re-tagging. (I had just proposed >> 'gcc-9_1_0-release-corrected' to make obvious what's going on.) >> >> Is there sufficient consensus, or who's going to make a decision? > > After some more discussion on IRC, and with Jakub's approval, I fixed > the tag by running this on the server: > > git update-ref refs/tags/gcc-9_1_0-release > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 > 1f54d412a517f3a4b82f3dd77517842fb4de099a > > The same command can be run in a clone to update local tags. Or `git fetch --tags -f` (not particularly well documented in the git manual, but intuitive; worked for me). -- Vlad > > Running 'git fetch --tags' will give an error if you already have that tag: > > ! [rejected]gcc-9_1_0-release -> gcc-9_1_0-release > (would clobber existing tag)
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
On Thu, 20 Jun 2019 at 13:25, Vladislav Ivanishin wrote: > > Jonathan Wakely writes: > > > On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge > > wrote: > >> > >> Hi! > >> > >> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely > >> wrote: > >> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely > >> > wrote: > >> > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge > >> > > wrote: > >> > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely > >> > > > wrote: > >> > > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge > >> > > > > wrote: > >> > > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't > >> > > > > > correspond to > >> > > > > > the actual GCC 9.1 release. The GCC 9.1 release (as per > >> > > > > > 'gcc-9.1.0.tar' > >> > > > > > as well as > >> > > > > > 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release', > >> > > > > > r272156) > >> > > > > >> > > > (Eh, at the end of that 'svn co [...]', it printed that it "Checked > >> > > > out > >> > > > revision 272156", but the GCC 9.1 release actually is r270840, and > >> > > > r272156 is GCC trunk from a moment ago.) > >> > > > > >> > > > > > would correspond to Git commit > >> > > > > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and > >> > > > > > version > >> > > > > > files for release", but the Git 'gcc-9_1_0-release' tag points > >> > > > > > one commit > >> > > > > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a > >> > > > > > "BASE-VER: > >> > > > > > Set to 9.1.1". (That's not a big problem; the 'BASE-VER' update > >> > > > > > is > >> > > > > > indeed the only difference.) > >> > > > > > >> > > > > That's probably my fault, I think I created the tag. > >> > > > > > >> > > > > > The Git tag can't be corrected now (would it make sense to push > >> > > > > > a Git > >> > > > > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, > >> > > > > > to get it > >> > > > > > into the mighty Internet archives; may this note help others who > >> > > > > > stumble > >> > > > > > over the same thing. > >> > > > > > >> > > > > Can't we just delete the tag and add it at the right commit? > >> > > > > >> > > > I don't think that'll be useful: as far as I remember (but please > >> > > > correct > >> > > > me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so > >> > >> Right, see the "DISCUSSION" "On Re-tagging" in 'git tag --help'. > >> > >> > > I think that's right, but 'git fetch --tags' would update it. > >> > >> Sure, but who's running that? ;-) > >> > >> (We shall see if the GitHub etc. mirrors will pick up the updated tag > >> automatically.) > >> > >> > > > different clones might then have different 'gcc-9_1_0-release' tags. > >> > > > >> > > Which doesn't seem like a problem to me. > >> > > > >> > > I could create a local tag with that name for any arbitrary revision. > >> > > It wouldn't match what's in everybody else's clone, but that's fine. > >> > > >> > It seems to me that having the master repo have the correct tag is > >> > more valuable than everybody having the same tag. > >> > > >> > And because, as you say, the difference is just one commit, it's not > >> > like doing diffs or other commands using the old value of the tag > >> > would look at a completely wrong branch or completely different > >> > histories. > >> > >> Note that I'm not objecting to re-tagging. (I had just proposed > >> 'gcc-9_1_0-release-corrected' to make obvious what's going on.) > >> > >> Is there sufficient consensus, or who's going to make a decision? > > > > After some more discussion on IRC, and with Jakub's approval, I fixed > > the tag by running this on the server: > > > > git update-ref refs/tags/gcc-9_1_0-release > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 > > 1f54d412a517f3a4b82f3dd77517842fb4de099a > > > > The same command can be run in a clone to update local tags. > > Or `git fetch --tags -f` (not particularly well documented in the git > manual, but intuitive; worked for me). Thanks, I meant to check if -f did it, and forgot to. Other people have reported that their clones updated the tag without any problems, so the "would clobber existing tag" error I got might be because I've been creating and removing that tag locally. If you have never done that, and just fetched from gcc.gnu.org, then it might update smoothly without issues. > > > > Running 'git fetch --tags' will give an error if you already have that tag: > > > > ! [rejected]gcc-9_1_0-release -> gcc-9_1_0-release > > (would clobber existing tag)
RE: gcc: -ftest-coverage and -auxbase
Dell Customer Communication - Confidential > From: Martin Liška > Sent: Thursday, June 20, 2019 5:12 AM > To: taylor, david; richard.guent...@gmail.com > Cc: gcc@gcc.gnu.org > Subject: Re: gcc: -ftest-coverage and -auxbase > > On 6/19/19 7:11 PM, david.tay...@dell.com wrote: > > Thanks for the patch. Standalone it is not sufficient. Combined with > > the other two changes that have been discussed -- > > Why is that not sufficient? If you build from top-level and you have .o files > that overwrite each other, then you can set -fprofile-note-dir=/tmp/my- > unique-folder > > And you'll not overwrite .gcno files. > > Martin Right now GCC names the GCNO files '-.gcno'. With your patch they get put into a specified directory. But, unless I am prepared to create over 16,000 directories each to hold just one file (I'm not), it is not sufficient. What I want to do -- unless it is going to create problems -- is to place the notes files alongside the object files. The files foo.o and foo.gcno would be in the same directory.
Re: gcc: -ftest-coverage and -auxbase
Am 20.06.19 um 15:00 schrieb david.tay...@dell.com: Dell Customer Communication - Confidential Can't expect me to read this, then? :-)
Re: gcc: -ftest-coverage and -auxbase
On 6/20/19 3:00 PM, david.tay...@dell.com wrote: > Dell Customer Communication - Confidential > >> From: Martin Liška >> Sent: Thursday, June 20, 2019 5:12 AM >> To: taylor, david; richard.guent...@gmail.com >> Cc: gcc@gcc.gnu.org >> Subject: Re: gcc: -ftest-coverage and -auxbase >> >> On 6/19/19 7:11 PM, david.tay...@dell.com wrote: >>> Thanks for the patch. Standalone it is not sufficient. Combined with >>> the other two changes that have been discussed -- >> >> Why is that not sufficient? If you build from top-level and you have .o files >> that overwrite each other, then you can set -fprofile-note-dir=/tmp/my- >> unique-folder >> >> And you'll not overwrite .gcno files. >> >> Martin > > Right now GCC names the GCNO files '-.gcno'. > > With your patch they get put into a specified directory. But, > unless I am prepared to create over 16,000 directories each to > hold just one file (I'm not), it is not sufficient. > > What I want to do -- unless it is going to create problems -- is > to place the notes files alongside the object files. The files > foo.o and foo.gcno would be in the same directory. > I would recommend that. You can achieve that with -fprofile-note-dir=. Martin
RE: gcc: -ftest-coverage and -auxbase
> Am 20.06.19 um 15:00 schrieb david.tay...@dell.com: > > Dell Customer Communication - Confidential > > Can't expect me to read this, then? :-) Grumble. For every email, even internal ones, we are asked it's 'sensitivity'. I explicitly marked that one as 'external public'. It should not have said 'customer communication - confidential'. David p.s. I hate Outlook.
RE: gcc: -ftest-coverage and -auxbase
> From: Martin Liška > Sent: Thursday, June 20, 2019 9:07 AM > > On 6/20/19 3:00 PM, david.tay...@dell.com wrote: > > > >> From: Martin Liška > >> Sent: Thursday, June 20, 2019 5:12 AM > >> > >> On 6/19/19 7:11 PM, david.tay...@dell.com wrote: > >>> Thanks for the patch. Standalone it is not sufficient. Combined > >>> with the other two changes that have been discussed -- > >> > >> Why is that not sufficient? If you build from top-level and you have > >> .o files that overwrite each other, then you can set > >> -fprofile-note-dir=/tmp/my- unique-folder > >> > >> And you'll not overwrite .gcno files. > >> > >> Martin > > > > Right now GCC names the GCNO files '-.gcno'. > > > > With your patch they get put into a specified directory. But, unless > > I am prepared to create over 16,000 directories each to hold just one > > file (I'm not), it is not sufficient. > > > > What I want to do -- unless it is going to create problems -- is to > > place the notes files alongside the object files. The files foo.o and > > foo.gcno would be in the same directory. > I would recommend that. You can achieve that with -fprofile-note-dir=. But unless some other change is also made, the '-o -' part of our compilation line results in all the notes files having names of '-.gcno'. While I have considered replacing the '-o -' with '-pipe' when doing instrumentation, I am loathe to make the dot c to dot o rule any more complicated -- it is already 30+ lines long. Your patch makes things much better. And for many it would be sufficient. For us, sadly, it is not enough.
Re: gcc: -ftest-coverage and -auxbase
On 6/20/19 3:29 PM, david.tay...@dell.com wrote:
>> From: Martin Liška
>> Sent: Thursday, June 20, 2019 9:07 AM
>>
>> On 6/20/19 3:00 PM, david.tay...@dell.com wrote:
>>>
From: Martin Liška
Sent: Thursday, June 20, 2019 5:12 AM
On 6/19/19 7:11 PM, david.tay...@dell.com wrote:
> Thanks for the patch. Standalone it is not sufficient. Combined
> with the other two changes that have been discussed --
Why is that not sufficient? If you build from top-level and you have
.o files that overwrite each other, then you can set
-fprofile-note-dir=/tmp/my- unique-folder
And you'll not overwrite .gcno files.
Martin
>>>
>>> Right now GCC names the GCNO files '-.gcno'.
>>>
>>> With your patch they get put into a specified directory. But, unless
>>> I am prepared to create over 16,000 directories each to hold just one
>>> file (I'm not), it is not sufficient.
>>>
>>> What I want to do -- unless it is going to create problems -- is to
>>> place the notes files alongside the object files. The files foo.o and
>>> foo.gcno would be in the same directory.
>
>> I would recommend that. You can achieve that with -fprofile-note-dir=.
>
> But unless some other change is also made, the '-o -' part of our
> compilation line results in all the notes files having names of
> '-.gcno'. While I have considered replacing the '-o -' with '-pipe'
> when doing instrumentation, I am loathe to make the dot c to
> dot o rule any more complicated -- it is already 30+ lines long.
>
> Your patch makes things much better. And for many it would be sufficient.
> For us, sadly, it is not enough.
>
I see. What about the following patch:
$ ./gcc/xgcc -Bgcc /tmp/main.c --coverage -fprofile-note=/tmp/main.gcno
$ ls -l /tmp/main.gcno
-rw-r--r-- 1 marxin users 428 Jun 20 15:48 /tmp/main.gcno
Martin
>From 30eb7f04c2ee84b5199ea908c8b72cec2163825f Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 20 Jun 2019 15:47:18 +0200
Subject: [PATCH] Add -fprofile-note option.
---
gcc/common.opt | 4
gcc/coverage.c | 11 ---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index a1544d06824..c1b90562b9b 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2096,6 +2096,10 @@ Common Joined RejectNegative Var(profile_data_prefix)
Set the top-level directory for storing the profile data.
The default is 'pwd'.
+fprofile-note=
+Common Joined RejectNegative Var(profile_note_location)
+Select the name for storing the profile note file.
+
fprofile-correction
Common Report Var(flag_profile_correction)
Enable correction of flow inconsistent profile data input.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 1ffefd5f482..960ff7ee86a 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1255,9 +1255,14 @@ coverage_init (const char *filename)
/* Name of bbg file. */
if (flag_test_coverage && !flag_compare_debug)
{
- bbg_file_name = XNEWVEC (char, len + strlen (GCOV_NOTE_SUFFIX) + 1);
- memcpy (bbg_file_name, filename, len);
- strcpy (bbg_file_name + len, GCOV_NOTE_SUFFIX);
+ if (profile_note_location)
+ bbg_file_name = xstrdup (profile_note_location);
+ else
+ {
+ bbg_file_name = XNEWVEC (char, len + strlen (GCOV_NOTE_SUFFIX) + 1);
+ memcpy (bbg_file_name, filename, len);
+ strcpy (bbg_file_name + len, GCOV_NOTE_SUFFIX);
+ }
if (!gcov_open (bbg_file_name, -1))
{
--
2.21.0
Dropping support of repo files (tlink)
Hi. In order to not buffer stderr output in LTO mode, I would like to remove support for repo files (tlink). If I'm correctly it's only used by AIX target. Would it be possible to drop that for the future? Is it even used? Thank you, Martin
Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference
On Jun 20 2019, Jonathan Wakely wrote: > Other people have reported that their clones updated the tag without > any problems, so the "would clobber existing tag" error I got might be > because I've been creating and removing that tag locally. You need to have a recent version of git to get that error. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Dropping support of repo files (tlink)
On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote: > > Hi. > > In order to not buffer stderr output in LTO mode, I would like to remove > support for repo files (tlink). If I'm correctly it's only used by AIX > target. Would it be possible to drop that for the future? Is it even > used? AIX currently does not support GCC LTO, but the hope was that GCC would not do anything to specifically inhibit that ability to eventually support that feature. AIX currently needs collect2. I guess that AIX could try to find another mechanism when it adds support. Thanks, David
Re: Dropping support of repo files (tlink)
> On 20 Jun 2019, at 15:21, David Edelsohn wrote: > > On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote: >> >> Hi. >> >> In order to not buffer stderr output in LTO mode, I would like to remove >> support for repo files (tlink). If I'm correctly it's only used by AIX >> target. Would it be possible to drop that for the future? Is it even >> used? > > AIX currently does not support GCC LTO, but the hope was that GCC > would not do anything to specifically inhibit that ability to > eventually support that feature. AIX currently needs collect2. I > guess that AIX could try to find another mechanism when it adds > support. Darwin needs collect2, but does not use the tlink facility. thanks Iain
Re: Dropping support of repo files (tlink)
On 6/20/19 4:21 PM, David Edelsohn wrote: > On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote: >> >> Hi. >> >> In order to not buffer stderr output in LTO mode, I would like to remove >> support for repo files (tlink). If I'm correctly it's only used by AIX >> target. Would it be possible to drop that for the future? Is it even >> used? > > AIX currently does not support GCC LTO, but the hope was that GCC > would not do anything to specifically inhibit that ability to > eventually support that feature. AIX currently needs collect2. I > guess that AIX could try to find another mechanism when it adds > support. Yes, I'm fine with collect2. I'm more precisely asking about read_report_files that lives in tlink.c. If I understand correctly, it's parsing output of linker and tries to find template implementations in a .rpo files that live on a disk. That's a legacy functionality that I'm targeting to remove. Thanks, Martin > > Thanks, David >
RE: gcc: -ftest-coverage and -auxbase
Dell Customer Communication - Confidential > From: Martin Liška > Sent: Thursday, June 20, 2019 9:49 AM > I see. What about the following patch: > > $ ./gcc/xgcc -Bgcc /tmp/main.c --coverage > -fprofile-note=/tmp/main.gcno $ ls -l /tmp/main.gcno > -rw-r--r-- 1 marxin users 428 Jun 20 15:48 /tmp/main.gcno I haven't tried it. But, looking it over it looks like it will do everything that I need. I'll try it and let you know. Thanks.
Re: [RFC] zstd as a compression algorithm for LTO
Any use of a host library should come with associated configure options to specify header and library paths for that library (and documentation for those options). (See existing --with-gmp*, --with-isl* etc. options.) -- Joseph S. Myers jos...@codesourcery.com
Re: Dropping support of repo files (tlink)
On June 20, 2019 5:09:55 PM GMT+02:00, "Martin Liška" wrote: >On 6/20/19 4:21 PM, David Edelsohn wrote: >> On Thu, Jun 20, 2019 at 10:05 AM Martin Liška wrote: >>> >>> Hi. >>> >>> In order to not buffer stderr output in LTO mode, I would like to >remove >>> support for repo files (tlink). If I'm correctly it's only used by >AIX >>> target. Would it be possible to drop that for the future? Is it even >>> used? >> >> AIX currently does not support GCC LTO, but the hope was that GCC >> would not do anything to specifically inhibit that ability to >> eventually support that feature. AIX currently needs collect2. I >> guess that AIX could try to find another mechanism when it adds >> support. > >Yes, I'm fine with collect2. I'm more precisely asking about >read_report_files >that lives in tlink.c. If I understand correctly, it's parsing output >of linker >and tries to find template implementations in a .rpo files that live on >a disk. >That's a legacy functionality that I'm targeting to remove. IIRC -frepo also works on Linux? Richard. >Thanks, >Martin > >> >> Thanks, David >>
gcc-7-20190620 is now available
Snapshot gcc-7-20190620 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190620/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 272526 You'll find: gcc-7-20190620.tar.xzComplete GCC SHA256=30e86a5f9e329b48f50919eff5cd2d24e3fafdef08bd6c01f196134a400a2099 SHA1=93c62d4b891381dbdfbea8cdbc82d6fa136cc9b7 Diffs from 7-20190613 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
