[Bug libstdc++/59508] std::find could use specialized container's find

["olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Daniel Krügler from comment #1)
> A conforming implementation cannot do that, unless the difference weren't
> observable by the user (modulo the performance difference), i.e. it would
> only be possible for containers that have neither user-defined value types
> nor user-defined allocators.

I don't understand why it would not be possible to do with user defined value
types or user defined allocators.

For example, in the current RB tree implementation each node
(_Rb_tree_node_base) has a field that stores a red/black bit.  It is possible
to use the spare bits to store additional node information whether a node is
the begin () node or end () node.  This will work regardless of the value type
or allocator, since the node type is implementation internal and not visible to
the user.

Could you please elaborate?
>From gcc-bugs-return-437641-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Dec 15 17:47:56 2013
Return-Path: <gcc-bugs-return-437641-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17067 invoked by alias); 15 Dec 2013 17:47:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17035 invoked by uid 48); 15 Dec 2013 17:47:51 -0000
From: "robert-gcc at debian dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/59512] New: Incomplete output files when compiler is killed
Date: Sun, 15 Dec 2013 17:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: robert-gcc at debian dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59512-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01296.txt.bz2
Content-length: 1591

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY512

            Bug ID: 59512
           Summary: Incomplete output files when compiler is killed
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: robert-gcc at debian dot org

Hi

When cc1plus program is killed for example by OOM then the output file (given
by the `-o' option) can be incomplete, which will than result in linker error.
This is especially visible when the `-pipe' option is used.

I can see that clang always first create some temporary file, and then renames
it into the final one:
 strace -efile -f  clang++ a.cpp -pipe -c -o a.o
  [pid 28990] stat64("a.o", {st_mode=S_IFREG|0644, st_sizeq6, ...}) = 0
  [pid 28990] access("a.o", W_OK)         = 0
  [pid 28990] open("/dev/urandom", O_RDONLY) = 3
  [pid 28990] open("a.o-8cc52ce9", O_RDWR|O_CREAT|O_EXCL, 0666) = 3
// skipped some output
  [pid 28990] rename("a.o-8cc52ce9", "a.o") = 0

It would be nice if g++ could implement the same behaviour.

I tried to simulate it in makefiles by using something like `g++ -o $@.tmp &&
mv $@.tmp $@', and it worked pretty well, unless coverage flags
(`-fprofile-arcs -ftest-coverage') were also given, in which case the generated
gcno/gcda files refered to the `.o.tmp' files, which generally broke the
coverage calculations. For that reason I think that it would be best if g++
could handle this `write to temp && rename temp' approach internally.