From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id 230953858D33 for ; Sat, 2 Dec 2023 21:51:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 230953858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 230953858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::82e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701553870; cv=none; b=W4GhAqqSI1WO/E8RVI8OvSCOnvtZ808hrsdATc4P1K9mG1TBkbqsMno7tDhWNvEYFvkVtvkQuv+wC7ZJj14n43PSfmqKhqN6hodber32Jq1X6nCkcZtjBKam6hrqDbuUPjc69lGsq1CclyKBa06bZ7yVKuGg9gzGjYlmSFUizT0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701553870; c=relaxed/simple; bh=H9xC8rxeg6hNeBpdDHv0EY6fIsN54uC4E9EAvKdFLkI=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=oDcNDunJz7/+zRixkpVNNowAJtWxrsW9W0zA3z1X8t8l68RkjSLvAOiktdUAXVJlheBHDaeFj3u8njFvPd9hy3I1s7306oj5WcKgCKutUyMxWNuN4sur+Ql/25YppleE1Hv49DfjiCT9rf60A4PiTPP4JUaEDMYWhCUm7rFVnJU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-423c944352fso22435081cf.3 for ; Sat, 02 Dec 2023 13:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701553868; x=1702158668; darn=gcc.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=H9xC8rxeg6hNeBpdDHv0EY6fIsN54uC4E9EAvKdFLkI=; b=IVnJDXTaBdhb29dt+yFxKDgS4WYI1YbtUpvEgRGQCMwvXcEAub10C205wPbvDa6Ljp 1JCAOwH+F8NPDE+Nse/KoKCYHDq1TQHlEqIjSl1BvppjJfSsbN7WN8uio7W2jYkd9nfV NR6iNPfWAkQ9Q3cDXH5HoYDQA8FSfpIsxeqjDmVZF8TFAbZ0yRseOPCH0PkjzCrUYiLW uaKXjalUCAOyi0T8xvVppnaGjigGZVeOy07fh1bYUuAHFKx9FS8U2jTQV5cIRCHfXXpZ zk6kKBSpvOLZrR3yvAKjBduIjk6n7r4xsYDXlFRIGB2IdEV8wS+AEH7sjTEMdT7p6sC/ Drrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701553868; x=1702158668; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=H9xC8rxeg6hNeBpdDHv0EY6fIsN54uC4E9EAvKdFLkI=; b=Z5Oee8IADigWTPZlwpfkUPeo8MVdFf6itjVKF7sl3UdbIu71RJ8i+eGEbTdwvhZnyt bELvE1oeMLbysxYYJe+CpJp1GeezaNX3tuVeb00VImiK0GzMcH8kM2luGPh51BkFixLY XNXzYlp86DWQHDtZpKLEZNYe6T3bR+7qK/L3+Q0hItV6PWz2Wq2s3PeKpPimpYQlXP30 fOa9oSsAC0KeJ00VQYKOUnkVNIxUrgm0ZYJK6QU7rIUbZ49sSDPTfIJmgFz48y/Sv1YT tqzNZzwBuX872gro6PdXmf/53VTEO5IDKirrctwtfH1oWNxqiaU7ANBo5GxD2qInhWJS bqQQ== X-Gm-Message-State: AOJu0YyOx2GD+8l0rCl2XN95k7mtvalP9zVySej/TjI/IiM4Jv2xSzfR Y0WOGOk/EnjKt4sMDdjNjXKrauB73Lj35HsEgDWiDzPhMDU= X-Google-Smtp-Source: AGHT+IF6/R3ByAKeA2bHawYscb9wlcJgQmBSr3mfIXrNxpgTbWn8iSWC0SrA7uk15rPq0KrNoaMTavNt8qbhmnHMDwQ= X-Received: by 2002:a05:622a:1485:b0:423:8dd3:b6cb with SMTP id t5-20020a05622a148500b004238dd3b6cbmr2488849qtx.9.1701553868201; Sat, 02 Dec 2023 13:51:08 -0800 (PST) MIME-Version: 1.0 From: Dan Klishch Date: Sat, 2 Dec 2023 16:50:57 -0500 Message-ID: Subject: [[gcc_struct]] potential clang compatibility concerns To: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, In the discussion of LLVM's PR adding `[[gnu::gcc_struct]]` support to Clang (https://github.com/llvm/llvm-project/pull/71148), maintainers asked me to make sure that whatever is done there, makes sense for GCC too. To summarize the long discussion on GitHub, GCC supports gcc_struct, ms_struct, and `-m{no-,}ms-bitfields` only on X86, while Clang currently supports ms_struct and `-m{no-,}ms-bitfields` on all targets with Itanium C++ ABI. Correspondingly, my PR adds support for gcc_struct for all targets with the Itanium C++ ABI and paves the road for gcc_struct and ms_struct support on targets with Microsoft C++ ABI (mainly, x86_64-pc-windows-msvc). There, I envision `ms_struct` to be a no-op (just like `gcc_struct` is usually a no-op with Itanium C++ ABI) and `gcc_struct` to change layout of C structs (or fields within C++ classes) to be compatible with the GenericItanium C++ ABI. As far as I can tell, the maintainer's question is "in a theoretical event GCC starts supporting Microsoft C++ ABI, would it make sense to implement gcc_struct and ms_struct on it just like I propose to?". Thanks, Dan Klishch