From patchwork Tue Jan 17 19:28:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Pluzhnikov X-Patchwork-Id: 63282 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 321423858C3A for ; Tue, 17 Jan 2023 19:29:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 321423858C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1673983758; bh=r7yY/g8NRAV8g52HW0mswrdYu3IFe0aKUf78E1+yr14=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=KIthin0AIEQiSMkSUwfCmWLt1HPrb39hYBEAy+BtrNS+EDzvL9ASkWVUIppmJyPBI jgLDoj1wDoc2LngKyiG7Fq+pd8Wns3DIMuhSQswowHjgyRkqcHXoNwvUoFUNpNWym4 SOrrlMimTOLjlDSlCVr4Cl+G0ej61PjqJkNAw7Yo= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id AC8C63858D28 for ; Tue, 17 Jan 2023 19:28:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC8C63858D28 Received: by mail-wr1-x433.google.com with SMTP id e3so22476303wru.13 for ; Tue, 17 Jan 2023 11:28:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=r7yY/g8NRAV8g52HW0mswrdYu3IFe0aKUf78E1+yr14=; b=dudp4G4TDyudSXXN/rZj5JIeFL1QQZLDG14hPyWTdnLbHH4ReAWDjTrHTsfXqeaqKy dVcxSQ89L17v3va5Zv1qbugHkB4OieRJP3j4H6fYpKvpXtFtMXrKiwoQDzfr0tqkNbac VrhuzEDoVve2uJvmJvinxvt5J9TPTphkP8Tfe2ymQyYRNQJzMiKGuOqeVTuaOMKUgILV 6kZt4tZrQg1zlVAOtIdtcy2clRU4NjveW2AGRvRX9IolvJtlx1SfvygqHuK55t4X2M+b T+KdtupPTQwU85GGZ1d8N5/lhrImzjwwNyiNGN6HtbocXhug4Cqg47O8AAGO7W9mtwYq gROQ== X-Gm-Message-State: AFqh2kpTMFfBrWvdHtMOO8rJIPxH1jg125rHnn+l6IemfT9Q3AU4IZvg jg1vgTnRCLyuh4YeCVxkmwwdikPdig9dQkQhqcCbS/EBKyYsINJb X-Google-Smtp-Source: AMrXdXu3S2Ea5rut7uzn8yDvk6U+LewDOj6PLF+Z54ejmcC6sq20cXGSC3uuBY8wHldWwRj4W6cHNuTXP3DvMbmapNU= X-Received: by 2002:a5d:4a8d:0:b0:2bb:f794:d444 with SMTP id o13-20020a5d4a8d000000b002bbf794d444mr191711wrq.295.1673983734356; Tue, 17 Jan 2023 11:28:54 -0800 (PST) MIME-Version: 1.0 Date: Tue, 17 Jan 2023 11:28:27 -0800 Message-ID: Subject: [patch] Use __builtin_FILE and __builtin_LINE in assert implementation in C++ To: GLIBC Devel X-Spam-Status: No, score=-24.6 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Paul Pluzhnikov via Libc-alpha From: Paul Pluzhnikov Reply-To: Paul Pluzhnikov Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" Greetings, Attached patch changes assert in C++ mode from using __FILE__ and __LINE__ to using __builtin_FILE() and __builtin_LINE(). These are supported by GCC since ~2012. Motivation: C++20 modules. When building C++, inline functions are required to have the exact same sequence of tokens in every translation unit. But __FILE__ token, when used in a header file, does not necessarily expand to the exact same string literal. For example: // a.h #include inline void fn () { assert (0); } // a.cc #include "a.h" // b.cc #include "foo/../a.h" Preprocessing a.cc and b.cc produces: (static_cast (0) ? void (0) : __assert_fail ("0", "a.h", 2, __extension__ __PRETTY_FUNCTION__)); and (static_cast (0) ? void (0) : __assert_fail ("0", "foo/../a.h", 2, __extension__ __PRETTY_FUNCTION__)); respectively. Without C++ modules, this results in unpredictable output, and technically there is an ODR violation. When C++ modules are involved, the mismatched sequence of tokens may be diagnosed and result in a build failure. P.S. I am only aware of the __FILE__ expansion causing problems, but I am changing __LINE__ as well for symmetry. diff --git a/assert/assert.h b/assert/assert.h index 72209bc5e7..4e0303db8d 100644 --- a/assert/assert.h +++ b/assert/assert.h @@ -89,7 +89,8 @@ __END_DECLS # define assert(expr) \ (static_cast (expr) \ ? void (0) \ - : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION)) + : __assert_fail (#expr, __builtin_FILE (), __builtin_LINE (), \ + __ASSERT_FUNCTION)) # elif !defined __GNUC__ || defined __STRICT_ANSI__ # define assert(expr) \