From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.163]) by sourceware.org (Postfix) with ESMTPS id 75A603858D26 for ; Thu, 3 Nov 2022 13:38:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 75A603858D26 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gjlay.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=gjlay.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1667482721; s=strato-dkim-0002; d=gjlay.de; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=miGlsOqSSHs/hMq0u08L1FzXgYxilAu8WQ7ge2vDtBE=; b=oQr/4vV8mIou09R5Zp4YOIzq+J4jj0vmi+0GFrTjetJZMbtywi3x3Jv/7pFn7evD+I 4Vd56bdZEVq6UoZPZGJyH26PjGWvQih5qClNKCaJBPq81OOQjxHmNPo2fMBPdm4lgBk1 8oAbM5oKhcdMOc/ef0ZPyTG056atADultgTY9Y3zEjYouhOLqyOn3NBHUcWX9X9qCCK3 WSOPCNEsRBCCTH77u11AKHDBNkhpFpcfLeW1Y9fP8pkspS9PUPLBXTUD+h/qwra6aFZB JaHdz1qgmJd8ohmyALeNzoQN0OJyA6vxQlCzBtIYZgzzs2+AiCMwqo9zdCX3NUOKyhZt RF7g== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKT7Qq0xotTetVnKkbjtK7qmy9Jvpc5Ezo" X-RZG-CLASS-ID: mo00 Received: from [192.168.2.102] by smtp.strato.de (RZmta 48.2.1 DYNA|AUTH) with ESMTPSA id aba1dcyA3DcemFD (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 3 Nov 2022 14:38:40 +0100 (CET) Message-ID: <49b9d82e-3252-9e58-f064-b74f059d8b7d@gjlay.de> Date: Thu, 3 Nov 2022 14:38:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v3] c++: parser - Support for target address spaces in C++ Content-Language: en-US To: Paul Iannetta , Jason Merrill Cc: gcc-patches@gcc.gnu.org References: <20221013152341.bztoqunwtmhdzi3f@ws2202.lin.mbt.kalray.eu> <20221013160227.sdlv6yaw5gr4zcvd@ws2202.lin.mbt.kalray.eu> <20221013215643.o2bymrmffwbtuppu@ws2202.lin.mbt.kalray.eu> <4026cae9-e371-a2ee-2b36-7abc9224afa1@redhat.com> <20221018073731.wj2expjfmk5uhmp3@ws2202.lin.mbt.kalray.eu> <07d4c9ba-594a-d3f8-3df3-5ef5d18a6e97@redhat.com> <20221018170135.zpkmyebmpcvqx7ky@ws2202.lin.mbt.kalray.eu> <20221026071837.l3de5hkxujvqqztr@ws2202.lin.mbt.kalray.eu> From: Georg-Johann Lay In-Reply-To: <20221026071837.l3de5hkxujvqqztr@ws2202.lin.mbt.kalray.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > [PATCH v3] c++: parser - Support for target address spaces in C++ First of all, it is great news that GCC is going to implement named address spaces for C++. I have some questions: 1. How is name-mangling going to work? ====================================== Clang supports address spaces in C++, and for address-space 1 it does generate code like the following: #define __flash __attribute__((__address_space__(1))) char get_p (const __flash char *p) { return *p; } _Z5get_pPU3AS1Kc: ... I.e. address-space 1 is mangled as "AS1". (Notice that Clang's attribute actually works like a qualifier here, one could not get this to work with GCC attributes.) 2. Will it work with compound literals? ======================================= Currently, the following C code works for target avr: const __flash char *pHallo = (const __flash char[]) { "Hallo" }; This is a pointer in RAM (AS0) that holds the address of a string in flash (AS1) and is initialized with that address. Unfortunately, this does not work locally: const __flash char* get_hallo (void) { [static] const __flash char *p2 = (const __flash char[]) { "Hallo2" }; return p2; } foo.c: In function 'get_hallo': foo.c: error: compound literal qualified by address-space qualifier Is there any way to make this work now? Would be great! 3. Will TARGET_ADDR_SPACE_DIAGNOSE_USAGE still work? ==================================================== Currently there is target hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE. I did not see it in your patches, so maybe I just missed it? See https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/Named-Address-Spaces.html#index-TARGET_005fADDR_005fSPACE_005fDIAGNOSE_005fUSAGE 4. Will it be possible to put C++ virtual tables in ASs, and how? ================================================================= One big complaint about avr-g++ is that there is no way to put vtables in flash (address-space 1) and to access them accordingly. How can this be achieved with C++ address spaces? Background: The AVR architecture has non-linear address space, and you cannot tell from the numeric value of an address whether it's in RAM or flash. You will have to use different instructions depending on the location. This means that .rodata must be located in RAM, because otherwise one would not know whether const char* pointed to RAM or flash, but to de-reference you's need different instructions. One way out is named address spaces, so we could finally fix https://gcc.gnu.org/PR43745 Regards, Johann