From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 050D5385E002; Tue, 24 Mar 2020 21:58:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 050D5385E002 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585087126; bh=h2VItkcr3UHIwNyJfZw0c9jDdrJarj0sjrpuRnG29cg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GsqQ91tyaxdh7B0WTjU7KWCozR2XEt5VO1S9Oxf0N0Sv2U8o1xXstaJA0W01XgvU8 FVmRuxYy3vngdFxLEyA5x7jQiY/EqdkQ/Hx4IOYHN0zuI9jsewZmky/yWW+cHa34k8 UuwQrz39y+jaluc3kOF4OcU3SGJgaGouBEEzV4gE= From: "richard-gccbugzilla at metafoo dot co.uk" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/94295] use __builtin_operator_new and __builtin_operator_delete when available Date: Tue, 24 Mar 2020 21:58:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: richard-gccbugzilla at metafoo dot co.uk X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 21:58:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94295 --- Comment #6 from Richard Smith --- (In reply to Marc Glisse from comment #5) > Ah, since you are here, and you appeared as an author of N3664 but not N3= 537 > (precisely when this subtlety happened), could you explain why? It isn't > discussed in the paper, complicates the design, and I cannot think of any > use for this distinction It isn't discussed in the paper because it wasn't part of the original plan= / design, but was added due to committee push-back. People want some guarante= es: * If they write a test for their global 'operator new' (particularly, test= ing failure cases, mallinfo, the effect of configuration parameters on its behavior, ...), that test should still work in the presence of the language change. * A direct function call to a user-defined function should behave as a dir= ect function call to that user-defined function. Even if it has a non-identifier name. In the end, the language and user model we found to be most satisfying, giv= en the above, is: new-expressions, like std::allocator, may obtain storage by calling 'operator new', but it's unspecified how often it's called and with what arguments. And the language rules are an approximation of that idea. (In reply to Marc Glisse from comment #5) > This of course doesn't at all prevent from adding a __builtin_operator_new > option in std::allocator, it only affects how motivated we should be to f= ix > the non-conformance. Well, in case it helps your analysis, LLVM once did what GCC does now (befo= re there were standard rules in place), and in practice we saw it break some s= tuff (largely, tests for allocators, but also weird things like using 'operator new((size_t)-1)' as a way to throw bad_alloc from code that can't '#include ').=