From patchwork Mon Jun 1 15:06:31 2020
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Gerald Pfeifer
X-Patchwork-Id: 1301789
Return-Path:
X-Original-To: incoming@patchwork.ozlabs.org
Delivered-To: patchwork-incoming@bilbo.ozlabs.org
Authentication-Results: ozlabs.org;
spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org
(client-ip=8.43.85.97; helo=sourceware.org;
envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=)
Authentication-Results: ozlabs.org;
dmarc=none (p=none dis=none) header.from=pfeifer.com
Received: from sourceware.org (server2.sourceware.org [8.43.85.97])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest
SHA256)
(No client certificate requested)
by ozlabs.org (Postfix) with ESMTPS id 49bJRg4ZCQz9sSy
for ; Tue, 2 Jun 2020 01:06:54 +1000 (AEST)
Received: from server2.sourceware.org (localhost [IPv6:::1])
by sourceware.org (Postfix) with ESMTP id 9C9BC3851C09;
Mon, 1 Jun 2020 15:06:51 +0000 (GMT)
X-Original-To: gcc-patches@gcc.gnu.org
Delivered-To: gcc-patches@gcc.gnu.org
Received: from hamza.pair.com (hamza.pair.com [209.68.5.143])
by sourceware.org (Postfix) with ESMTPS id 8503E3851C01;
Mon, 1 Jun 2020 15:06:49 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8503E3851C01
Authentication-Results: sourceware.org;
dmarc=none (p=none dis=none) header.from=pfeifer.com
Authentication-Results: sourceware.org;
spf=pass smtp.mailfrom=gerald@pfeifer.com
Received: from hamza.pair.com (localhost [127.0.0.1])
by hamza.pair.com (Postfix) with ESMTP id 35A0333E10;
Mon, 1 Jun 2020 11:06:49 -0400 (EDT)
Received: from [192.168.1.5] (unknown [77.118.218.145])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by hamza.pair.com (Postfix) with ESMTPSA id 8768933E0C;
Mon, 1 Jun 2020 11:06:48 -0400 (EDT)
Date: Mon, 1 Jun 2020 17:06:31 +0200 (CEST)
From: Gerald Pfeifer
To: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: [committed] libstdc++: Update/streamline Valgrind references
MIME-Version: 1.0
Message-Id: <20200601150649.35A0333E10@hamza.pair.com>
X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00, GIT_PATCH_0,
KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS,
TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: gcc-patches-bounces@gcc.gnu.org
Sender: "Gcc-patches"
Like many sites over the last year(s) valgrind.org has now moved to
https. While there, replace the second of two links in the same vicinity
by a purely textual reference -- easier to maintain, and in particular
also better from a user experience perspective.
Gerald
* doc/xml/faq.xml: Adjust Valgrind reference and remove another.
* doc/html/faq.html: Regenerate.
---
libstdc++-v3/doc/html/faq.html | 4 ++--
libstdc++-v3/doc/xml/faq.xml | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html
index 18407225d7a..967e5f5f348 100644
--- a/libstdc++-v3/doc/html/faq.html
+++ b/libstdc++-v3/doc/html/faq.html
@@ -700,7 +700,7 @@
of a few dozen kilobytes on startup. This pool is used to ensure it's
possible to throw exceptions (such as bad_alloc)
even when malloc is unable to allocate any more memory.
- With some versions of valgrind
+ With some versions of valgrind
this pool will be shown as "still reachable" when the process exits, e.g.
still reachable: 72,704 bytes in 1 blocks.
This memory is not a leak, because it's still in use by libstdc++,
@@ -710,7 +710,7 @@
In the past, a few people reported that the standard containers appear
to leak memory when tested with memory checkers such as
- valgrind.
+ valgrind.
Under some (non-default) configurations the library's allocators keep
free memory in a
pool for later reuse, rather than deallocating it with delete
diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index cf8684e1cea..e419d3c22a0 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -993,7 +993,7 @@
of a few dozen kilobytes on startup. This pool is used to ensure it's
possible to throw exceptions (such as bad_alloc)
even when malloc is unable to allocate any more memory.
- With some versions of valgrind
+ With some versions of valgrind
this pool will be shown as "still reachable" when the process exits, e.g.
still reachable: 72,704 bytes in 1 blocks.
This memory is not a leak, because it's still in use by libstdc++,
@@ -1004,7 +1004,7 @@
In the past, a few people reported that the standard containers appear
to leak memory when tested with memory checkers such as
- valgrind.
+ valgrind.
Under some (non-default) configurations the library's allocators keep
free memory in a
pool for later reuse, rather than deallocating it with delete